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.