A PTPv2 időszinkronizáló protokoll megvalósításának részletei

Bevezetés

A digitális alállomás koncepciója az energiaszektorban 1 μs pontosságú szinkronizálást igényel. Pénzügyi tranzakciók lebonyolításához is μs pontosság szükséges. Ezekben az alkalmazásokban az NTP időpontossága már nem elegendő.

A PTPv2 időszinkronizáló protokoll, amelyet az IEEE 1588v2 szabvány ír le, lehetővé teszi, hogy néhány tucat nanomásodpercen belüli szinkronizálási pontosságot érjünk el. A PTPv2 lehetővé teszi szinkronizáló csomagok küldését L2 és L3 hálózatokon keresztül.

A PTPv2 fő alkalmazási területei a következők:

• energiaipar;
• mérő- és ellenőrző berendezések;
• védelmi ipar;
• távközlés;
• pénzügyi szektor.

Ez a bejegyzés azt vizsgálja, hogyan működik a PTPv2 időszinkronizáló protokoll.

Több tapasztalattal rendelkezünk az iparban, és gyakran találkozunk ezzel a protokollal az energiatermelő alkalmazásokban. Ennek megfelelően az áttekintésünket az energiára összpontosítva készítjük el. az energiatermelésre.

Miért van szükség rá?

Jelenleg a ROSSETI PJSC 34.01-21-004-2019 és a FSK EES PJSC 56947007-29.240.10.302-2020 szabványában a PTPv2 alapú időszinkronizálás szervezésére vonatkozó követelmények találhatók.

Ez azért van, mert a folyamati buszhoz kapcsolódó relé-védelmi terminálok és mérőeszközök az úgynevezett SV-áramlatokon (multicast-áramlatok) keresztül az áram és a feszültség pillanatnyi értékeit továbbítják.

A relé-védelmi terminálok ezeket az értékeket használják az összekapcsolások védelmének megvalósításához. Ha az időmérés pontossága alacsony, akkor előfordulhat, hogy egyes védelmek tévesen aktiválódnak.

Például a 'gyenge' időszinkronizálás áldozatául eshetnek az abszolút szelektivitási védelmek. Az ilyen védelmek logikája gyakran két mennyiség összehasonlításán alapul. Ha a mennyiségek elég nagy értékre eltérnek, akkor a védelem aktiválódik. Ha ezeket az értékeket 1 ms időpontossággal mérjük, akkor nagy eltérést kaphatunk, ahol az értékek valójában normál tartományban vannak, ha 1 μs pontossággal mérjük őket.

PTP verziók

A PTP protokoll a 2002-es IEEE 1588-2002 szabványban lett először leírva, és "Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems" néven ismert. 2008-ban kiadták a frissített IEEE 1588-2008 szabványt, amely a PTP Version 2-t írja le. Ebben a protokollverzióban a pontosság és a stabilitás javult, de nem őrizte meg a visszafelé kompatibilitást az első verzióval. Ezenkívül 2019-ben megjelent az IEEE 1588-2019 szabvány, amely a PTP v2.1-et írja le. Ez a verzió kis javításokat ad a PTPv2-hez, és visszafelé kompatibilis a PTPv2-vel.

Más szavakkal, így néz ki a verziók képe:

PTPv1
(IEEE 1588-2002)

PTPv2
(IEEE 1588-2008)

PTPv2.1
(IEEE 1588-2019)

PTPv1 (IEEE 1588-2002)

—
Nem kompatibilisek

Nem kompatibilisek

PTPv2 (IEEE 1588-2008)

Nem kompatibilisek

—
Kompatibilisek

PTPv2.1 (IEEE 1588-2019)

Nem kompatibilisek

Kompatibilisek

—

De, mint mindig, vannak árnyalatok.

A PTPv1 és PTPv2 közötti inkompatibilitás azt jelenti, hogy a PTPv1-et támogató eszköz nem tud szinkronizálni a PTPv2-n működő pontos óráktól. Különböző üzenetformátumokat használnak a szinkronizáláshoz.

De lehetővé lehet tenni a PTPv1 és PTPv2 eszközök összekapcsolását egy hálózaton belül. Ehhez néhány gyártó lehetővé teszi a határidők portjain a protokollverzió kiválasztását. Tehát a határidős órák PTPv2-n keresztül szinkronizálhatók, és egyidejűleg más csatlakoztatott órákat is szinkronizálhatnak a PTPv1 és a PTPv2 használatával.

PTP eszközök. Milyen típusúak és miben különböznek?

Az IEEE 1588v2 szabvány többféle eszközt ír le. Ezek mindegyikét a táblázat tartalmazza.

Az eszközök egymással LAN-on keresztül lépnek kapcsolatba, PTP-t használva.

A PTP eszközöket óráknak hívják. Minden óra a nagymester óráktól szerzi meg a pontos időt.

Ötféle óra létezik:

Grandmaster clock (Nagymester óra)

A pontos idő fő forrása. Gyakran GPS csatlakozási felülettel szerelik fel.

Ordinary Clock (Sima óra)

Egy porttal rendelkező eszköz, amely lehet mester (vezető óra) vagy szolga (követő óra).

Vezető órák (mester)

A pontos idő forrása, amely alapján más órák szinkronizálódnak.

Követő órák (szolga)

Olyan végberendezés, amely a vezető óráktól szinkronizálódik.

Boundary Clock (Határok órája)

Több porttal rendelkező eszköz, amely lehet mester vagy szolga.

Tehát ezek az órák szinkronizálhatók a magasabb szintű vezető óráktól, és szinkronizálhatják az alacsonyabb szintű követő órákat.

Végponttól-végpontig Átlátszó Óra

Olyan többportos eszköz, amely nem vezető, sem mondott óra. Adatokat továbbít PTP között két óra.

Az adatátvitel során az átlátszó órák módosítják az összes PTP üzenetet.

A módosítás a késleltetési idő hozzáadásával történik az eszközön a korrigálási mezőhöz a továbbított üzenet fejléce előtt.

Peer-to-Peer Átlátszó Óra

Olyan többportos eszköz, amely nem vezető, sem mondott óra.
Adatokat továbbít PTP között két óra.

Az adatátvitel során az átlátszó órák módosítják az összes PTP Sync és Follow_Up üzenetet.

A módosítás úgy érhető el, hogy a továbbított csomag korrigálási mezőjéhez hozzáadjuk a késleltetést a küldő eszközön és a kommunikációs csatornán.

Management Node

Olyan eszköz, amely konfigurálja és diagnosztizálja a többi órát.

A vezető és mondott órák időbélyegek segítségével szinkronizálódnak a PTP üzenetekben. Két üzenettípus létezik a PTP protokollban:

• Event Messages – ezek szinkronizált üzenetek, amelyek azt feltételezik, hogy időbélyeg keletkezik az üzenet küldése és fogadása pillanatában.
• General Messages – ezek az üzenetek nem igényelnek időbélyeget, de tartalmazhatnak az összefüggő üzenetekhez kapcsolódó időbélyegeket.

Event Messages

General Messages

Sync
Delay_Req
Pdelay_Req
Pdelay_Resp

Announce
Follow_Up
Delay_Resp
Pdelay_Resp_Follow_Up
Management
Signaling

A következőkben részletesebben ismertetjük az összes üzenettípust.

Főbb szinkronizálási problémák

Amikor a szinkronizáló csomag átkerül a helyi hálózaton, késlekedik a kapcsolónál és az adatátviteli csatornán. Bármely kapcsoló körülbelül 10 μs késleltetést ad, ami elfogadhatatlan a PTPv2 számára. Végül is az végső eszközön 1 μs pontosságot kell kapnunk. (Ez az energiatermelésre vonatkozik. Más alkalmazások esetén lehet, hogy nagyobb pontosságra van szükség.)

Az IEEE 1588v2-ben több működési algoritmus van leírva, amelyek lehetővé teszik az idő késleltetés rögzítését és annak korrekcióját.

Működési algoritmus
Normál működés mellett a protokoll két fázisban működik.

• 1. fázis – a "Vezető órák - Mondott órák" hierarchia felállítása.
• 2. fázis – az órák szinkronizálása az End-to-End vagy Peer-to-Peer mechanizmus segítségével.

1. Fázis - A "Mester-Rabszolga" hierarchia beállítása

Minden szokásos vagy határidőórának meghatározott számú állapota van (rabszolga órák és mester órák). A szabvány leírja az állapotok közötti átmenet algoritmusát. A programozásban ezt az algoritmust végső automatának vagy állapotgépezetnek hívják (további információ a Wiki-n).

Ez a végső automata a Legjobb Mesteróra Algoritmus (BMCA) eljárást használja a mester beállításához, amikor két órát összekapcsolnak.

Ez az algoritmus lehetővé teszi az órák számára, hogy átvállalják a nagymesteri órák kötelezettségeit, amikor a felette álló nagymesteri órák elveszítik a GPS jelet, leválnak a hálózatról stb.

Az állapotok közötti átmenetek a BMCA szerint röviden a következő ábrán láthatók:


Az órákról a "vezeték" másik végén egy speciális üzenetben (Felhívó üzenet) érkezik információ. Amikor ez az információ megérkezik, az állapotgép algoritmus végrehajtja az összehasonlítást, hogy melyik óra a legjobb. A legjobb órák portja mester órává válik.

Az egyszerű hierarchiát az alábbi ábra mutatja. Az 1, 2, 3, 4, 5 utak átlátszó órákat (Átlátszó óra) tartalmazhatnak, de nem vesznek részt a "Mester órák - Rabszolga órák" hierarchia beállításában.

2. Fázis - Szinkronizálás a szokásos és határidőórák között

Az "Mester órák - Rabszolga órák" hierarchia beállítása után azonnal megkezdődik a szinkronizálás a szokásos és határidőórák között.

A mester órák üzenetet küldenek a rabszolga óráknak, amely tartalmazza az időbélyeget.

A mester órák lehetnek:

• egyszintű;
• kétszintű.

Az egyszintű órák szinkronizálása egy Sync üzenetet küldenek.

A kétszintű órák szinkronizálásához két üzenetet használnak – Sync és Follow_Up.

A szinkronizálási fázisban két mechanizmus használható:

• Kérés-válasz késleltetési mechanizmus (Késleltetési kérés-válasz mechanizmus).
• Szomszédos csomópont késleltetésmérési mechanizmusa (Csoport késleltetés mérési mechanizmus).

Kezdjük el ezeket a mechanizmusokat a legegyszerűbb esetben – amikor átlátszó órák nincsenek alkalmazva.

Kérés-válasz késleltetési mechanizmus (Késleltetési kérés-válasz mechanizmus)

A mechanizmus két lépést feltételez:

1. A késleltetés mérése a mester órák és a rabszolga órák között történik. Ezt a késleltetési kérés-válasz mechanizmus segítségével hajtják végre.
2. A pontos idő eltolódásának kiigazítása történik.

A késleltetés mérése


t1 – A szinkronizáló óra üzenetének elküldési ideje; t2 – A szinkronizáló óra üzenetének átvételi ideje; t3 – A késleltetési kérés (Delay_Req) elöljáró órák átvételi ideje; t4 – A Delay_Req elöljáró órák által küldött üzenetének átvételi ideje.

Amikor az elöljáró órák ismerik az t1, t2, t3 és t4 időket, akkor képesek kiszámítani az üzenet szinkronizálása során tapasztalt átlagos késleltetést (tmpd). A számítás a következőképpen történik:

A Sync és Follow_Up üzenet átvitele során kiszámítjuk az idő késleltetését a mester és a slave között – t-ms.

A Delay_Req és Delay_Resp üzenetek átvitele során kiszámítjuk az idő késleltetését a slave és a mester között – t-sm.

Ha e két érték között bármiféle aszimmetria lép fel, akkor a pontos idő eltérésekor hiba keletkezik. A hiba abból adódik, hogy a számított késleltetés az t-ms és t-sm késleltetések átlagát jelenti. Ha a késleltetések nem egyenlőek, akkor az időt pontatlanul fogjuk korrekciózni.

A pontos idő eltolódásának korrekciója

Miután a késleltetés az elöljáró és a slave óra között ismert, a slave óra végrehajtja az idő korrekcióját.

A slave órák a Sync üzenetet és az opcionális Follow_Up üzenetet használják a pontos idő eltolódásának kiszámításához az elöljáró órák és a slave órák közötti csomagátvitel során. Az eltolódás a következő képlettel számítható:

A szomszédos csomópont késleltetésének mérési mechanizmusa (Peer delay measurement mechanism)

Ez a mechanizmus is két lépést használ a szinkronizáláshoz:

1. Az eszközök minden szomszéd idő késleltetését mérik minden porton keresztül. Ehhez használják a peer delay mechanizmust.
2. A pontos idő eltolódásának korrekciója.

A Peer-to-Peer üzemmódot támogató eszközök közötti késleltetés mérése

A peer-to-peer mechanizmust támogató portok közötti késleltetést a következő üzenetek segítségével mérjük:

Amikor az 1-es port ismeri az t1, t2, t3 és t4 időpontokat, akkor képes kiszámítani az átlagos késleltetést (tmld). Ezt a következő képlettel számítják:

Ezután a port ezt az értéket használja a korrekciós mező kiszámításához minden Sync üzenethez vagy opcionális Follow_Up üzenethez, amelyek áthaladnak ezen az eszközön.

A végső késleltetés a késleltetés összege lesz, amely az adott eszközön keresztül történik, a közvetlen adatátvitel átlagos késleltetése, és a már a fentebb található eszközökben tartalmazott késleltetés.

A Pdelay_Req, Pdelay_Resp és az opcionális Pdelay_Resp_Follow_Up üzenetek lehetővé teszik a késés mérését a mestertől a slave-hez és a slave-től a mesterhez (körkörös).

Bármilyen aszimmetria e két érték között hibát okoz a pontos idő eltolásának korrekciójában.

A pontos idő eltolásának korrekciója

A slave órák Sync üzenetet és opcionális Follow_Up üzenetet használnak a pontos idő eltolásának kiszámításához, amikor a csomag vezető óráról a slave órákra kerül. Az eltolást a következő képlettel számítják ki:

A peer-to-peer korrekciós mechanizmus előnye – a Sync vagy Follow_Up üzenet késése minden egyes üzenet átvitele során számítódik. Ennek következtében az átvitel útvonalának megváltozása semmilyen módon nem befolyásolja a korrekció pontosságát.

E mechanizmus használatakor az idő szinkronizálása nem igényli a késés számítását a szinkronizáló csomag által megtett úton, mint azt a klasszikus cserénél a Delay_Req és Delay_Resp üzenetek küldésénél teszik. Ebben a módszerben a vezető és a slave órák közötti késést egyszerűen hozzáadják a Sync vagy Follow_Up üzenetek korrekciós mezőjéhez.

Egy másik előny – a vezető óráknak nem kell kezelnük a Delay_Req üzeneteket.

Áttetsző órák működési módjai

Ennek megfelelően egyszerű példákat vizsgáltunk meg. Most feltételezzük, hogy a szinkronizálási úton switchek jelennek meg.

Ha switcheket használunk, amelyek nem támogatják a PTPv2-t, akkor a szinkronizáló csomag körülbelül 10 μs késéssel fog várakozni a switch-en.

A PTPv2-t támogató switcheket az IEEE 1588v2 terminológiájában áttetsző óráknak (Transparent clock) nevezik. Az áttetsző órák nem szinkronizálódnak a vezető óráktól és nem vesznek részt a "Vezető órák – Slave órák" hierarchiájában, de a szinkronizáló üzenetek átvitele során eltárolják, mennyit késlekedtek. Ez lehetővé teszi a késés korrekcióját.

Az áttetsző órák két üzemmódban működhetnek:

• Végpont-végpont.
• Peer-to-Peer.

Végpont-végpont (E2E)

Az E2E áttetsző órák a Sync üzeneteket és a kapcsolódó Follow_Up üzeneteket minden porton továbbítják. Még azokon is, amelyek zárolva vannak bármilyen protokoll által (például RSTP).

A switch remembers the timestamp when a Sync (Follow_Up) packet was received on a port and when it was sent from the port. Based on these two timestamps, the processing time of the message by the switch is calculated. In the standard, this time is called residence time.

The processing time is added to the correctionField of the Sync message (one-step clocks) or the Follow_Up message (two-step clocks).

Transparent E2E clocks measure the processing time for Sync and Delay_Req messages passing through the switch. However, it's important to understand that the delay time between the master and slave clocks is calculated using the delay request-response mechanism. If the master clocks change or the path from the master clocks to the slave changes, the delay is measured again. This increases the transitional state time in case of network changes.

Transparent P2P clocks, in addition to measuring the message processing time by the switch, measure the delay over the data transmission channel to the nearest neighbor, using the neighbor node delay measurement mechanism.

The delay is measured on each channel in both directions, including channels that are blocked by any protocol (e.g., RSTP). This allows for the immediate recalculation of the new delay on the synchronization path if the grandmaster clocks or network topology have changed.

The processing times of messages by switches and the delay times accumulate when messages Sync or Follow_Up are transmitted.

Types of PTPv2 support by switches

Switches can support PTPv2:

• software;
• hardware.

In a software implementation of the PTPv2 protocol, the switch queries the firmware for a timestamp. The problem is that the firmware operates cyclically, and you have to wait until it finishes the current cycle, processes the request, and then provides the timestamp after the next cycle. This also takes time, resulting in a delay, albeit not as significant as with no software support for PTPv2.

Only hardware support for PTPv2 can ensure the required accuracy. In this case, the timestamp is provided by a special ASIC installed on the port.

Message format

All PTP messages consist of the following fields:

• Header – 34 bytes.
• Body – size depends on the message type.
• Suffix – optional.

Header

A Header mező minden PTP üzenet számára azonos. Mérete 34 bájt.

A Header mező formátuma:

messageType – tartalmazza az átvitt üzenet típusát, például Sync, Delay_Req, PDelay_Req stb.

messageLength – tartalmazza a PTP üzenet teljes méretét, beleértve a header-t, a body-t és a suffix-et (de kizárva a kitöltő bájtokat).

domainNumber – meghatározza, hogy melyik domain PTP-hez tartozik az üzenet.

Domainek – különböző órák csoportját jelenti, amelyeket egy logikai csoportba összegyűjtöttek, és egy vezető óra alapján szinkronizáltak, de nem feltétlenül szinkronizáltak egy másik domainhez tartozó órákkal.

flags – ez a mező különböző zászlókat tartalmaz az üzenet státuszának azonosítására.

correctionField – a késleltetést nanomásodpercben tartalmazza. A késleltetés magában foglalja a késleltetést az átlátszó órákon való átvitel során, valamint a csatornán való átvitel késleltetését Peer-to-Peer módban.

sourcePortIdentity – ez a mező tartalmazza az információt arról, hogy melyik porról küldték az üzenetet.

sequenceID – a különböző üzenetek azonosító számát tartalmazza.

controlField – artefakt mező=) Ez az első verzióból maradt meg, és tartalmazza az üzenet típusára vonatkozó információkat. Lényegében ugyanaz, mint a messageType, de kevesebb lehetőséggel.

logMessageInterval – ez a mező az üzenet típusától függ.

Body

Mint azt korábban tárgyaltuk, többféle üzenet létezik. Ezek a típusok az alábbiakban vannak leírva:

Announce üzenet
Az Announce üzenet arra szolgál, hogy „elmondja” a domainen belüli többi órának a paramétereit. Ez az üzenet lehetővé teszi a „Vezető órák – Követő órák” hierarchia felállítását.


Sync üzenet
A szinkronizáló üzenet (Sync) a vezető órák által van elküldve, és tartalmazza a vezető órák idejét arra a pillanatra, amikor a Sync üzenet létrejött. Ha a vezető órák kétszintűek, akkor a Sync üzenetben szereplő időbélyeg 0-ra lesz állítva, és a tényleges időbélyeg a Follow_Up üzenetben lesz elküldve. A Sync üzenetet a késleltetés mérésének mindkét mechanizmusához használják.

Az üzenet Multicast módszerrel kerül átvitelre. Opcióként Unicast is alkalmazható.

Delay_Req üzenet

A Delay_Req üzenet formátuma azonos a Sync üzenetével. A követő órák küldik el a Delay_Req-t. Tartalmazza a Delay_Req követő órák általi elküldési idejét. Ez az üzenet csak a késleltetés kérés-válasz mechanizmusához használható.

Az üzenet Multicast módszerrel kerül átvitelre. Opcióként Unicast is alkalmazható.

Follow_Up üzenet

A Follow_Up üzenet opcionálisan kerül elküldésre a vezető órák által, és tartalmazza az elküldés idejét. Sync üzenetek mester által. A Follow_Up üzenet csak a kétlépcsős vezető órák által kerül elküldésre.

A Follow_Up üzenet mindkét késleltetési mérési mechanizmushoz használható.

Az üzenet Multicast módszerrel kerül átvitelre. Opcióként Unicast is alkalmazható.

Delay_Resp üzenet

A Delay_Resp üzenet a vezető órák által kerül elküldésre. Tartalmazza a Delay_Req üzenet érkezési idejét a vezető órák által. Ezt az üzenetet csak a késleltetés kérés-válasz mechanizmushoz használják.

Az üzenet Multicast módszerrel kerül átvitelre. Opcióként Unicast is alkalmazható.

Pdelay_Req üzenet

A Pdelay_Req üzenet az a készülék küldi, amely a késleltetést kéri. Tartalmazza a saját portján elküldött üzenet idejét. A Pdelay_Req üzenet csak a szomszédos csomópont késleltetési mérési mechanizmusához használható.

Pdelay_Resp üzenet

A Pdelay_Resp üzenet az a készülék küldi, amely megkapta a késleltetés iránti kérelmet. Tartalmazza a Pdelay_Req üzenet érkezési idejét. A Pdelay_Resp üzeneteket csak a szomszédos csomópont késleltetési mérési mechanizmusához használják.

Pdelay_Resp_Follow_Up üzenet

A Pdelay_Resp_Follow_Up üzenet opcionálisan kerül elküldésre azon készülék által, amely megkapta a késleltetési kérelmet. Tartalmazza a Pdelay_Req üzenet érkezési idejét a készülék által. A Pdelay_Resp_Follow_Up üzenetet csak a kétlépcsős vezető órák küldik.

Ez az üzenet a végrehajtási időre is használható a timestamp helyett. A végrehajtási idő a Pdelay-Req beérkezésétől a Pdelay_Resp küldéséig eltelt idő.

A Pdelay_Resp_Follow_Up üzeneteket csak a szomszédos csomópont késleltetési mérési mechanizmusához használják.

Irányító üzenetek (Management üzenet)

A PTP irányító üzenetek szükségesek az információk továbbításához egy vagy több óra és az irányító csomópont között.

Átvitel LV-ben

A PTP üzenet két szinten továbbítható:

• Hálózati szinten – IP adatok részeként.
• Link szinten – Ethernet keret részeként.

PTP üzenet átvitel UDP-n keresztül IP-n keresztül Ethernet-en

PTP UDP-n keresztül Ethernet-en

Profilok

A PTP-nek van számos "rugalmas" paramétere, amelyeket be kell állítani. Például:

• BMCA opciók.
• Késleltetés mérési mechanizmus.
• Minden konfigurálható paraméter intervallumai és kezdeti értékei stb.

És bár korábban azt mondtuk, hogy a PTPv2 eszközök kompatibilisek egymással, valójában ez nem így van. Az eszközöknek azonos beállításokkal kell rendelkezniük a kölcsönhatáshoz.

Ezért léteznek úgynevezett PTPv2 profilok. A profilok a konfigurált beállítások és a protokoll különböző korlátozásainak csoportjai, hogy lehetővé tegyék az időszinkronizálást egy adott alkalmazás számára.

Az IEEE 1588v2 szabvány csupán egy profilt ír le - a „Default Profile”-t. Minden más profilt különböző szervezetek és egyesületek hoztak létre és írtak le.

Például az elektroenergetikai PTPv2 Power Profile-t a Power Systems Relaying Committee és az IEEE Power and Energy Society alállomásbizottsága hozta létre. A profil neve IEEE C37.238-2011.

A profil leírja, hogy a PTP hogyan továbbítható:

• Csak L2 hálózatokon (azaz Ethernet, HSR, PRP, nem IP).
• Az üzenetek csak multicast terjesztéssel kerülnek továbbításra.
• A késleltetésmérés mechanizmusaként a Peer delay measurement mechanism használatos.

Az alapértelmezett domain – 0, ajánlott domain – 93.

A C37.238-2011 létrehozásának filozófiája az volt, hogy csökkentse a választási lehetőségek számát, és csak a szükséges funkciókat hagyja meg a megbízható eszköz-interakció érdekében és a rendszer stabilitásának javítása érdekében.

A kommunikációs üzenetek továbbítási frekvenciáját is meghatározták:

Tulajdonképpen egyetlen paraméter választható - a vezető órák típusa (egyfokozatú vagy kétfokozatú).

A pontosságnak nem szabad meghaladnia az 1 μs-t. Más szavakkal, egy szinkronizációs útvonalban legfeljebb 15 átlátszó óra vagy három határoló óra található.

Forrás: habr.com