Czy dostępne są materiały badawcze dotyczące dokładności NTP?


13

O ile mi wiadomo, dokładność synchronizacji NTP w dużym stopniu zależy od sieci. Widziałem w Internecie pewne liczby od 50 mikrosekund do „poniżej jednej sekundy”. To ogromna różnica.

Wierzę, że zależność od dokładności jest świetnym pytaniem do zbadania, ale jak dotąd nie znalazłem żadnego materiału, który wyraźnie stwierdza, że, powiedzmy, pewna konkretna konfiguracja zapewnia tę szczególną dokładność.

Jest powiedziane na http://www.ntp.org/ntpfaq/NTP-s-algo.htm :

Do utrzymania synchronizacji NTP wymagana jest różnica czasu mniejsza niż 128 ms między serwerem a klientem. Typowa dokładność w Internecie wynosi od około 5 ms do 100 ms, być może zmienia się wraz z opóźnieniami sieci. Ostatnie badanie [2] sugeruje, że 90% serwerów NTP ma opóźnienia sieciowe poniżej 100 ms, a około 99% jest synchronizowanych w ciągu jednej sekundy z równorzędnym urządzeniem synchronizującym.

Dzięki synchronizacji PPS można uzyskać dokładność 50 µs i stabilność poniżej 0,1 PPM na komputerze Pentium (na przykład z systemem Linux).

To jest coś, ale może jest jakaś dokładniejsza analiza na ten temat?


3
Chociaż myślę, że to pytanie w ogóle nie wykazuje wysiłku badawczego i na tej podstawie głosuję za odrzuceniem - nie jest nawet jasne, że OP przeczytał dowolny materiał na ntp.org - myślę, że jest to zgodne z prawem pytanie i sprzeciwiałoby się zamknięciu ta podstawa. Chcąc wiedzieć, dlaczego protokół będzie działał zgodnie z reklamą, zamiast ślepo wdrażać i mieć nadzieję na najlepsze, nie jest stratą czasu.
MadHatter

Dzięki za aktualizację pytania, zrezygnowałem z głosowania. Powiedziawszy to, możesz czuć się denerwująco, gdy odeślesz nas z powrotem, ale jeśli nie powiesz nam, gdzie byłeś, kiedy zadajesz pytanie, skąd możemy to wiedzieć? Zauważam również, że sam tekst, który zamieszczasz powyżej, zawiera wskaźnik do artykułu naukowego badającego dokładność serwerów NTP. Czytałeś to, a jeśli tak, czy możesz wskazać, dlaczego to nie wystarczyło?
MadHatter

Słusznie. Artykuł jest 14-letnim ogólnym badaniem sieci NTP. Ma dalsze linki, ale wszystkie są oczywiście jeszcze starsze. Próbowałem Google Scholar i CiteSeer, ale większość linków to te same Mills i Millnar z lat dziewięćdziesiątych. Nadal przeglądam, ale jestem trochę za daleko od tematu i może to zająć dużo czasu, więc postanowiłem poprosić społeczność o pomoc.
akalenuk

1
NTP nie zmieniło się od co najmniej 14 lat, dlaczego jego dokładność zmieniłaby się znacząco? Jak wspomniano poniżej, NTP nie ma być bardzo dokładny, ma dostać się w ciągu 1 s (prawdopodobnie z tego pochodzi ten niedoinformowany cytat). Jeśli potrzebujesz dokładności poniżej 1ms, powinieneś użyć PTP. Naprawdę nie widzę żadnej wartości w badaniu dokładności czegoś, co przy bardzo szerokim wdrożeniu robi dokładnie to, co było zamierzone.
Chris S

2
Faktycznie, Chris, dwa kawałki pracy cytowany jasno wynika, że dokładność serwerów NTP w internecie (nie sam protokół, który był zawsze doskonałe) został udoskonalony między 1999 i teraz. Podejrzewam, że dzieje się tak częściowo dlatego, że Internet jest lepszy - opóźnienia są nieco niższe i znacznie mniej zmienne niż kiedyś - a częściowo dlatego, że poprawiła się jakość serwerów S1 (artykuł z 1999 r. Mówi, że najczęstszym źródłem zegara dla serwerów S1 jest Zegar systemu operacyjnego!). Cieszę się, że OP zadał to pytanie, myślę, że warto.
MadHatter

Odpowiedzi:


14

Nikt nie może zagwarantować, jak dobrze NTP będzie działał w twojej sieci, ponieważ nikt nie wie, jak dobrze twoja sieć jest połączona z Internetem i serwerami zegara na nim. Jednak zgodnie ze stroną algorytmu dyscypliny zegarowej na ntp.org

W przypadku ciągłego działania klient NTP w szybkiej sieci LAN w środowisku domowym lub biurowym może nominalnie utrzymać synchronizację w ciągu jednej milisekundy. Gdy zmiany temperatury otoczenia są mniejsze niż stopień Celsjusza, częstotliwość oscylatora zegarowego jest dyscyplinowana z dokładnością do jednej części na milion (PPM), nawet gdy natywne przesunięcie częstotliwości oscylatora zegarowego wynosi 100 PPM lub więcej.

Zwróć uwagę, że duże, ale stabilne opóźnienie między twoją siecią LAN a internetowymi serwerami zegarowymi nie ma tak złego wpływu na dokładność, jak bardzo zmienne opóźnienie.

Nie podajesz, skąd masz powyższe szacunki („50 mikrosekund do ...„ poniżej jednej sekundy ””), więc nie mogę ich komentować, ale z mojego doświadczenia wynika, że ​​50us jest mało prawdopodobne, chyba że masz bezpośrednie powiązanie źródło zegara, a 1s jest mało prawdopodobne, chyba że masz kawałek mokrego sznurka łączącego cię z Internetem i używasz serwerów upstream na Antarktydzie.

Edycja : tekst, który teraz cytujesz w swoim pytaniu, daje wskaźnik do artykułu, który w 1999 r. Rzeczywiście ustalił, że 99% serwerów NTTP jest zsynchronizowanych w ciągu jednej sekundy. Na szczęście są nowsze prace; w tym artykule niektórzy autorzy z Federalnego Uniwersytetu w Paranie w Brazylii powtórzyli eksperyment w 2005 roku i stwierdzili (jeśli dobrze rozumiem ich ryc. 1), że na północ od 99% - więcej niż 99,5% - serwerów ma teraz przesunięcia mniejsze niż 100 ms, a 90% ma przesunięcia mniejsze niż 10 ms. To całkiem dobrze pasuje do moich doświadczeń (patrz wyżej).

Edycja 2 : ostatnia zmarszczka: wszystkie te badania nie badają, jak dokładny jest zegar lokalny, ale jak bardzo różni się od wcześniejszego zegara referencyjnego. To oczywiście nie to samo. Ale pierwszy jest niepoznawalny; aby wiedzieć, jak zły jest twój zegar, musisz dokładnie wiedzieć, która jest godzina, a jeśli o tym wiesz, dlaczego miałbyś tak źle ustawić swój zegar? Pamiętaj tylko, że to, co mierzą te badania, nie jest różnicą między zegarem lokalnym a czasem bezwzględnym, ale między zegarem lokalnym a zegarem odniesienia.


+1 Prowadziłem również serwer puli, dryf> 20ms monitorowany w całym kraju był dziwny.
Chris S

9

Jaki problem próbujesz rozwiązać?

Rozwiązaniem, które spotkałem w środowiskach wymagających większej precyzji niż NTP, jest Precision Time Protocol (PTP) . Miałem to w komputerowych aplikacjach naukowych i finansowych. Są jednak kompromisy .

Zobacz także: synchronizacja czasu ptp na centos6 / rhel


4
„Jaki problem próbujesz rozwiązać?” Moje ulubione pytanie - zadaję je cały czas.
mfinni

@ mfinni, Kiedy musisz ustalić, który z Twoich klientów przesyła pierwszy (np. HFT ), pomaga to zachować dokładność czasu.
Pacerier,

6

Kilka innych rzeczy, o których warto wspomnieć:

  • Będziesz miał szczęście uzyskać <100ms jittera zegara na maszynie wirtualnej, więc wszystkie poniższe informacje dotyczą hosta fizycznego
  • Jitter poniżej 100 ms jest prawie niezmierzony dla prawie każdego zadania i łatwo osiągalny przez Internet
  • Jitter poniżej 30 ms może być potrzebny w niektórych ogólnych środowiskach obsługujących (potrzebowałem go do korelacji logów w poprzednim zadaniu) i można go łatwo osiągnąć za pomocą serwerów NTP na tym samym kontynencie, na którym połączenie nie odbywa się za pośrednictwem łączy „konsumenckich” (np. Nie satelitarnych , ADSL, DOCSIS, GPON, UMTS / LTE / HSPA / etc)
  • Aby uzyskać absolutną dokładność poniżej tego, powinieneś instalować sprzętowe serwery NTP od wysokiej jakości dostawcy (np. Symmetricom)
  • Lokalne porozumienie poniżej 10 ms (często poniżej 1 ms) można łatwo osiągnąć, po prostu posiadając trio (możesz zrobić mniej, ale istnieją powody, aby użyć trzech lub pięciu) w tym samym centrum danych, wystarczająco dużo dla prawie każdej aplikacji nienaukowej

5

Zainteresowanie z mojej strony: jestem agentem Meinberga :-)

Tak NTP może osiągnąć kompleksową precyzję do ok. 50 us (czyli mikrosekund) jittera, jeśli zsynchronizujesz „klienta” linuksa na gołym metalu z systemem Chrony lub ntpd, z serwerem NTP opartym na Linuksie, zdyscyplinowanym przez GPS, lokalny zegar atomowy lub jakieś inne źródło.

Na maszynie, która ma lokalny GPS (z interkonektem PPS), prawdopodobnie zobaczysz 0-2 mikrosekund przesunięcia, między instancją ntpd działającą w systemie operacyjnym, a wejściem sterownika ponownego kodowania PPS.

Te pozostałe 50 osób „od końca do końca przez LAN” są wynikiem kilku etapów buforowania, zmiennego opóźnienia IRQ, innego ruchu zakłócającego LAN i zaangażowane magistrale komputerowe i tak dalej. 50 us oznacza sieć LAN o bardzo małym ruchu. Nawet tylko przełącznik może dodać kilka mikrosekund drgań - a wyższej klasy przełączniki ze złożonymi funkcjami zwiększają opóźnienia i drgania. Innymi słowy, może być bardzo trudno osiągnąć te 50 mikrosekund w warunkach rzeczywistych w niektórych praktycznych sieciach LAN.

Podobnie, te cca <2us przesunięcia PPS wynikają tylko z niepewności opóźnienia IRQ i ogólnego jittera opóźnienia magistrali na dobrze zachowanym sprzęcie PC.

Zauważ, że NTP i jego implementacje ntpd i Chrony z pewnością mierzą czas transakcji w obie strony NTP i odejmują (dodają, w rzeczywistości) połowę tej podróży w obie strony, jako środek do filtrowania systematycznego opóźnienia transportu (w jedną stronę). Dokonują także odrzucania wartości odstających, konsensusu kworum, wyborów syspeer i każdego demona NTP filtrują odpowiedzi, które otrzymają na jego zapytania poprzedzające. Tak jak inni powiedzieli, milisekundy widoczne w Ping i Traceroute nie kompensują bezpośrednio lokalnego zegara. Liczy się zmienność transakcji w obie strony, tj. Inny ruch na drodze do twojego wcześniejszego serwera NTP. Ntpq -p jest twoim przyjacielem.

Podstawowy odbiornik GPS do pomiaru czasu, z TCXO, może mieć może 100-200 ns resztkowego jittera + wędrówki na wyjściu PPS. Wystarczająco dobre dla NTP, o ile GPS pozostaje zablokowany. (Wydajność Holdover nie jest bardzo dobra w przypadku TCXO.) GPS wysokiej jakości z OCXO może znajdować się w granicach 100 ns, może więcej niż 10-30 ns błędu resztkowego (przesunięcie względem globalnego UTC).

Zwróć uwagę, że rzeczywiste satelity przelatujące nad tobą i promieniejące przez atmosferę mogą być nieco trudniejszą grą dla odbiornika, niż testowanie w laboratorium z generatorem GPS.

PTP to młotek. Potrzebujesz pomocy HW u arcymistrza, u niewolników i dowolnych przełączników - ale jeśli to wszystko dostaniesz, możliwe jest przesunięcie resztkowe do niskiej podwójnej cyfry nanosekund. Osobiście widziałem to w ptp4l z kartą sieciową i210, która ma obsługę HW (znacznik czasu z rozdzielczością nanosekundową).

Układ i210 to cud. Posiada 4 piny ogólnego przeznaczenia, których można użyć do wprowadzenia lub wyprowadzenia sygnału PPS. Referencyjna karta dodatkowa Intel NIC z i210 (i jej wersje OEM od kilku dużych dostawców) jest wyposażona w nagłówek pinów, który daje dostęp do co najmniej 2 z tych pinów GPIO (SDP są nazywane przez Intel). Oprócz implementacji portu grandmaster PTP, wejście PPS można wykorzystać do precyzyjnego oznaczania czasu w przechwytywaniu pakietów. Potrzebujesz precyzyjnego źródła PPS i niestandardowego oprogramowania do uruchomienia pętli serwo, dostrajając PHC i210 do ext.PPS. Na moim stanowisku testowym spowodowało to jednocyfrowe ns (na iterację 1 s) przesunięcia resztkowego. To jest precyzja, którą uzyskuje się w znacznikach czasu przechwytywania, jeśli uruchamiasz najnowszy tcpdump lub wireshark na nowoczesnym jądrze Linuksa (całe oprogramowanie wymaga wsparcia rozdzielczości na poziomie nanosekund). Jeszcze lepiej: poszedłem na całość i zbudowałem prosty syntezator PLL, aby wyprodukować 25 MHz dla zegarów NIC, zablokowanych do dokładnego odniesienia 10 MHz. Następnie resztkowe przesunięcie w pętli serwomechanizmu mojego urządzenia do przechwytywania pakietów spadło do czystego 0 (dowód, że moje odniesienie 10 MHz jest synchronizowane fazowo z PPS z tego samego urządzenia GPS).

Należy zauważyć, że arcymistrzowie PTP mogą być określani w celu zapewnienia znaczników czasu o rzeczywistej ziarnistości na 8 ns (w typie danych o rozdzielczości 1 ns). Ma to sens - gigabit Ethernet ma tendencję do używania zegara 125 MHz, używanego jako zegar bajtowy we wnętrzu MAC, ten zegar jest prawdopodobnie również używany w GMII, a także jest zegarem symbolicznym w metalicznym 1000Base-TX (cztery pary równolegle 2 bity na symbol na parę). Więc jeśli nie używasz 1000Base-FX (światłowód) z SERDES i ekstremistycznej implementacji jednostki znacznika czasu HW w PHY, która działa z poszczególnymi bitami SERDES, te 8 ns to wszystko, na co realistycznie możesz liczyć w przypadku gigabitowego Ethernetu. Niektóre karty danych chipów (z obsługą PTP) twierdzą nawet, że ścieżka danych MII nie jest wolna od buforowania i stamtąd mogą pochodzić pewne drgania.

Pakiety PTP faktycznie zawierają znaczniki czasu przechowywane w typie danych, który pozwala na głęboką rozdzielczość poniżej nanosekund. Ale „sub-nanosekundowe pole ułamkowe” jest obecnie zwykle nieużywane. AFAIR tylko projekt White Rabbit (związany ze szwajcarskim centrum badawczym CERN) jak dotąd wdrożył precyzję subn.

PTP jest również dostępny w czystym oprogramowaniu, bez przyspieszenia HW. W takim przypadku, dla GM opartego na SW i klienta opartego na SW, spodziewaj się podobnego jittera resztkowego jak w przypadku NTP - tj. Około 50 osób w dedykowanej, ale nieświadomej sieci LAN. Pamiętam, że otrzymałem precyzję poniżej mikrosekundy od arcymistrza HW na bezpośrednim interkonekcie (bez przełączania między) i na kliencie z oprogramowaniem tylko dla SW (na nieświadomej karcie sieciowej PTP). W porównaniu z NTP, serwomechanizm PTP zbiega się znacznie szybciej.

Podczas wykonywania niektórych „prac domowych”, niedawno przyszło mi do głowy, że transportowanie PPS lub podobnych „dyskretnych” sygnałów taktowania po rozległych trasach światłowodowych może być podatne na „wędrówkę” zależnego od temperatury czasu propagacji. I chociaż nie mam możliwości przetestowania tego eksperymentalnie, niektóre źródła w interwebach podają liczby od 40 do 76 pikosekund na kilometr i Kelvina. Należy zauważyć, że chociaż tego rodzaju „wędrówka termiczna” nie jest w stanie złagodzić „w paśmie” w transmisji simpleksowej PPS, PTP z natury zrekompensuje to z natury, w oparciu o swoje standardowe pomiary opóźnienia ścieżki (która zależy od transmisji w pełnym dupleksie).

To tyle, jeśli chodzi o przegląd „dokładności” w różnych technologiach / interfejsach czasowych. Jaki poziom precyzji jest dla Ciebie wystarczająco dobry, w zależności od zastosowania, od rzeczywistych potrzeb.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.