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?
Odpowiedzi:
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
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.
źródło
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
źródło
Kilka innych rzeczy, o których warto wspomnieć:
źródło
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.
źródło