Problematyka protokołu PTP

Standard PTP (Precision Time Protocol) opisuje podejście do procesu synchronizacji urządzeń w nowoczesnych sieciach komputerowych. Standard ten jest dobrym przykładem radzenia sobie ze skomplikowanym zagadnieniem synchronizacji czasu poprzez dzielenie go na szereg mniejszych części, które da się rozwiązać w elegancki i przejrzysty sposób. W tym artykule przedstawię problemy, z jakimi musieli zmagać się twórcy standardu, aby wypracować rozwiązania, które spełniają pokładane przez użytkowników oczekiwania.

Informacje na start

We współczesnych sieciach komputerowych istnieje potrzeba, żeby wiele urządzeń działało, mając jedną wspólną bazę czasową. Innymi słowy aby jedno urządzenie było zsynchronizowane z drugim oddalonym nierzadko na znaczną odległość. Rozpatrując zagadnienie czasu w systemach komputerowych, nie możemy jednak nie wspomnieć o częstotliwości i fazie. Mam na myśli częstotliwość, z jaką oscyluje zegar urządzenia. Na przykład częstotliwość 1 MHz mówi nam że zadany przebieg sygnału powtarza się milion razy na sekundę. Często urządzenia końcowe (jakimi mogą być np. sterowniki przemysłowe) co pewien ściśle określony czas mają do wykonania konkretne akcje. Jednak żeby te akcje mogły zostać zrealizowane jednocześnie na większej liczbie urządzeń, muszą one (oprócz ustawionej tej samej częstotliwości) być zsynchronizowane w fazie.

Reasumując: opisane wyżej procesy wymagają tego, aby co najmniej dwa urządzenia miały do dyspozycji sygnał zegarowy o tej samej częstotliwości i fazie oraz posiadały wspólną bazę czasową.

Realizacja tych założeń sprowadza się do wyprowadzenia sygnałów synchronizacyjnych niosących informacje o częstotliowści oraz fazie. Może to być sygnał o danej wartości na przykład 10MHz lub sygnał PPS (Pulse Per Second) co sekunde generujący impuls na linii sygnałowej. Dodatkowo co pewien ściśle określony okres  może być wysłana informacja o czasie dnia za pomocą linii ToD (Time of Day) – w formacie godzina:minuta:sekunda. Kolejnym przykładem linii niosącej informacje o czasie i czestotliwości jest linia Bits (building integrated timing support ) często używana w telekomunikacji. Na poniższym obrazku przedstawione są wymienione wyżej linie dla urządzenia CISCO ASR902 RSP1.

Generalnie aby umożliwić urządzeniom proces synchronizacji wymienionych parametrów można wyprowadzć z urządzeń jedną linię z sygnałem o zadanych częstotliwości i fazie oraz drugą linię, na której będzie przesyłana informacja o aktualnym czasie (może to być magistrala szeregowa jak np. RS-485). Przykładowy model synchronizacji przedstawiłem na rysunku poniżej.

Jak widać na rysunku, wprowadzony został podział na urządzenia typu:

- Master – będące źródłem sygnału,

- Slave – urządzenie synchronizujące się do sygnału z Mastera.

Wyprowadzenie dedykowanych sygnałów, jak zostało to zrobione w powyższym modelu, może okazać się kosztownym rozwiązaniem.

Okazuje się jednak, że podobny proces można „odwzorować”, mając do dyspozycji jedynie medium przesyłające pakiety danych (packet based network), jakim jest na przykład Ethernet. Model takiego podejścia przedstawiłem na rysunku poniżej.

Protokół PTP

Przechodząc do rzeczy, skupmy się na założeniach protokołu PTP. Na wstępie zdefiniuję pojęcia, które pozwolą lepiej opisać model synchronizacji.

Każde z urządzeń, które bierze udział w procesie synchronizacji, musi być wyposażone w swój zegar. Różnica we wskazaniach dwóch zegarów w danym momencie jest nazywana offsetem między tymi zegarami. Czas liczony od wysłania pakietu do jego odbioru nazywany jest opóźnieniem łącza (link delay). Pożądanym jest aby wyniki pomiaru były jak najbardziej powtarzalne. Innymi słowy, żeby opóźnienie łącza wynosiło zawsze taką samą wartość czasu, niezależnie od tego czy rozpatrujemy pierwsze, setne czy n-te przesłanie pakietu. 

Aby zrozumieć sprawę dokładniej, należy przyjrzeć się drodze, jaką musi przejść pakiet, nim dotrze z jednej aplikacji do drugiej uruchonionej na innym urządzeniu. 

Jak widać, pakiet wysłany z aplikacji PTP musi przejść przez cały stos sieciowy. Operacja ta może trochę potrwać, ale co istotniejsze podróż pakietu przez stos sieciowy jednym razem może zająć więcej a innym razem dużo mniej czasu. W zależności od wielu parametrów pakiety mogą być przez pewien czas kolejkowane, kopiowane, wstrzymywane w stosie sieciowym.

I tutaj pojawia się pierwszy problem, który można sformułować następująco:

W jaki sposób w procesie synchronizacji pozbyć się wysoce losowego czasu przetwarzania pakietu przez stos sieciowy, zachowując przy tym założenie, że pakiety powinny być generowane na poziomie aplikacji?

Odpowiedzią jest sprzętowe wsparcie pozwalające na umieszczenie znacznika czasowego (timestamp) przypisanego do danego pakietu w momencie jego przejścia przez dany punkt, który powinien być ulokowany jak najbliżej łącza – zazwyczaj jest to pomiędzy warstwą MAC a PHY. Model tekiego rozwiązania znajduje się na rysunku poniżej:

Oczywiście rozwiązanie to wymaga wsparcia sprzętowego ze strony odpowiednich modułów analizujących ruch na linii pomiędzy warstwą MAC a PHY.  Aby mieć pełen obraz sytuacji, należy wspomnieć, że istnieją implementacje, pozwalające aplikacji PTP nie korzystać z opisanego wyżej mechanizmu wsparcia sprzętowego, wtedy operuje się na czasie dostępnym z poziomu aplikacji (Takie rozwiązanie wiązę się z pogorszeniem parametrów synchronizacji). Sprzętowe wsparcie, pozwalające na generowanie znaczników czasowych pomiędzy warstwą MAC a PHY, jest jednym z fundamentów precyzyjnej synchronizacji czasu w sieciach wykorzystujących protokół PTP.

Rodzaje pakietów występujących w domenie sieci PTP

Fundamentalną operacją urządzenia określonego w sieci PTP jako Master – wyposażonego w  zegar nadrzędny – jest wysyłanie pakietów synchronizacyjnych (Sync message). Pakiety te są wysyłane co pewien czas (sync message transmission interval) i mają na celu dostarczyć dane do urządzenia określanego jako Slave (z zegarem podrzędnym) o stanie zegara na Masterze.

Z pakietami typu sync wiąże się problem, który można sformułować następująco:

Jak w pakiecie przesłać informacje o czasie wysyłania tego pakietu (Mając na uwadze, że znacznik czasowy powinien być dodawany na styku warst MAC i PHY) skoro przed wysłaniem, należy zdefiniować jego zawartość, w której wartość tego czasu mogła by być umieszczona? Tak – istnieją rozwiązania, dające możliwość modyfikowania danego pola ze znacznikiem czasu pakietu „w locie” (i standard PTP przewiduje też taką możliwość), ale chodzi mi o zupełnie inne rozwiązanie.

Rozwiązaniem przyjętym przez twórców protokołu PTP jest w pewnym sensie obejście problemu – to bowiem pogodzenie się z faktem, że nie uda się wysłać tej informacji w tym samym pakiecie i wysłanie kolejnego pakietu (follow up), mającego już dostęp do znacznika czasowego utworzonego poprzednio przez pakiet sync. Scenariusz ten jest przedstawiony na rysunku poniżej. 

Jak można wywnioskować z zaprezentowanego wyżej rysunku po odebraniu obydwu pakietów urządzenie Slave będzie posiadało znaczniki czasów T1 (moment wysłania pakietu złapany na zegarze Mastera) oraz T2 (moment odebrania pakietu złapany na zegarze Slave).

Należy się teraz zastanwoić, jakie informacje może uzyskać urządzenie Slave, mając te dwie wartości do dyspozycji. Odwzorowują one tylko stany zegarów w pewnych momentach, ale skoro pakiety są wysyłane z interwałem (np. co sekundę), można pokusić się o precyzyjny pomiar wartości czasowej tych interwałów. Standardowo znaczniki czasowe T1 i T2 są wyrażone w rozdzielczości nanosekundowej – ponieważ rozdzielczość ta jest zbliżona do okresu, z jakim oscylują nasze zegary, można zauważyć zanalogie do pomiaru częstotliwości. Na przykład jeżeli zegar oscyluje z częstotliwością 1 GHz, oznacza to, że statystycznie jego okres wynosi 1 ns. Zakładając więc, że czas przesyłu pakietów przez medium jest zawsze taki sam, można porównać częstotliwość działania zegara na węźle Master i na węźle Slave, a następnie na tej podstawie skorygować wartość częstotliwości zegara Slave. Zatem cały proces umożliwia dokonanie synchronizacji częstotliwości. Idea tego procesu przedstawiona jest na poniższym rysunku.

Proces dostosowania częstotliwości do zadanej wartości nie jest jednak taki prosty. W ramach tej czynności często stosuje się mechanizmy regulacji, dążące do minimalizacji wartości uchybu. W tym przypadku jest to wartość różnicy częstotliwości pomiędzy urządzeniami Master a Slave.   

Mając do dyspozycji wyłącznie znaczniki czasowe T1 i T2, nie da się jednak stwierdzić, jaki jest czas opóźnienia łącza – a ten parametr jest kluczowy do synchronizacji wartości czasu oraz fazy na zegarze podrzędnym.

Jak zatem wyliczyć opóźnienie łącza? Niezbędne będzie wykonanie dodatkowej operacji inicjowanej tym razem po stronie urządzenia Slave. Można zrealizować analogiczną operację jak w przypadku wysyłania wiadomości sync, ale tym razem odwrócić kierunek komunikacji – urządzenie Slave będzie wysyłać wiadomości do urządzenia Master (pakiet ten nazywa się Delay_Req). Operacja pozwoli na zebranie kolejnych znaczników czasowych (T3 – moment wysłania pakietu z urządzenia Slave oraz T4 – moment odebrania pakietu na urządzeniu Master). Do urządzenia Slave nie ma potrzeby wysyłania pakietów follow up, ponieważ urządzenie Master nie potrzebuje wiedzy o tym, kiedy została wysłana ramka. Chce za to uzyskać informacje o tym, kiedy pakiet dotarł do urządzenia Master, dlatego wymaga się od niego, żeby wysłał kolejny pakiet z tą informacją nazywany Delay_Resp. Poniżej przedstawiony jest opisany poprzednio scenariusz.

Odpowiada to mechanizmowi obliczania opóźnienia łącza o nazwie E2E (End 2 End) opisanemu w standardzie, dostępny jest również drugi mechanizm P2P (Pear 2 Pear), którego którego opis wykracza poza ramy tego artykułu.

Co można zrobić, mając do dyspozycji dodatkowe znaczniki czasowe T3 i T4? W końcu wykonana została tylko analogiczna do poprzedniej operacja, wiec czy zmieni to w jakiś sposób sytuację?

W tym miejscu można pomyśleć o skonkretyzowaniu ustaleń. Cały proces można zobrazować w sposób następujący:

Zdefiniujmy niektóre wartości:

Po przesłaniu pakietu Sync możemy zdefiniować zmienną, wyrażającą różnicę między stanem zegara urządzenia Master w momencie wysłania, a stanem zegara urządzenia Slave w momencie odebrania pakietu:

 ms_diff = T2 – T1

Po przesłaniu pakietu Delay_Req można zdefiniować zmienną, wyrażającą różnicę między stanem zegara urządzenia Slave w momencie wysłania, a stanem zegara urządzenia Master w momencie odebrania pakietu:

 sm_diff = T4 – T3

Do obliczeń można teraz wprowadzić wcześniej zdefiniowane zmienne, czyli offset (różnica we wskazaniach dwóch zegarów) oraz opóźnienie łącza:

ms_diff = offset + ms_delay

oraz 

sm_diff = - offset + sm_delay

Uwagę może zwrócić fakt, że definiowana jest tu tylko jedna wartość offset, kóra z założenia jest stała podczas całego procesu obliczeń. Aby to założenie było prawdziwe, kluczowe jest przeprowadzenie w pierwszej kolejności synchronizacji częstotliwości, gdyż różnica częstotliwości może spowodować znaczny dryf fazy – a co za tym idzie offsetu pomiędzy zegarami.

Z powyższych równań możemy wyprowadzić następujący wzór na offset:

offset =  [ ( ms_diff – sm_diff ) – ( ms_delay – sm_delay ) ] / 2

Możemy też napisać:

( ms_delay + sm_delay ) = ( ms_diff + sm_diff )

Biorąc pod uwagę dwa powyższe równania, można zauważyć, że występują w nich trzy niewiadome (offset, ms_delay, sm_delay) i tylko dwie znane wartości (ms_diff i sm_diff). Rozwiązanie tego równania bez dodatkowych założeń wydaje się więc niemożliwe. Kolejnym założeniem, które można przyjąć, jest opóźnienie łącza w kierunku od Mastera do Slave, które jest równe opóźnieniu w przeciwnym kierunku – innymi słowy nie występuje asymetria łącza, więc:

ms_delay = sm_delay = delay.

Możemy ostatecznie napisać wzory:

offset =  ( ms_diff – sm_diff ) / 2

oraz

delay =  ( ms_diff + sm_diff ) / 2

Podsumowanie

Protokół PTP znalazł zastosowanie w takich dziedzinach jak: telekomunikacja, procesy kontroli przemysłowej, a nawet synchronizacja operacji finansowych. Ze względu na to wiedza o jego działaniu staje się coraz bardziej przydatna. Jego analiza pozwala też zapoznać się z ciekawym podejściem do rozwiązywania problemów z pogranicza zarówno sieci komputerowych, jak i przetwarzania sygnałów. Mam nadzieję, że w tym artykule przedstawiłem informacje, które pomogą czytelnikowi w zrozumieniu procesu synchronizacji czasu za pomocą protokołu PTP. Zachęcam do przyjrzenia się dostępnym realizacjom, na przykład projektowi ptp4l będącemu implemantacją aplikacji PTP dla systemu operacyjnego Linux.