Badania sygnałów czasu sterowanych protokołem NTP

Transkrypt

1 Badania sygnałów czasu sterowanych protokołem NTP Andrzej Dobrogowski, Mieczysław Jessa, Michał Kasznia, Krzysztof Lange Politechnika Poznańska, Katedra Systemów Telekomunikacyjnych i Optoelektroniki Słowa kluczowe: protokół NTP, sygnał czasu Abstrakt - W pracy przedstawiono zagadnienia związane z oceną jakości sygnałów czasu pozyskiwanych z protokołu NTP. Przedstawione zostały zasady oraz program prowadzonych badań. Przedstawiono statystyczne wyniki badań zachowania się protokołu NTP. Opisane zostały metody pozyskiwania fizycznego sygnału czasu sterowanego protokołem NTP oraz stanowiska pomiarowe do pomiaru jakości tego sygnału. 1. Wprowadzenie W świecie wraz z rozwojem infrastruktury informatyczno telekomunikacyjnej rośnie zapotrzebowania na dostępne i wiarygodne źródła sygnałów czasu. PoniewaŜ cena wzorców czasu i towarzyszących im urządzeń jest bardzo wysoka, to w sposób oczywistym rozwiązaniem wydaje się przesyłanie sygnału czasu z tych wzorców z wykorzystaniem istniejącej infrastruktury. Podstawowym sposobem skorzystania z tej idei jest zastosowanie w sieciowego protokołu czasu NTP. Obecnie jest dostępna 5 wersja tego protokołu (wersja NTP 4, pierwsza wersja miała numer 0) opracowanego przez Davida Millsa w 1988 roku [1, 2]. Wpływ na jakość sygnału czasu pozyskiwanego przez protokół NTP z danego serwera mogą mieć róŝnorodne czynniki, między innymi poziom stratum serwera (liczba pośrednich serwerów, przez które podłączony jest serwer do wzorca czasu), przeciąŝenie sieci w zaleŝności od pory dnia, oprogramowanie i system operacyjny komputera podłączonego do sieci. Protokół NTP (ang. Network Time Protocol) jest protokołem sieciowym umoŝliwiającym programowe ustawienie czasu zegara systemowego komputera z serwera czasu podłączonego do sieci Internet. Serwer czasu jest komputerem synchronizowanym do atomowego wzorca czasu. Liczba komputerów pomiędzy serwerem i wzorcem atomowym określa poziom stratum serwera czasu. NTP nie przesyła sygnału czasu, a tylko róŝnice czasu pomiędzy zegarem serwera i zegarem systemowym komputera klienta. Funkcjonowanie protokołu NTP najprościej moŝna zauwaŝyć w systemie Windows klikając w pole z godziną znajdujące się zazwyczaj w dolnym prawym lub górnym rogu ekranu. Przedstawia to Rys. 1. Rys.1. Czas z NTP w systemie Windows (po lewej) i dane szczegółowe synchronizacji (po prawej) Jak wynika porównania wskazań na Rys. 1, synchronizacja czasu przeprowadzana przez protokół NTP zachodzi w odstępach około 10-dniowych. Odstęp ten jest wystarczający dla odstępu minutowego, z jakim jest wyświetlany czas na ekranie, natomiast dla otrzymania lepszej rozdzielczości zachodzi potrzeba częstszego synchronizowania. W tym miejscu naleŝy zastosować inne procedury od proponowanych w tym miejscu przez Windows. 1

2 2. Program badań Przeprowadzone badania obejmowały dwa zagadnienia: badania statystyczne pozyskiwania informacji o czasie z róŝnych serwerów czasu z protokołem NTP oraz badania fizycznego sygnału czasu wyprowadzonego na złącze COM komputera synchronizowanego protokołem NTP. W obu przypadkach zastosowano oprogramowanie umoŝliwiające pozyskanie danych statystycznych o pracy protokołu z poszczególnymi serwerami (w pierwszym przypadku), oraz uzyskanie fizycznego sygnału czasu (w drugim przypadku), który moŝna nazwać sekundą NTP związaną z konkretnym serwerem. Przeprowadzone w pierwszym przypadku badania statystyczne umoŝliwiły porównanie poszczególnych serwerów w przekroju godzin i dni pod kątem pomiaru czasu trwania procedury NTP [3]. W drugim przypadku badano fizyczne sygnały czasu porównując połoŝenie sekundy NTP względem sygnału odniesienia (w tym przypadku sygnału pochodzącego z odbiornika sterowanego sygnałami systemu GPS) dla róŝnych serwerów i roŝnych parametrów procesu synchronizacji. Badania statystyczne przeprowadzono dla komputerów pracujących pod kontrolą systemu operacyjnego MS Windows, natomiast badania fizycznego sygnału czasu wykonano z wykorzystaniem komputerów pracujących w systemie Linux. Powodem tego zróŝnicowania były problemy z uzyskaniem odpowiedniej jakości generowanego sygnału czasu w systemie Windows. Zasadniczym powodem trudności w tym obszarze było kontrolowanie przesłania taktu zegara systemowego synchronizowanego przez NTP na złącze COM. Problem ten udało się pokonać w zadowalający sposób w systemie Linux. 3. Badania statystyczne zachowania protokołu NTP W prowadzonych badaniach przyjęto podstawowe załoŝenie badania zachowania protokołu NTP będą prowadzone przy uŝyciu zwyczajnego komputera osobistego o przeciętnych parametrach technicznych z zainstalowanym systemem operacyjnym MS Windows XP. Do pozyskiwania danych wykorzystano następującą platformę programową: System operacyjny: MS Windows XP Professional SP2; Wirtualna maszyna Java: Java JRE 1.5_06; Arkusz kalkulacyjny: MS Excel 2003; Implementacja klienta protokołu NTP program napisany w języku Java. Zaletą języka Java (podobnie jak protokołu NTP) jest jego darmowość. Program wykorzystuje standardowe biblioteki tego języka dotyczące protokołu NTP, które są właściwie gotową implementacją klienta NTP. Jedyne, co naleŝało zrobić, to uŝyć tej implementacji w taki sposób, aby uzyskane wyniki miały jakąś wartość dla eksperymentu. Warto jeszcze skomentować uŝycie arkusza kalkulacyjnego Microsoft Excel 2003, który okazał się wystarczającym dla zakresu zebranych wyników w ciągu jednego tygodnia Zasady i cele prowadzonych badań Na badania składało się kilka serii eksperymentów. Równocześnie badane były dwa serwery, których stratum było znane, a więc z góry wiadomo było, który serwer teoretycznie powinien być lepszy [3]. Jedna seria eksperymentu obejmowała ciągłe wysyłanie Ŝądania na przemian do jednego i drugiego serwera NTP, w odstępie 5 sekund (czyli kaŝdy serwer otrzymywał Ŝądania co 10 sekund). Wyniki były pobierane jako znaczniki czasowe. Dzięki temu dla kaŝdego Ŝądania moŝna było określić, kiedy zostało wysłane, kiedy dotarło do serwera, kiedy na nie odpowiedziano i kiedy odpowiedź trafiła do komputera wysyłającego Ŝądanie. W ten sposób moŝna było zbadać szybkość odpowiedzi serwera porównując znaczniki czasu w momencie otrzymania przez serwer Ŝądania i odpowiedzi na niego, a takŝe badać opóźnienia w sieci, przez którą przesyłane były Ŝądania do serwera i jego odpowiedzi. Wyniki te z wszystkich serii moŝna porównywać, gdyŝ były otrzymywane w tych samych warunkach. Dzięki temu zbadano, który serwer pracuje najlepiej w praktyce, czyli uwzględniając nie tylko stratum, ale zachowanie protokołu NTP w sieci Internet [5, 6]. Lista badanych serwerów NTP, połączonych w pary (1 z 2, 3 z 4, 5 z 6, 7 z 8) przedstawiona jest w Tablicy Format danych i procedura badań KaŜda seria badań generowała dwa pliki wynikowe jeden z nich zawierał znaczniki czasu w wersji wygodnej do natychmiastowej weryfikacji poprawności otrzymanych danych, zawiera, bowiem datę i godzinę zapisaną przy uŝyciu tekstu i cyfr. Wymagało to przekształceń, które umoŝliwiły rozwinięcie uzyskanych wyników w liczbę milisekund, które upłynęły od 1 stycznia 1900 roku (początek odliczania znaczników czasowych w NTP), do 1 stycznia 1970 roku (początek odliczania znaczników systemu Unix). Powodem takiego przedstawiania wyników w postaci liczby było uŝycie w implementacji klienta NTP standardowej funkcji języka Java (gettime), która to działała według standardów systemu Unix. Fragment arkusza z danymi liczbowymi przedstawia Rys. 2. 2

3 Tabl. 1. Lista badanych serwerów NTP Nazwa serwera Adres IP serwera Stratum serwera 1 vega.cbk.poznan.pl ntp.nask.pl ntp.icm.edu.pl ntp.task.gda.pl info.cyf-kr.edu.pl ntp.man.poznan.pl tempus1.gum.gov.pl ucirtr.agh.edu.pl Rys. 2. Wygląd pliku wyjściowego w postaci rozwiniętej dla: wiersza 3 i kolumny F Podsumowując opis formatu danych w plikach wyjściowych, naleŝy podkreślić, Ŝe: Dla obliczeń statystycznych postać czasowa danych wyjściowych nie jest wygodna. Postać liczbowa powstaje przez zamianę czasu na liczbę milisekund z uwzględnieniem punktu początkowego na dzień 1 stycznia 1970, godz. 00:00:00 (notacja UNIX) Korekta dla NTP wymagała dodania s, co uwzględnia początek wskaźników NTP od dnia 1 stycznia 1990 godz. 00:00:00. W sześciu pierwszych kolumnach (w kolumnach A-F) przedstawione są wyniki dotyczące pierwszego serwera, potem następuje wolna kolumna (kolumna G) i w następnych sześciu są wyniki dotyczące drugiego serwera (w kolumnach H-M). Relacje pomiędzy znacznikami przedstawia Rys. 3. Czas serwera T2 T3 Czas klienta T1 T4 Rys. 3. Relacje między znacznikami czasowymi z podziałem na czas klienta i czas serwera T1 znacznik czasu wysłania wiadomości przez klienta (orginate timestamp) T2 znacznik czasu otrzymania wiadomości przez serwer (reseive timestamp) T3 znacznik czasu wysłania wiadomości przez serwer (transmit timestamp) T4 znacznik czasu otrzymania wiadomości przez klienta (destimation timestamp) W wyniku przeprowadzonych badań otrzymano bardzo duŝą ilość wyników. UmoŜliwiają one porównania pomiędzy sobą róŝnych wzorców w przedziałach czasowych od pojedynczych minut do tygodnia, gdyŝ taki był najdłuŝszy przedział czasu obserwacji. Badaniami objęto: Czas potrzebny serwerom na wygenerowanie odpowiedzi (T3 T2), w przekroju godzin w ramach doby i dni tygodnia dla wszystkich serwerów. Czasu uzyskania odpowiedzi z serwerów NTP (T4 T1), w przekroju godzin w ramach doby i dni tygodnia dla wszystkich serwerów Wyniki badań czasu przebywania protokołu NTP w serwerach podczas 1 doby Badania oceny czasu przebywania zapytania o czas w serwerach NTP przeprowadzono w dwóch seriach. Wyniki badań zostały zestawione w Tablicy 2 i przedstawione w postaci histogramów [6]. Ze względu na występujące pomiędzy serwerami rozrzuty uzyskanych rezultatów część wynikową podzielono na 4 kolumny, w których pogrupowano odpowiednio wyznaczone w pomiarze czasy oraz przedstawiono wyliczony czas średni. 3

4 Lp Nazwa serwera Tabl. 2. Czas przebywania zapytania w serwerze Średni czas generowania odpowiedzi w ciągu całego badania [ms] Średni czas generowania odpowiedzi w wybranym dniu [ms] I seria II seria I seria II seria 1 vega.cbk.poznan.pl 0,032 0,031 0,026 0,036 2 ntp.nask.pl 0,929 1,083 0,962 1,074 3 ntp.icm.edu.pl 0,036 0,037 0,031 0,057 4 ntp.task.gda.pl 0,049 0,486 0,039 0,393 5 info.cyf-kr.edu.pl 0,239 0,241 0,221 0,258 6 sunflower.man.poznan.pl 0,086 0,092 0,106 0,118 7 tempus1.gum.gov.pl 0,09 0,011 0,075 0,08 8 ucirt.agh.edu.pl 0,012 0,011 0,019 0,015 Histogram ilustrujący te relacje uwzględniający średni dobowy czas odpowiedzi poszczególnych serwerów przedstawia Rys. 4. Rys. 4. Średni dobowy czas odpowiedzi poszczególnych serwerów NTP W drugiej serii czas trwania badań wynosił 1 tydzień. Pozwoliło to na ocenę zachowania się badanego czasu w poszczególnych dniach tygodnia. Średni dobowy czas przebywania informacji NTP w serwerze nie precyzuje tego czasu dla kaŝdej godziny. Przykładowe dobowe histogramy dla serwerów stratum 1 i stratum 3 przedstawia Rys. 5, natomiast tygodniowe badania przedstawia Rys. 6. Rys. 5. Histogramy czasu przebywania zapytania w ujęciu dobowym dla serwerów tempus1.gum.gov.pl (stratum1, po lewej) i ucitr.agh.edu.pl (stratum 3, po prawej) Rys. 6. Histogramy czasu przebywania zapytania w ujęciu tygodniowym dla serwerów tempus1.gum.gov.pl (stratum1, po lewej) i ucitr.agh.edu.pl (stratum 3, po prawej) 3.4. Wnioski z przeprowadzonych badań Podsumowując badania czasu przebywania zapytania w serwerze, moŝna zauwaŝyć, Ŝe: Na stabilność serwera oraz na szybkość generowania odpowiedzi nie miał wielkiego wpływu fakt, czy dany dzień badań był dniem roboczym czy nie. 4

5 Nie potwierdziło się, Ŝe serwer o najkrótszym czasie generowania odpowiedzi jest równocześnie najbardziej stabilny. Na czas przebywania zapytania w serwerze nie ma wpływu poziom stratum serwera; zdarza się, Ŝe serwer o lepszym stratum ma gorsze wyniki. Statystycznie czasy odpowiedzi serwerów mieszczą się w 100 µs Badania czasu przebywania protokołu NTP w systemie Zakres badań czasu przebywania protokołu NTP w systemie obejmował pomiary odstępu czasu pomiędzy zapytaniem klienta do serwera czasu i odebranie odpowiedzi, czyli przedział czasów T4 T1, (tak jak to przedstawia Rys. 3) oraz ocenę wyników w przekroju poszczególnych godzin w ramach doby i poszczególnych dni w ramach tygodnia. Badania przeprowadzono w dwóch seriach. Zestawienie wszystkich próbek z obu serii badań przedstawia Tablica 3. W pierwszej serii badano serwery w trybie badań dobowych, koncentrując się na określeniu wpływu pory dnia na uzyskane wyniki czasów opóźnienia wprowadzanych przez serwery i sieć Internet. W drugiej serii badań czas pomiarów pary serwerów przedłuŝono do tygodnia. UmoŜliwiło to badanie rozkładu czasów wynikającego z przebywania protokołu w systemie dla poszczególnych dni tygodnia nie tracąc przy tym ujęcia dobowego. Z licznych wykonanych pomiarów dla wszystkich serwerów przedstawiono histogramy dla serwera tempus1.gum.gov.pl (stratum 1) i serwera ucitr.agh.edu.pl (stratum 3). Lp Tabl. 3. Średni czas przebywania zapytania w systemie dla I i II serii badań Nazwa serwera Średni czas generowania odpowiedzi w ciągu całego badania dla wszystkich próbek [ms] Średni czas generowania odpowiedzi w wybranym dniu dla wszystkich próbek [ms] I seria II seria I seria II seria 1 vega.cbk.poznan.pl 25,812 22,991 24,459 21,759 2 ntp.nask.pl 15,638 15,945 14,234 14,089 3 ntp.icm.edu.pl 70,875 13,794 65,168 11,376 4 ntp.task.gda.pl 76,985 31,910 44,734 36,511 5 info.cyf-kr.edu.pl 79,665 19,420 68,791 14,007 6 sunflower.man.poznan.pl 82,134 17,272 42,084 12,954 7 tempus1.gum.gov.pl 63,639 14,949 56,237 15,619 8 ucirt.agh.edu.pl 67,430 19,277 47,248 19,697 Zestawienie czasów odpowiedzi dla wszystkich badanych serwerów przedstawia Rys. 7. Rys. 7. Średni tygodniowy czas przebywania zapytania w systemie dla próbek prawidłowych (w 1 rzędzie) oraz błędnych i opóźnionych powyŝej 100ms (w 2 rzędzie) dla wszystkich serwerów Podsumowanie wyników badania czasu przebywania protokołu NTP w systemie Podsumowując badania czasu przebywania protokołu NTP systemie moŝna sformułować następujące wnioski: Na pracę systemu ma wpływ pora dnia. Jest to czynnik wspólny dla wszystkich serwerów czasu i wynika z oddziaływania obciąŝenia sieci Internet w godzinach szczytu. Na pracę systemu ma równieŝ wpływ dzień tygodnia, ale wpływ ten jest róŝny dla poszczególnych serwerów czasu i zaleŝy od ich lokalizacji. Całkowity czas przebywania w systemie procedury NTP nie zaleŝy istotnie od poziomu stratum serwera. Liczba opóźnionych i zgubionych próbek, czyli tych uznanych za błędne zaleŝy od poziomu stratum serwera i jest większa dla wyŝszego stratum. 5

6 Nie występuje istotna relacja pomiędzy dniem tygodnia i najdłuŝszym czasem przebywania protokołu w systemie, chociaŝ środa, czwartek i piątek w badaniach wykazały najwięcej błędnych próbek. Nie zawsze liczba traconych próbek przypada w tym samym czasie, co liczba próbek opóźnionych. Wskazuje to na róŝne przyczyny tych zjawisk. Dla rozkładu próbek bez błędów nie ma wpływu, czy jest aktualnie dzień roboczy, czy dzień wolny od pracy.wnioski z badań pracy protokołu NTP w krajowej sieci Internet W referacie przedstawiono, ze względu na brak miejsca niewielką liczbę wyników zawartych w opracowanych tabelach i histogramach. Uzyskano wyniki dla wszystkich par serwerów. Stąd uogólnienia, które przedstawiono w punkcie 3.6 dotyczą wszystkich badań, a nie tylko wyników dla dwóch przykładowych serwerów. Przeprowadzone badania wykazały bardzo istotny wpływ obciąŝenia sieci Internet na czas przebywania protokołu w systemie. MoŜna to zauwaŝyć w Tablicy 3 w wynikach porównań badań z I i II serii. Dotyczy to długości czasu odpowiedzi i liczby próbek traconych, których statystyk nie zamieszczono. Badania czasu przebywania protokołu w serwerze wykazały niewielki jego wpływ dla dokładności pozyskiwania czasu w przedziałach milisekundowych i istotny dla dokładności w przedziałach mikrosekundowych. 4. Wyprowadzenie sygnału czasu sterowanego protokołem NTP na złącze zewnętrzne komputera 4.1. Przesłanki do pozyskania fizycznego sygnału czasu sterowanego z protokołu NTP Opisane w rozdziale 3 działania pozwoliły na uzyskanie olbrzymiej liczby wyników. Przedstawiona w nich analiza nie wyczerpuje wszystkich informacji, które uzyskano w wyniku badań. Forma wyników w postaci plików arkusza MS Excel umoŝliwiła ich analizę, porównania i zestawienia graficzne w postaci histogramów. MoŜna oczywiście takŝe sporządzić wykresy ilustrujące przebiegi przebywania protokołu NTP w serwerach czasu i w systemie. Jednak te działania są niezwykle czasochłonne. Badania statystyczne funkcjonowania protokołu NTP nie przynoszą pełnego obrazu problemu pozyskiwania czasu z sieci Internet. Nasuwa się oczywista potrzeba wykorzystania protokołu NTP jako źródła sygnału czasu funkcjonującego poza strukturą komputera. W tym celu naleŝy wyprowadzić sygnał czasu na złącze zewnętrzne komputera. Układ pomiarowy do badania fizycznego sygnału czasu zrealizowany został w sposób następujący. Komputer z zainstalowanym oprogramowaniem umoŝliwiającym zsynchronizowanie się do czasu NTP oraz generację sygnału jest podłączony do sieci Internet. Dane wyjściowe wysyłane są na port COM1 komputera pakiet czasowy (pin nr 3) oraz impulsy 1 pps (pin nr 4). Uzyskany sygnał 1 pps porównywany jest z sygnałem odniesienia (takŝe 1 pps) generowanym przez układ sterowany sygnałami systemu GPS. Miarą róŝnicy chwil badanego sygnału względem sygnału odniesienia (błędem czasu) jest szerokość impulsów T na wyjściu modułów pomiarowych, wyzwalanych chwilami znaczącymi sygnałów 1 pps. Ta szerokość impulsów jest mierzona w kaŝdej sekundzie przez specjalistyczną kartę pomiarową. Odniesienie się w pomiarze sygnału czasu pozyskanego z protokołu NTP do sygnału referencyjnego z systemu GPS umoŝliwia chwilowy pomiar połoŝenia znacznika kaŝdej sekundy NTP, a takŝe wykrywa ich bezpośrednią relację względem czasu UTC, który jest powiązany z czasem GPS stałą relacją. Schemat blokowy tego układu jest przedstawiony na Rys. 8. Komputer Windows Dane wyjściowe Odbiornik GPS Dane wyjściowe Komputer Windows Karta pomiarowa GPS GPS Karta pomiarowa T 1pps 1pps T Moduł pomiarowy Moduł pomiarowy Komputer Linux 1pps Sekunda NTP Sekunda NTP 1pps Komputer Linux Stanowisko 1 Stanowisko 2 Internet Rys. 8. Schemat układu pomiarowego do badania sygnału czasu z NTP 6

7 4.2. Ustawianie czasu z protokołu NTP Do ustawiania czasu NTP wykorzystywany jest program ntpdate. Jest to unixowy program działający samodzielnie, bez konieczności jakiejkolwiek zewnętrznej konfiguracji oraz usług systemowych. Program ntpdate wchodzi w skład standardowego pakietu NTP słuŝącego do synchronizacji czasu w systemach unixowych oraz windowsowych i jego działanie jest zgodne aktualnymi procedurami synchronizacji. W opisywanym zastosowaniu do synchronizacji czasu uŝywany jest skrypt, który korzysta z polecania ntpdate : #!/bin/bash interval=$1 # pierwszy parametr skryptu to odstęp miedzy synchronizacjami time_server=$2 # drugi parametr skryptu to nazwa serwera while : # nieskończona pętla do ntpdate -b $time_server # synchronizuj czas z zadanym serwerem sleep $interval # wstrzymaj działanie skryptu na zadany czas done Wywołanie skryptu przyjmuje postać:./sync.sh vega.cbk.poznan.pl 10 Pierwszym parametrem wywołania jest odstęp w sekundach pomiędzy synchronizacjami czasu. Drugim parametrem jest adres serwera, z którego ma nastąpić synchronizacja. Parametr -b występujący w skrypcie po poleceniu ntpdate nie ma wpływu na interwał, czy moment synchronizacji, wymusza jedynie skokową zmianę czasu systemowego (natychmiastowe przestawienie). Uruchomienie ntpdate bez tego przełącznika powoduje ustawienie czasu przez spowolnienie zegara. Efekt działania skryptu synchronizacji, ustawiony przykładowo na 10 sekundowy interwał jest następujący: 2 Nov 11:23:18 ntpdate[17247]: step time server offset sec 2 Nov 11:23:28 ntpdate[17253]: step time server offset sec 2 Nov 11:23:38 ntpdate[17264]: step time server offset sec 4.3. Generowanie impulsu 1 pps na wyjściu szeregowym Mając zapewniony prawidłowy i synchronizowany (przy uŝyciu programu ntpdate ) z NTP czas zegara systemowego, zastosowano linuxowy program OneShot do przeniesienia impulsu 1 pps z zegara komputera na wyjście portu szeregowego. Realizacja tego procesu w systemie operacyjnym Linux zapewnia bardziej precyzyjną kontrolę nad przesyłaniem impulsów zegarowych niŝ w przypadku systemu MS Windows [2]. W tym celu wykorzystywany jest sygnał DTR (data transfer ready), który wybrany został ze względu na łatwość obsługi zdarzenia z poziomu programu napisanego w języku C. Nie ma potrzeby ustawiania parametrów portu, wystarcza jedynie podanie jego nazwy (np. COM1). Nie jest to wiec przysyłanie Ŝadnej informacji wymagającej czytania po stronie odbiornika kodów ASCII, a tylko na wybranym pinie (w tym przypadku 4) zmienia się napięcie, które odtwarza sygnał 1 pps. Uruchomiony program OneShot pobiera czas systemowy z rozdzielczością 1 µs, a następnie wylicza odstęp czasu do następnej sekundy. Gdy ten czas mija, wysłany zostaje impuls na port szeregowy, po czym następuje kolejne wyliczenie czasu w µs do następnej sekundy. Po upływie tak obliczonego czasu zostaje wysłany impuls na port szeregowy, po czym procedura się powtarza. Jednosekundowe przeliczanie czasu gwarantuje uwzględnienie synchronizacji z protokołu NTP. JuŜ w kolejnej sekundzie po przestawieniu zegara systemowego program jest w stanie przedstawić wszystkie zmiany wynikające z przyspieszania lub zwalniania zegara systemowego. W ten sposób program stara się dostosować wysyłany impuls do stale synchronizowanego zegara komputera. Do pobierania czasu zegara systemowego uŝywana jest standardowa unixowa funkcja języka C gettimeofday [7, 8]. Funkcja ta pobiera aktualny czas i przestawia go w postaci przesunięcia czasu od tzw. czasu unixowego, zwanego równieŝ Epoką. Zachodzi w tym miejscu podobna realizacja jaka została opisana w podrozdziale 3.2. Przesunięcie to jest reprezentowane przez czas, który upłynął od 1 stycznia 1970 roku. Czas ten jest podany w postaci struktury (paczki), z której moŝna bezpośrednio pobrać czas w µs, który upłynął od ostatniej pełnej sekundy: liczba µs do kolejnej sekundy (T µs) = liczba µs od poprzedniej sekundy (T µs) (1) Na podstawie tego czasu obliczany jest czas, w którym naleŝy wysłać kolejny impuls na port szeregowy. Jest to wykonane w następujący sposób. Zostaje utworzony licznik (moŝna to porównać do alarmu), który po upływie zadanych µs (T µs) uruchamia procedurę wysyłania impulsu na port szeregowy. Jest to licznik odmierzający czas do kolejnej sekundy oparty o unixowy setitimer [7, 8]. Jest to funkcja, która odmierza upływający czas rzeczywisty i generująca alarm po jego upływie. Pomiar czasu rzeczywistego oznacza, Ŝe nawet gdy działanie programu zostanie wstrzymane przez system, licznik będzie nadal pracować i odmierzać czas do kolejnej sekundy. Działanie programu OneShot przedstawia diagram na Rys. 9. 7

8 Oblicz czas w µ s do kolejnej sekundy T Ustaw alarm na czas T tak Czas minął? nie Czekaj Wyślij sygnał na złącze szeregowe 4.4. Wyniki pomiarów Rys. 9. Algorytm działania programu OneShot Wykorzystane na stanowisku pomiarowym komputery z systemem operacyjnym Linux, oprócz współpracy z siecią Internet i generowania przy pomocy programu OneShot impulsu 1 pps synchronizowanego protokołem NTP, umoŝliwiają takŝe podgląd uzyskanych rezultatów synchronizacji czasu. Obrazują to zrzuty ekranowe wirtualnych terminali z wynikami offsetu pomiędzy zegarem wewnętrznym komputera i serwerem NTP przedstawione na Rys. 10. Rys. 10. Wielkości offsetu [µs] pomiędzy sekundą NTP i serwerem czasu dla zegara komputerowego (dane po lewej stronie) i protokołu NTP (dane po prawej stronie) Wyprowadzony na złącze komputera sygnał 1 pps porównywany był (zgodnie ze schematem na Rys. 8) z sygnałem odniesienia uzyskanym z generatora sterowanego sygnałami systemu GPS. Przykładowy przebieg błędu czasu pomiędzy sygnałem sterowanym protokołem NTP i sygnałem odniesienia przedstawiony jest na Rys TE [s] t [s] Rys. 11. Przebieg błędu czasu dla sygnału 1 pps sterowanego protokołem NTP 8

9 5. Podsumowanie ZałoŜone w pracy cele udało się osiągnąć. Opracowano programy do badań statystycznych funkcjonowania protokołu NTP współpracującego z grupą wybranych krajowych serwerów czasu i przeprowadzono szereg badań zakończonych istotnymi wnioskami. Opracowano i wykonano specjalistyczne stanowisko do badania sygnałów czasu równocześnie z dwóch serwerów czasu NTP. Udało się równieŝ uzyskać zadowalające przeniesienie sygnału czasu z synchronizowanego protokołem NTP zegara komputera na jego złącze wyjściowe. Przeprowadzono pomiary sygnału czasu na wyjściu komputera uzyskując wyniki zapewniające moŝliwości technicznego wykorzystania takiego źródła czasu w aplikacjach zadawalających się dokładnością czasu na poziomie milisekundy. Potwierdziło się występowanie zakłóceń pochodzących od sieci Internet, co udokumentowały badania statystyczne i potwierdziły pomiary bezpośredniego sygnału czasu na wyjściu komputera. Przedstawia to wykres błędu czasu z zakłóceniami w postaci pików na Rys. 11. Uzyskane rezultaty mogą zostać wykorzystane do monitorowania pracy serwerów NTP, do pozyskania z Internetu fizycznego sygnału czasu, który umoŝliwi porównywanie sygnałów czasu z innymi jego źródłami, synchronizowanie innych zegarów oraz konstrukcję prostych zegarów wyświetlających czas synchronizowany przez serwery NTP. Bibliografia [1] Mills D. L.: Precision synchronization of computer network clocks, ACM Computer Communication Review 24, April 1994 [2] Mills D. L.: Network Time Protocol Version 4. Reference and Implementation Guide, NTP Working Group Technical Report , University of Delaware, June 2006 [3] Kuich-Zalejko O.: Badania sygnału czasu z wybranych serwerów NTP, Praca magisterska, Politechnika Poznańska, Wydział Elektroniki i Telekomunikacji, Poznań 2007, (promotor: dr inŝ. Krzysztof Lange) [4] Maniewski M.: Badania sygnału czasu pozyskanego z protokołu NTP, Praca magisterska, Politechnika Poznańska, Wydział Elektroniki i Telekomunikacji, Poznań 2008, (promotor: dr inŝ. Krzysztof Lange) [5] Dobrogowski A., Jessa M., Kasznia M., Lange K.: Wybrane badania sygnałów czasu sterowanych protokołem NTP, Przegląd Telekomunikacyjny + Wiadomości Telekomunikacyjne, 2009, nr 8-9 str [6] Dobrogowski A., Jessa M., Kasznia M., Lange K.: Results of evaluation of time signals receiving from NTP servers in Poland, Proc. of 24 th European Frequency and Time Forum, April 2010, Noordwijk, Netherlands [7] SETITIMER(2) Linux Programmer's Manual [8] GETTIMEOFDAY(2) Linux Programmer's Manual 9