Służba czasu

pexels-photo

Wczoraj miałem bardzo ciekawe spotkanie w Obserwatorium UAM w Poznaniu. Miałem okazję porozmawiać z ludźmi, którzy obserwują i badają planetoidy (i nie tylko) zawodowo. Może coś fajnego z tego spotkania wyniknie.

Jednym z luźniejszych wątków były techniki obserwacyjne stosowane wobec szybko poruszających się obiektów, w tym tzw. służba czasu. Od dawna wiercił mi dziurę w brzuchu problem, czy czas systemu operacyjnego rejestrowany jako czas wykonania zdjęcia jest wystarczająco precyzyjny. Pomijam tu obserwacje zakryć, dla których oczekiwana dokładność to ok. 1/40 sekundy – wymaga to stosowania inserterów czasu GPS łączonych z sygnałem z kamer analogowych. Inna bajka. Przy obserwacjach astrometrycznych szybkich planetoid typu NEO o prędkościach rzędu 1000″/godzinę i oczekiwanej dokładności pomiaru 0.1″, dokładność rejestracji czasu powinna wynosić ok. 0.4 s.

Powszechnie stosowanym protokołem służącym do synchronizacji czasu komputerów jest Network Time Protocol (NTP), w wersji uproszczonej stosowany m.in. w systemie Windows (jako Simple NTP). Najprościej mówiąc, komputer użytkownika łączy się z komputerem wzorcowym, pobiera z niego czas, uwzględniając czas transmisji. W sieci dostępnych jest sporo klientów, także dla systemu Windows, wykonujących to zadanie. Jednym z najpopularniejszych jest np. Dimension 4. Pomiędzy synchronizacjami czas utrzymywany jest przez wewnętrzny zegar lokalnego komputera.

Historia pracy aplikacji Dimension 4 na moim komputerze (Windows 10) wskazuje, że w ciągu 10 minut program może zarejestrować fluktuację błędu czasu nawet w wymiarze 0.5 sekundy. Sądzę, że jest to albo błąd stosowanej metody – po 4 dobach bez synchronizacji błąd wynosił 2 sekundy. Nie znam szczegółów implementacji NTP w Dimension 4, ale wydaje się, że pojedyncze odczytanie czasu z jednego serwera może być obarczone sporym błędem wynikającym  z niesymetryczności czasów transmisji (do i z serwera czasu) oraz nieznanych opóźnień operacji wejścia-wyjścia, zarówno na moim komputerze jak i na serwerze.

Zamiast więc synchronizować czas mojego systemu operacyjnego z serwerami czasu w sieci, w Agrafce postanowiłem zaimplementować inną metodę: przed wykonaniem serii zdjęć danej planetoidy (zwykle ok. 5) łączę się z preferowanymi serwerami czasu i wykonuję 8 pobrań wzorca czasu. Robię to tuż przed uruchomieniem każdej serii – od pobrania czasu do wykonania zdjęcia mija kilka sekund. Zakładam, że w tak krótkim czasie zegar nie zdąży się rozsynchronizować. Okrągła liczba 8 😉 zawarta jest w dokumentacji NTP. W zasadzie nie wiem czemu 8, a nie 6 albo 10. Przyjąłem 8 za minimum i kropka! Jeśli serwer nie zechce mi odpowiedzieć 8 razy pod rząd (a zdaje się, że niektóre serwery nie chcą dla zasady), to odczytuję z kolejnego. Na koniec – nie, nie wyciągam średniej! Algorytm opisywany przez deweloperów NTP zakłada, że spośród tych 8 wybieram ten, z najkrótszym czasem transmisji sygnału przez sieć i z niego obliczam offset czasu. Dalej, zamiast regulować czas systemu operacyjnego, zapisuje informację o offsecie (a także parę innych szczegółów, m.in. odchylenie standardowe na tych 8 próbach) razem ze zdjęciem. Ponieważ wykonuję zwykle ponad 100 serii zdjęć na noc, błędy (nawet przy tak restrykcyjnym podejściu mogą się zdarzyć) będą łatwe do wychwycenia.

Algorytm jest już zaimplementowany w Agrafce i czeka na bezchmurną noc. Będę informował.

Add a Comment

Your email address will not be published.