NTP doğruluğu hakkında bir araştırma materyali var mı?

Bildiğim kadarıyla, NTP senkronizasyonunun doğruluğu büyük ölçüde ağa bağlıdır. İnternet üzerinden 50 mikrosaniyeden "bir saniyenin altında" rakamlar gördüm. Bu çok büyük bir fark.

Doğruluk bağımlılığının araştırılması için harika bir soru olduğuna inanıyorum, ancak şimdiye kadar bazı özel konfigürasyonların bu doğruluğu verdiğini açıkça belirten herhangi bir materyal bulamadım.

Http://www.ntp.org/ntpfaq/NTP-s-algo.htm adresinde söylenir :

NTP senkronizasyonunu sürdürmek için sunucu ve istemci arasında 128 ms'den daha az bir zaman farkı gerekir. İnternet'teki tipik doğruluk, yaklaşık 5ms ila 100ms arasında değişmektedir, muhtemelen ağ gecikmeleriyle değişmektedir. Yakın zamanda yapılan bir anket [2], NTP sunucularının% 90'ının 100 ms'nin altında ağ gecikmelerine sahip olduğunu ve yaklaşık% 99'unun senkronizasyon eşiyle bir saniye içinde senkronize edildiğini göstermektedir.

PPS senkronizasyonu ile Pentium PC'de 50µs hassasiyet ve 0.1 PPM'nin altında bir stabilite elde edilebilir (örneğin Linux çalışıyor).

Bu bir şey, ama belki de konu hakkında daha ayrıntılı bir analiz var mı?

Kimse NTP'nin ağınızda ne kadar iyi çalışacağını garanti edemez, çünkü kimse ağınızın internete ve bunun üzerindeki saat sunucularına ne kadar iyi bağlandığını bilmez. Ancak, ntp.org'daki saat disiplini algoritması sayfasına göre

Sürekli olarak çalışır durumda kalırsa, bir ev veya ofis ortamında hızlı bir LAN üzerindeki bir NTP istemcisi, senkronizasyonu bir milisaniye içinde nominal olarak koruyabilir. Ortam sıcaklığı değişimleri santigrat derecenin altında olduğunda, saat osilatörü doğal frekans ofseti 100 PPM veya daha fazla olsa bile, saat osilatör frekansı milyonda bir parça (PPM) içinde disipline edilir.

LAN'ınız ve İnternet'in saat sunucuları arasındaki büyük ancak kararlı gecikmenin, yüksek değişkenlikteki gecikme kadar doğruluk üzerinde kötü bir etkisi olmadığını unutmayın.

Yukarıdaki tahminleri nereden aldığını söylemiyorsun ('50 mikrosaniye ... "bir saniyenin altında" "), bu yüzden onlara yorum yapamam, ancak benim deneyimime göre, doğrudan ekli olmadıkça 50us olası değildir saat kaynağı ve 1s, sizi internete bağlayan bir ıslak dize parçanız yoksa ve Antarktika'daki yukarı akış sunucularını kullanmıyorsanız olası değildir.

Düzenleme : Şimdi sorunuzda alıntıladığınız metin, 1999'da ntp sunucularının% 99'unun bir saniye içinde senkronize edildiğini belirleyen bir makaleye bir işaretçi verir. Neyse ki, daha yeni çalışmalar var; içinde bu yazıda (ben onların Şek anlarsanız 1 doğru.) Parana, Brezilya, Federal Üniversitesi'nde bazı yazarlar 2005 yılında deneyi tekrarladı, ve bulunan% 99 geriye kuzey - daha 99.5% gibi - sunucularının şimdi daha az uzaklıklar var 100ms ve% 90'ının ofsetleri 10ms'den azdır. Bu benim deneyimlerime oldukça iyi uyuyor (yukarıya bakınız).

Düzenleme 2 : Son bir kırışıklık: Tüm bu çalışmalar yerel saatin ne kadar doğru olduğunu araştırmaz, bunun yerine yukarı akış referans saatinden ne kadar farklı olduğunu araştırır. Bunlar patentli olarak aynı şey değildir. Ama ilki bilinemez; saatinizin ne kadar yanlış olduğunu bilmek için saatin tam olarak ne zaman olduğunu bilmelisiniz ve bunu bilseydiniz, neden saatinizi yanlış ayarladınız? Sadece bu çalışmaların ölçtüğü şeyin yerel saat ile mutlak zaman arasındaki fark değil , yerel saat ile referans saat arasındaki fark olduğunu unutmayın .

Ne problemi çözmeye çalışıyorsun?

NTP'den daha fazla hassasiyet gerektiren ortamlar için karşılaştığım çözüm, Hassas Zaman Protokolüdür (PTP) . Bilimsel hesaplama ve finansal hesaplama uygulamalarında yaşadım. Yine de ödünler var .

Ayrıca bakınız: centos6 / rhel üzerinde ptp zaman senkronizasyonu

Bahsetmeye değer birkaç şey daha:

• Sanal bir makinede 100 ms'den daha az saat titreşimi elde ettiğiniz için şanslı olacaksınız, bu nedenle aşağıdakilerin hepsi fiziksel bir ana bilgisayar içindir
• Sub 100ms jitter neredeyse her görev için neredeyse ölçülemez ve internet üzerinden kolayca erişilebilir
• Bazı genel sunum ortamları için 30ms alt jitter gerekebilir (önceki bir işte günlük korelasyonu için ihtiyacım vardı) ve bağlantının "tüketici" bağlantıları üzerinden olmadığı aynı kıtadaki NTP sunucuları kullanılarak kolayca elde edilebilir (örn. Uydu değil) , ADSL, DOCSIS, GPON, UMTS / LTE / HSPA / vb.)
• Bunun altında mutlak doğruluk için kaliteli bir satıcıdan donanım NTP sunucuları kurmalısınız (örn. Symmetricom)
• Hemen hemen her Bilim Dışı uygulama için aynı veri merkezinde yeterli bir üçlüye (daha azıyla yapabilirsiniz, ancak üç veya beş kullanmanın nedenleri vardır) sahip olup, 10ms altı (genellikle 1ms altı) yerel anlaşma kolayca gerçekleştirilebilir

Benim tarafımdan çıkarılan ilgi: Ben bir Meinberg ajanıyım :-)

Evet NTP, uçtan uca hassasiyetini yakl. 50 bize (bu mikrosaniye), Chrony veya ntpd çalıştıran çıplak metal üzerinde bir linux "istemcisini" GPS, yerel atom saati veya benzeri bir kaynakla disiplinli Linux tabanlı bir NTP sunucusuna senkronize ederseniz.

Yerel bir GPS (PPS ara bağlantısı olan) olan makinede, muhtemelen işletim sisteminde çalışan ntpd örneği ile PPS refclock sürücüsü girişi arasında 0-2 mikrosaniye ofset göreceksiniz.

Bir LAN üzerinden uçtan uca kalan bu 50 "arabellekleme, değişken IRQ gecikmesi, LAN ve ilgili bilgisayar veri yollarına müdahale eden diğer trafik ve bunun bir kaç aşamasının bir sonucudur. 50 bize çok az trafiği olan bir LAN demek. Sadece bir anahtar bile bazı mikrosaniye titreşim ekleyebilir ve karmaşık özelliklere sahip üst seviye anahtarlar daha fazla gecikme ve titreşim ekler. Başka bir deyişle, gerçek dünya koşullarınızda bu 50 mikrosaniyeyi bazı pratik LAN'larda elde etmek oldukça zor olabilir.

Benzer şekilde, PPS ofsetinin bu cca <2us değeri, iyi işlenmiş PC donanımında sadece IRQ gecikme belirsizliği ve genel veri yolu gecikme titreşiminden kaynaklanır.

NTP ve onun ntpd ve Chrony uygulamalarının kesinlikle NTP işlem gidiş-dönüş süresini ölçtüğünü ve sistematik taşıma gecikmesini (tek yön) filtrelemek için bu gidiş-dönüşün yarısını (aslında eklediğini) unutmayın. Ayrıca, daha fazla reddetme, çekirdek görüş birliği, sistem seçimi ve herhangi bir NTP iblisi, yukarı akış sorgularına aldığı yanıtları filtreler. Diğerlerinin söylediği gibi, Ping ve Traceroute'ta gördüğünüz milisaniyeler yerel saatinizi doğrudan dengelemez. Önemli olan, işlem gidiş-dönüşünün değişkenliği, yani yukarı akış NTP sunucunuzun yolundaki diğer trafik. Ntpq -p senin arkadaşın.

Bir TCXO ile zamanlama kullanımı için temel bir GPS alıcısı, PPS çıkışında 100-200 ns artık jitter + dolaşıma sahip olabilir. GPS kilitli kaldığı sürece NTP için yeterince iyi. (Holdover performansı TCXO'larla çok iyi değil.) OCXO ile kaliteli bir zamanlama GPS'i 100 ns içinde, belki de 10-30 ns artık hataya benzeyebilir (global UTC'den ofset).

Havada uçan ve size bir atmosferde ışık saçan gerçek uyduların, alıcı için GPS jeneratörü ile bir laboratuvarda kıyaslamaktan biraz daha zor bir oyun olabileceğini unutmayın.

PTP bir çekiçtir. Büyükusta, kölelerde ve herhangi bir anahtarda HW desteğine ihtiyacınız var - ancak tüm bunları alırsanız, düşük çift haneli nanosaniyeye kadar artık ofsetler mümkündür. Ben şahsen bunu HW desteği (bir nanosaniye çözünürlük ile zaman damgası) olan bir i210 NIC ile çalışan ptp4l gördüm.

İ210 yongası harika. Bir PPS sinyali girmek veya çıkarmak için kullanılabilen 4 genel amaçlı pime sahiptir. Referans i210'lu Intel addon NIC kartı (ve birkaç büyük tedarikçiden OEM sürümleri), bu GPIO pinlerinden en az 2 tanesine (Intel tarafından adlandırılan SDP'ler) erişmenizi sağlayan bir pin başlığı ile birlikte gelir. Bir PTP grandmaster portu uygulamanın yanı sıra, PPS girişi paket yakalamada hassas zaman damgası için kullanılabilir. Bir servo döngüsünü çalıştırmak için i210'un PHC'sini ext.PPS'ye ince ayarlayarak hassas bir PPS kaynağına ve özel bir yazılım parçasına ihtiyacınız vardır. Test cihazımda bu, tek ofsetin tek haneli ns (1 s yineleme başına) ile sonuçlandı. Bu, yakalama zaman damgalarınızda elde ettiğiniz hassasiyettir, Modern bir Linux çekirdeğinde yeni bir tcpdump veya wireshark çalıştırıyorsanız (tüm yazılımların nanosaniye düzeyinde çözünürlük için desteğe ihtiyacı vardır). Daha da iyisi: NIC saatleri için 25 MHz üretmek üzere basit bir PLL synth oluşturdum, yukarı doğru 10MHz referansa kilitlendi. Bundan sonra, paket yakalama donanımımın servo döngüsünde kalan ofset temiz bir 0'a düştü (10 MHz referansımın aynı GPS kutusundan PPS ile faz senkronize olduğunun bir kanıtı).

PTP büyükannelerinin, 8 ns başına gerçek tanecikliğe sahip zaman damgaları sağlamak üzere belirtilebileceğini unutmayın (1 ns çözünürlüğe sahip bir veri türünde). Bu mantıklı - gigabit Ethernet, MAC'in iç kısmında bayt saati olarak kullanılan 125 MHz saat kullanma eğilimindedir, bu saat muhtemelen GMII'de de kullanılır ve aynı zamanda metalik 1000Base-TX (dört çift) paralel olarak, çift başına sembol başına 2 bit). Bu nedenle, SERDES ile 1000Base-FX (fiber optik) ve PHY'deki bireysel SERDES bitlerine kadar çalışan HW zaman damgası biriminin aşırı bir uygulamasını kullanmıyorsanız, bu 8 ns, gigabit Ethernet'te gerçekçi olarak ümit edebileceğiniz tek şeydir. Bazı yonga veri sayfaları (PTP desteği ile), MII veri yolunun arabelleğe alınmadığını ve bazı titreşimlerin oradan gelebileceğini iddia ediyor.

PTP paketleri aslında derin nanosaniye çözünürlüğü sağlayan bir veri tipinde saklanan zaman damgalarını içerir. Ancak "nanosaniye altı kesirli alan" günümüzde tipik olarak kullanılmamaktadır. AFAIR sadece Beyaz Tavşan projesi (İsviçre araştırma merkezi CERN ile ilgili) şimdiye kadar sub-ns hassasiyetini uyguladı.

PTP, HW hızlandırması olmadan saf yazılımda da mevcuttur. Bu durumda, SW tabanlı bir GM ve SW tabanlı bir istemci için, NTP ile benzer bir artık titreşimi almayı bekleyebilirsiniz - yani yaklaşık 50 bize özel ama PTP farkında olmayan bir LAN'da. Doğrudan bağlantı (aralarında geçiş yok) ve yalnızca SW istemcisi (PTP habersiz PC NIC'de) üzerinde bir HW grandmaster'dan mikrosaniye altı hassasiyet elde ettiğimi hatırlıyorum. NTP ile karşılaştırıldığında, PTP'nin servo çok daha hızlı birleşir.

Bazı "ödev" yaparken, yakın zamanda bana PPS veya benzer "ayrık" zamanlama sinyallerinin geniş alan fiber optik yollar üzerinden taşınmasının sıcaklığa bağlı yayılma süresi "dolaşmasına" duyarlı olabileceği ortaya çıktı. Ve bunu deneysel olarak test etmem mümkün olmasa da, iç ağlardaki bazı kaynaklar km ve Kelvin başına 40 ila 76 pikosaniye arasında rakamlar gösteriyor. Bu tür bir "termal dolaşımı" simpleks PPS iletiminde "bantta" hafifletmek mümkün olmasa da, PTP standart yol gecikme ölçümlerine (tam çift yönlü iletime bağlı olarak) dayanarak bunu doğal olarak telafi edecektir.

Farklı zamanlama teknolojileri / arayüzlerinde "hassasiyetlerin" nasıl göründüğüne genel bir bakış için çok fazla Uygulamanıza bağlı olarak gerçek ihtiyaçlarınız için hangi hassasiyet seviyesi sizin için yeterince iyidir.