Służba czasu – testowanie NTP

wykres

Przy obserwacjach bliskich Ziemi planetoid, satelitów a także zakryć gwiazd przez planetoidy bardzo istotne jest dokładne zarejestrowanie czasu zjawiska. Zegary komputerów domowych, pozostawione same sobie, szybciej lub później zaczną wskazywać nieakceptowalne odchylenia. Odchylenia te będą zmienne w czasie, zależne od warunków w jakich pracuje komputer. Remedium na tę przypadłość może być synchronizowanie zegarów wg serwerów czasu. W niniejszym artykule chcę przyjrzeć się pracy tych urządzeń bliżej.

Od ponad 70 godzin rejestruję znaczniki czasu wysyłane przez ok. 30 serwerów NTP. Mój komputer znajduje się w ogrzewanym pomieszczeniu o w miarę stałej temperaturze i podlega normalnym obciążeniom podczas niezbyt intensywnej pracy. Test polega na łączeniu się co ok. 300 sekund z każdym z serwerów i ośmiokrotne wysłanie i odebranie komunikatu zwrotnego. Następnie obliczam wartość DELAY (czas transmisji w obie strony) oraz OFFSET (przesunięcie czasu miedzy moim komputerem, a serwerem). Dodatkowo obliczam odchylenie standardowe każdej ósemki pomiarów.

Do wyznaczenia OFFSETu konieczna jest informacja o 4 zmiennych: T1, T2, T3 i T4. Mój komputer w chwili T1 swojego lokalnego czasu wysyła zapytanie do serwera NTP. Serwer NTP odbiera to zapytania w chwili T2 – ale wg własnego zegara. Wykonuje pewne czynności i odsyła mi komunikat w chwili T3 swojego czasu. Ja odbieram go w chwili T4 wg czasu mojego komputera. Znając te cztery czasy i zakładając, że czas oczekiwania danych w buforach wejścia/wyjścia jest pomijalny możemy policzyć, że czas transmisji sygnału do serwera i z powrotem (DELAY) wynosił w sumie (T2-T1)+(T4-T3). Prawdziwy OFFSET będzie zawarty w przedziale ( T2-T1-DELAY, T2-T1 ). Ponieważ nie ma prostego sposobu, by znaleźć dokładną wartość OFFSETu, przyjmuje się za jego wartość środek tego przedziału. Odpowiada to sytuacji, w której transmisja do i z serwera zajmuje tyle samo czasu – co zwykle nie jest prawdą, ale niestety trudno o lepsze przybliżenie bez złożonych operacji analizy sieci. Zatem o dokładności naszego wyniku decyduje wartość DELAY – im bliższa zeru tym lepiej.

Przyznam się, że po pierwszych kilkudziesięciu godzinach obserwacji byłem lekko skonfundowany – wydawało się, że mogę wyróżnić kilka grup zegarów atomowych, chodzących ze stałym opóźnieniem względem siebie: polskie + kanadyjskie w jednej grupie, niemieckie, francuskie i amerykańskie w drugiej, rosyjskie w trzeciej, a japońskie w czwartej. Były to wszystko serwery oficjalne, rządowe lub głównych instytucji w danym kraju. Opóźnienia nie są jakieś ogromne – wynoszą rzędu tysięcznych lub setnych części sekundy, ale są niemal niezmienne w czasie. Zadziwiające. Każdy kraj ma swój czas atomowy i nie chce ustąpić? A może jakieś kwestie wojskowe? Wszystko wyjaśniło się, gdy do wykresu dodałem widełki DELAY. Okazało się, że opóźnienie OFFSET liczone dla najbliższego mi serwera (a więc z najmniejszą wartością DELAY, ergo teoretycznie z najmniejszym błędem) znajduje się w granicach wyznaczonych przez margines błędu pozostałych serwerów, a przesunięcia średniej wartości OFFSETu dla tych serwerów o te tysięczne części sekundy wynikają z niesymetryczności prędkości do i z serwera. I tak, największy iloraz prędkości do serwera w stosunku do prędkości z serwera notuje serwer japoński, po drugiej stronie są serwery niemieckie, francuskie i amerykańskie, a najwolniejszy w transmisji powrotnej jest serwer rosyjski. Co ciekawe, serwery kanadyjskie zachowują się symetrycznie – czas transmisji w obie strony jest porównywalny.

Wartościową obserwacją jest też to, że polskie rządowe serwery (tempus1.gum.gov.pl, tempus2.gum.gov.pl) wydają się przeciążone – chociaż czasy odpowiedzi mają nieco krótsze od serwerów niemieckich czy francuskich (w końcu jestem w Polsce!) to odsetek zerwanych lub nienawiązanych połączeń jest większy. Na tyle duży, że eliminuje je jako podstawowy serwer czasu dla moich zastosowań. Tylko 13% prób nawiązania połączenia zwróciło pełnowartościową odpowiedź. Na szczęście jest całkiem sporo dobrych polskich serwerów czasu, dobrze zsynchronizowanych z czasem atomowym i łatwiej dostępnych (a także kilka, których lepiej unikać!).

Pora na najważniejszą informację, czyli dokładność. Najprościej rzecz ujmując, korzystając z serwerów NTP, przy zastosowaniu kilku trików jestem w stanie określić OFFSET z dokładnością +/- 0.002 s. Korzystając tylko z polskich serwerów rządowych byłoby to +/- 0.004 s, niemieckich bądź francuskich 0.018 s, kanadyjskich 0.05 s, amerykańskich 0.07 s, rosyjskich 0.034 s, japońskich 0.13 s. Oczywiście nie ma co przywiązywać się do tych liczb, sieć zmienna jest. Taka dokładność w zupełności mi wystarcza. Triki, o których wspomniałem to analiza danych z kilku serwerów, wykonywanie serii 8 pomiarów dla każdego z nich i wybór najmniejszego DELAY, a także wyznaczenie krzywej zależności OFFSETu od czasu i testowanie czy pomiar nie odbiega od niej zanadto (w stałych warunkach uzyskiwałem wykres liniowy z drobnymi wahaniami). Wszystko to można wykonać w czasie 2-3 sekund.

I na koniec jeszcze jeden wniosek praktyczny. Chyba nie ma sensu zbyt często synchronizować czasu komputera z zegarami sieciowymi. Lepiej mierzyć OFFSET i go zapamiętywać obok czasu systemu operacyjnego. Z kilku powodów otrzymuje się wówczas lepszą dokładność. Dlaczego? O tym następnym razem.

Add a Comment

Your email address will not be published.