Lansarea Firefox 75

Introducere

Conceptul de construire a «Substației Digitale» în energetica electrică necesită sincronizare cu o precizie de 1 μs. De asemenea, pentru efectuarea tranzacțiilor financiare este necesară o precizie în μs. În aceste aplicații, precizia timpului NTP este deja insuficientă.

Protocolul de sincronizare PTPv2, descris de standardul IEEE 1588v2, permite obținerea unei precizii de sincronizare de câteva zeci de nanosecunde. PTPv2 permite trimiterea pachetelor de sincronizare prin rețele L2 și L3.

Principalele domenii în care se aplică PTPv2 sunt:

• energetică;
• echipamente de măsurare și control;
• complexul industrial și de apărare;
• telecomunicații;
• sectorul financiar.

În această postare se analizează cum funcționează protocolul de sincronizare PTPv2.

Avem mai multă experiență în industrie și întâlnim frecvent acest protocol în aplicații energetice. Prin urmare, vom face o revizuire având în vedere sectorul energetic.

De ce este necesar?

În prezent, în STC 34.01-21-004-2019 al PJSC „Rosseti” și în STC 56947007-29.240.10.302-2020 al PJSC „FSK EES” există cerințe pentru organizarea magistralei de proces cu asigurarea sincronizării timpului prin PTPv2.

Acest lucru se datorează faptului că la magistrala de proces sunt conectate terminale de protecție prin relee și aparate de măsură, care prin magistrala de proces, folosind așa-numitele fluxuri SV (fluxuri multicast), transmit valori instantanee ale curentului și tensiunii.

Terminalele de protecție prin relee folosesc aceste valori pentru implementarea protecțiilor conexiunilor. Dacă precizia măsurărilor în timp este mică, unele protecții pot reacționa fals.

De exemplu, victimele unei sincronizări temporale «slabe» pot deveni protecțiile cu selecție absolută. De obicei, logica unor astfel de protecții se bazează pe compararea a două mărimi. Dacă mărimile se abate suficient de mult, protecția se activează. Dacă aceste mărimi au fost măsurate cu o precizie în timp de 1 ms, se poate obține o diferență mare acolo unde valoriile se află de fapt în normă, dacă sunt măsurate cu o precizie de 1 μs.

Versiunile PTP

Protocolul PTP a fost descris inițial în 2002 în standardul IEEE 1588-2002 și a avut denumirea „Standard pentru un protocol de sincronizare precisă a ceasului pentru sisteme de măsurare și control în rețea”. În 2008 a fost lansat un standard actualizat, IEEE 1588-2008, care descrie PTP Versiunea 2. În această versiune a protocolului s-a îmbunătățit precizia și stabilitatea, însă nu s-a păstrat compatibilitatea înapoi cu prima versiune. De asemenea, în 2019 a fost lansată versiunea standardului IEEE 1588-2019, care descrie PTP v2.1. Această versiune adaugă mici îmbunătățiri la PTPv2 și este compatibilă înapoi cu PTPv2.

Cu alte cuvinte, avem următoarea situație cu versiunile:

PTPv1
(IEEE 1588-2002)

PTPv2
(IEEE 1588-2008)

PTPv2.1
(IEEE 1588-2019)

PTPv1 (IEEE 1588-2002)

—
Incompatibile

Incompatibile

PTPv2 (IEEE 1588-2008)

Incompatibile

—
Compatibile

PTPv2.1 (IEEE 1588-2019)

Incompatibile

Compatibile

—

Dar, ca întotdeauna, există nuanțe.

Incompatibilitatea între PTPv1 și PTPv2 presupune că un dispozitiv care suportă PTPv1 nu se poate sincroniza de la ceasuri precise care funcționează pe PTPv2. Pentru sincronizare, utilizează formate diferite de mesaje.

Dar este totuși posibil să combinăm dispozitive cu PTPv1 și dispozitive cu PTPv2 într-o singură rețea. Pentru aceasta, unii producători permit alegerea versiunii protocolului pe porțile ceasurilor de frontieră. Adică, ceasurile de frontieră se pot sincroniza prin PTPv2 și în același timp pot sincroniza alte ceasuri conectate la ele atât prin PTPv1, cât și prin PTPv2.

Dispozitive PTP. Ce tipuri există și cu ce se deosebesc?

Standardul IEEE 1588v2 descrie mai multe tipuri de dispozitive. Toate acestea sunt prezentate în tabel.

Dispozitivele interacționează între ele printr-o rețea locală, folosind PTP.

Dispozitivele PTP sunt denumite ceasuri. Toate ceasurile preiau timpul exact de la ceasurile grandmaster.

Există 5 tipuri de ceasuri:

Grandmaster clock (Ceasuri grandmaster)

Sursa principală de timp exact. Adesea dotată cu o interfață pentru conectarea GPS-ului.

Ordinary Clock (Ceasuri obișnuite)

Dispozitiv cu o singură poartă care poate fi master (ceasuri principale) sau slave (ceasuri secundare)

Ceasuri principale (master)

Sunt sursa de timp exact în jurul căreia se sincronizează celelalte ceasuri

Ceasuri secundare (slave)

Dispozitiv final care se sincronizează de la ceasurile principale

Boundary Clock (Ceasuri de frontieră)

Dispozitiv cu mai multe porți care poate fi master sau slave.

Adică aceste ceasuri se pot sincroniza de la ceasurile principale superioare și pot sincroniza ceasurile secundare inferioare.

Ceas Transparent End-to-End

Dispozitiv cu mai multe porturi care nu este nici ceas de referință, nici ceas secundar. Acesta transmite date PTP între două ceasuri.

În timpul transmiterii datelor, ceasurile transparente corectează toate mesajele PTP.

Corectarea se face prin adăugarea timpului de întârziere pe acest dispozitiv în câmpul de corectare din antetul mesajului transmis.

Ceas Transparent Peer-to-Peer

Dispozitiv cu mai multe porturi care nu este nici ceas de referință, nici ceas secundar.
Acesta transmite date PTP între două ceasuri.

În timpul transmiterii datelor, ceasurile transparente corectează toate mesajele PTP Sync și Follow_Up (despre care se discută mai jos).

Corectarea se realizează prin adăugarea întârzierilor din câmpul de corectare al pachetului transmis și din canalul de transmisie a datelor.

Nod de Management

Dispozitiv care configurează și diagnostichează alte ceasuri.

Ceasurile de referință și secundare sunt sincronizate folosind marcaje temporale în mesajele PTP. Există două tipuri de mesaje în protocolul PTP:

• Mesaje de Eveniment – acestea sunt mesaje sincronizate care presupun generarea marcajului temporal în momentul trimiterii și în momentul primirii mesajului.
• Mesaje Generale – aceste mesaje nu necesită marcaje temporale, dar pot conține marcaje temporale pentru mesaje corelate.

Mesaje de Eveniment

Mesaje Generale

Sync
Delay_Req
Pdelay_Req
Pdelay_Resp

Anunțare
Follow_Up
Delay_Resp
Pdelay_Resp_Follow_Up
Management
Signaling

În continuare, toate tipurile de mesaje vor fi discutate în detaliu.

Problemele principale de sincronizare

Atunci când un pachet de sincronizare este transmis printr-o rețea locală, acesta este întârziat de comutator și de canalul de transmisie. Orice comutator va oferi o întârziere de aproximativ 10 μs, ceea ce este inacceptabil pentru PTPv2. Este necesar ca la dispozitivul de destinație să obținem o precizie de 1 μs. (Aceasta dacă se referă la energie. Alte aplicații pot necesita o precizie chiar mai mare.)

În IEEE 1588v2 sunt descrise mai multe algoritmi de lucru care permit măsurarea întârzierii în timp și corectarea acesteia.

Algoritmul de funcționare
În condiții normale de funcționare, protocolul funcționează în două faze.

• Faza 1 – stabilirea ierarhiei "Ceasuri de referință – Ceasuri secundare".
• Faza 2 – sincronizarea ceasurilor prin mecanismul End-to-End sau Peer-to-Peer.

Faza 1 — Instalarea ierarhiei „Master-Slave”

Fiecare port al ceasurilor obișnuite sau de frontieră are un număr specific de stări (ceasuri secundare și ceasuri principale). Standardul descrie algoritmul de tranziție între aceste stări. În programare, un astfel de algoritm este numit automată finită sau mașină de stări (mai multe detalii în Wiki).

Această automată finită utilizează algoritmul Best Master Clock Algorithm (BMCA) pentru a stabili masterul atunci când se conectează două ceasuri.

Acest algoritm permite ceasurilor să își asume responsabilitățile ceasurilor de mare măestrie, atunci când ceasurile de mare măestrie superioare pierd semnalul GPS, se deconectează de la rețea etc.

Tranzițiile între stări conform BMCA sunt prezentate sumar în următorul grafic:


Informațiile despre ceasuri de la celălalt capăt al „cablului” sunt trimise într-un mesaj special (mesaj de anunțare). Odată ce aceste informații sunt primite, algoritmul mașinii de stări este activat și se compară care ceas este mai bun. Portul ceasurilor superioare devine ceas principal.

Ierarhia simplă este reprezentată în schema de mai jos. Cărțile 1, 2, 3, 4, 5 pot conține ceasuri transparente (Transparent clock), dar nu participă la stabilirea ierarhiei „Ceasuri principale – Ceasuri secundare”.

Faza 2 — Sincronizarea ceasurilor obișnuite și a ceasurilor de frontieră

Imediat după stabilirea ierarhiei „Ceasuri principale – Ceasuri secundare” începe faza de sincronizare a ceasurilor obișnuite și a ceasurilor de frontieră.

Pentru sincronizare, ceasurile principale trimit ceasurilor secundare un mesaj care conține un timestamp.

Ceasurile principale pot fi:

• unice;
• dual.

Ceasurile unice pentru sincronizare trimit un singur mesaj Sync.

Ceasurile duale pentru sincronizare utilizează două mesaje – Sync și Follow_Up.

Pentru faza de sincronizare pot fi utilizate două mecanisme:

• Mecanismul de cerere-răspuns pentru întârziere (Delay request-response mechanism).
• Mecanismul de măsurare a întârzierei nodului vecin (Peer delay measurement mechanism).

La început, să analizăm aceste mecanisme în cel mai simplu caz – atunci când nu se utilizează ceasuri transparente.

Mecanismul de cerere-răspuns pentru întârziere (Delay request-response mechanism)

Mecanismul presupune două etape:

1. Măsurarea întârzierii în transmiterea mesajului între ceasurile principale și cele secundare. Aceasta se face prin mecanismul de cerere-răspuns pentru întârziere.
2. Se efectuează corectarea diferenței de timp precis.

Măsurarea întârzierii


t1 – Timpul de trimitere a mesajului Sync de către ceasurile principale; t2 – Timpul de primire a mesajului Sync de către ceasurile secundare; t3 – Timpul de trimitere a cererii de întârziere (Delay_Req) de către ceasurile secundare; t4 – Timpul de primire a Delay_Req de către ceasurile principale.

Când ceasurile secundare cunosc timpul t1, t2, t3 și t4, ele pot calcula întârzierea medie la transmiterea mesajului de sincronizare (tmpd). Aceasta se calculează după cum urmează:

La transmiterea mesajului Sync și a Follow_Up se calculează întârzierea de timp de la master la slave – t-ms.

La transmiterea mesajelor Delay_Req și Delay_Resp se calculează întârzierea de timp de la slave la master – t-sm.

Dacă între aceste două valori apare o asimetie, atunci apare o eroare de corecție a timpului exact. Eroarea este determinată de faptul că întârzierea calculată este media întârziatelor t-ms și t-sm. Dacă întârzierea nu sunt egale între ele, atunci vom corecta timpul imprecis.

Corecția deplasării timpului exact

După ce întârzierea dintre ceasurile principale și cele secundare este cunoscută, ceasurile secundare efectuează corecția timpului.

Ceasurile secundare utilizează mesajul Sync și mesajul opțional Follow_Up pentru a calcula deplasarea timpului exact la transmiterea pachetului de la ceasurile principale la cele secundare. Deplasarea este calculată conform următoarei formule:

Mecanismul pentru măsurarea întârzierei nodului vecin (Peer delay measurement mechanism)

Acest mecanism utilizează de asemenea două etape pentru sincronizare:

1. Dispozitivele măsoară întârzierea timpului către toți vecinii prin toate porturile. Pentru aceasta, ele utilizează mecanismul de întârziere peer.
2. Corecția deplasării timpului exact.

Măsurarea întârzierei între dispozitive care suportă modul Peer-to-Peer

Întârzierea între porturile care suportă mecanismul peer-to-peer este măsurată folosind următoarele mesaje:

Când portul 1 cunoaște timpul t1, t2, t3 și t4, el poate calcula întârzierea medie (tmld). Aceasta se calculează conform următoarei formule:

Apoi, portul utilizează această valoare la calcularea câmpului de corecție pentru fiecare mesaj Sync sau mesajul opțional Follow_Up care trece prin acest dispozitiv.

Întârzierea finală va fi egală cu suma întârzierei la transmiterea prin acest dispozitiv, întârzierea medie la transmiterea prin canalul de date și întârzierea deja conținută în acest mesaj, inclusă pe dispozitivele superioare.

Mesajele Pdelay_Req, Pdelay_Resp și opțional Pdelay_Resp_Follow_Up permit obținerea întârzierii de la maestru la slaiv și de la slaiv la maestru (circulară).

Orice asimetrie între aceste două valori va introduce o eroare de corectare a decalajului de timp precis.

Corectarea decalajului de timp precis

Ceasurile slave utilizează mesajul Sync și mesajul opțional Follow_Up pentru a calcula decalajul de timp precis la transferul pachetului de la ceasurile principale la cele slave. Decalajul este calculat conform următoarei formule:

Avantajele corectării mecanismului peer-to-peer – decalajul fiecărui mesaj Sync sau Follow_Up este calculat pe parcursul transmiterii în rețea. Prin urmare, modificarea traseului de transmitere nu va afecta deloc acuratețea corectării.

Când se folosește acest mecanism, sincronizarea timpului nu necesită calcularea decalajului de timp pe traseul parcurs de pachetul de sincronizare, așa cum se face în schimbul de bază. Asta înseamnă că mesajele Delay_Req și Delay_Resp nu sunt trimise. În această metodă, decalajul dintre ceasurile principale și cele slave este pur și simplu sumat în câmpul de corectare al fiecărui mesaj Sync sau Follow_Up.

Un alt avantaj – ceasurile principale sunt descărcate de obligația de a procesa mesajele Delay_Req.

Modurile de operare ale ceasurilor transparente

În consecință, acestea au fost exemple simple. Acum să presupunem că pe calea de sincronizare apar comutatoare.

Dacă se folosesc comutatoare fără suport pentru PTPv2, atunci pachetul de sincronizare va fi întârziat pe comutator cu aproximativ 10 μs.

Comutatoarele cu suport pentru PTPv2, conform terminologiei IEEE 1588v2, sunt numite ceasuri transparente (Transparent clock). Ceasurile transparente nu se sincronizează de la ceasurile principale și nu participă în ierarhia „Ceasuri principale – Ceasuri slave”, dar la transmiterea mesajelor de sincronizare, acestea rețin cât de mult mesajul a fost întârziat pe ele. Acest lucru permite corectarea decalajului de timp.

Ceasurile transparente pot funcționa în două moduri:

• End-to-End.
• Peer-to-Peer.

End-to-End (E2E)

Ceasurile transparente E2E transmit mesajele Sync și mesajele asociate Follow_Up pe toate porturile. Chiar și pe cele care sunt blocate de anumite protocoale (de exemplu, RSTP).

Comutatorul amintește marca de timp când pachetul Sync (Follow_Up) a fost primit la port și când a fost trimis de la port. Pe baza acestor două mărci de timp, se calculează timpul de procesare al mesajului de către comutator. În standard, acest timp se numește timpul de rezidență.

Timpul de procesare este adăugat în câmpul correctionField al mesajului Sync (ceasuri unistep) sau Follow_Up (ceasuri dualstep).

Ceasurile transparente E2E măsoară timpul de procesare pentru mesajele Sync și Delay_Req care trec prin comutator. Dar este important să înțelegi că întârzierea de timp între ceasurile maître și cele slave este calculată folosind mecanismul de solicitare-răspuns al întârzierii. Dacă ceasurile maître se schimbă sau calea de la ceasurile maître la cele slave se schimbă, atunci întârzierea este măsurată din nou. Acest lucru mărește timpul de tranziție în cazul unor modificări în rețea.

Ceasurile transparente P2P, pe lângă măsurarea timpului de procesare al mesajului de către comutator, măsoară întârzierea pe canalul de transfer de date până la cel mai apropiat vecin, utilizând mecanismul de măsurare a întârzierii nodului vecin.

Întârzierile sunt măsurate pe fiecare canal în ambele direcții, inclusiv pe canalele care sunt blocate de un anumit protocol (de exemplu, RSTP). Acest lucru permite calcularea imediată a unei noi întârzieri pe calea de sincronizare, dacă ceasurile gromaster se schimbă sau dacă topologia rețelei se schimbă.

Timpul de procesare al mesajelor de către comutatoare și timpul de întârziere se acumulează în timpul transmiterii mesajelor Sync sau Follow_Up.

Tipuri de suport PTPv2 de către comutatoare

Comutatoarele pot suporta PTPv2:

• software;
• hardware.

În cazul unei implementări software a protocoalelor PTPv2, comutatorul solicită marca de timp de la firmware. Problema este că firmware-ul funcționează ciclic și va trebui să aștepte până când finalizează ciclul curent, va prelua solicitarea și, după finalizarea ciclului următor, va emite marca de timp. Tot acest proces va lua timp, iar noi vom obține o întârziere, deși nu atât de semnificativă cum va fi fără suport software pentru PTPv2.

Respectarea preciziei necesare este posibilă doar cu suport hardware PTPv2. În acest caz, emiterea mărcii de timp este realizată de un ASIC special instalat la port.

Formatul mesajului

Toate mesajele PTP constau din următoarele câmpuri:

• Header – 34 de biți.
• Body – dimensiunea variază în funcție de tipul mesajului.
• Suffix – opțional.

Header

Câmpul Header este identic pentru toate mesajele PTP. Dimensiunea sa este de 34 de octeți.

Formatul câmpului Header:

messageType – conține tipul mesajului transmis, de exemplu, Sync, Delay_Req, PDelay_Req etc.

messageLength – conține dimensiunea totală a mesajului PTP, inclusiv header, body și suffix (dar exclude octeții de umplere).

domainNumber – definește la ce domeniu PTP aparține mesajul.

Domeniu – acesta este un grup de ceasuri diferite, adunate într-un singur grup logic și sincronizate dintr-o sursă principală, dar nu neapărat sincronizate cu ceasuri care aparțin altui domeniu.

flags – acest câmp conține diverse flaguri pentru identificarea stării mesajului.

correctionField – conține timpul de întârziere în nanosecunde. Timpul de întârziere include întârzierile de transmisie prin ceasuri transparente, precum și întârzierile de transmisie prin canal în modul Peer-to-Peer.

sourcePortIdentity – acest câmp conține informații despre portul de la care a fost inițial trimis acest mesaj.

sequenceID – conține un număr de identificare pentru mesaje individuale.

controlField – câmp artefact=) A rămas din prima versiune a standardului și conține informații despre tipul acestui mesaj. Practic, este același lucru cu messageType, dar cu mai puține opțiuni.

logMessageInterval – acest câmp este definit de tipul mesajului.

Corpul

După cum a fost discutat mai sus, există mai multe tipuri de mesaje. Aceste tipuri sunt descrise mai jos:

Mesajul Announce
Mesajul Announce este folosit pentru a „anunța” alte ceasuri dintr-un domeniu despre parametrii săi. Acest mesaj permite stabilirea unei ierarhii „Ceasuri principale – Ceasuri secundare”.


Mesajul Sync
Mesajul de sincronizare (Sync) este trimis de ceasurile principale și conține timpul ceasului principal la momentul în care mesajul Sync a fost creat. Dacă ceasurile principale sunt cu două etape, atunci timestamp-ul din mesajul Sync va fi egal cu 0, iar timestamp-ul actual va fi trimis în mesajul asociat Follow_Up. Mesajul Sync este utilizat pentru ambele mecanisme de măsurare a întârzierii.

Mesajul este transmis prin Multicast. Opțional, se poate utiliza Unicast.

Mesajul Delay_Req

Formatul mesajului Delay_Req este identic cu cel al mesajului Sync. Ceasurile secundare trimit Delay_Req. Acesta conține timpul de trimitere a Delay_Req de către ceasurile secundare. Acest mesaj este utilizat doar pentru mecanismul de solicitare-răspuns al întârzierii.

Mesajul este transmis prin Multicast. Opțional, se poate utiliza Unicast.

Mesaj Follow_Up

Mesajul Follow_Up este trimis opțional de către ceasurile master și conține timpul de trimitere. mesaje Sync mesajul master. Mesajul Follow_Up este trimis doar de ceasurile master cu două etape.

Mesajul Follow_Up este utilizat pentru ambele mecanisme de măsurare a întârzierii.

Mesajul este transmis prin Multicast. Opțional, se poate utiliza Unicast.

Mesaj Delay_Resp

Mesajul Delay_Resp este trimis de ceasurile master. Acesta conține timpul de primire a Delay_Req de către ceasurile master. Acest mesaj este utilizat doar pentru mecanismul de solicitare-răspuns al întârzierii.

Mesajul este transmis prin Multicast. Opțional, se poate utiliza Unicast.

Mesaj Pdelay_Req

Mesajul Pdelay_Req este trimis de dispozitivul care solicită întârzirea. Acesta conține timpul de trimitere a mesajului de pe portul acestui dispozitiv. Pdelay_Req este utilizat doar pentru mecanismul de măsurare a întârzierii nodului vecin.

Mesaj Pdelay_Resp

Mesajul Pdelay_Resp este trimis de dispozitivul care a primit solicitarea de întârzire. Acesta conține timpul de primire a mesajului Pdelay_Req de către acest dispozitiv. Mesajele Pdelay_Resp sunt utilizate doar pentru mecanismul de măsurare a întârzierii nodului vecin.

Mesaj Pdelay_Resp_Follow_Up

Mesajul Pdelay_Resp_Follow_Up este trimis opțional de către dispozitivul care a primit solicitarea de întârzire. Acesta conține timpul de primire a mesajului Pdelay_Req de către acest dispozitiv. Mesajul Pdelay_Resp_Follow_Up este trimis doar de ceasurile master cu două etape.

De asemenea, acest mesaj poate fi utilizat pentru timpul de execuție în loc de marca temporală. Timpul de execuție este timpul de la momentul primirii Pdelay-Req până la trimiterea Pdelay_Resp.

Pdelay_Resp_Follow_Up sunt utilizate doar pentru mecanismul de măsurare a întârzierii nodului vecin.

Mesaje de gestionare (Mesaj Management)

Mesajele de gestionare PTP sunt necesare pentru transmiterea informațiilor între unul sau mai multe ceasuri și nodul de gestionare.

Transmitere în LV

Mesajul PTP poate fi transmis la două niveluri:

• Nivelul de rețea – ca parte a datelor IP.
• Nivelul de legătură – ca parte a cadrelor Ethernet.

Transmiterea mesajului PTP prin UDP prin IP prin Ethernet

PTP prin UDP prin Ethernet

Profile

PTP are o serie de parametri "flexibili" care trebuie configurați. De exemplu:

• Opțiuni BMCA.
• Mecanismul de măsurare a întârzierii.
• Intervale și valori inițiale pentru toți parametrii configurabili etc.

Și, în ciuda faptului că anterior am spus că dispozitivele PTPv2 sunt compatibile între ele, în realitate, nu este așa. Dispozitivele trebuie să aibă setări identice pentru a interacționa.

Așadar, există așa-numitele profiluri PTPv2. Profilurile sunt grupuri configurate de setări și restricții specifice ale protocolului, astfel încât să se poată realiza sincronizarea timpului pentru o aplicație specifică.

Standardul IEEE 1588v2 descrie un singur profil – „Profilul Implicit”. Toate celelalte profiluri sunt create și descrise de diverse organizații și asociații.

De exemplu, profilul pentru energia electrică sau Profilul PTPv2 Power a fost creat de Comitetul de Relații cu Sistemele de Energie și de Comitetul de Substație din cadrul IEEE Power and Energy Society. Profilul poartă numele IEEE C37.238-2011.

Profilul descrie că PTP poate fi transmis:

• Numai prin rețele L2 (adică Ethernet, HSR, PRP, nu IP).
• Mesajele sunt transmise doar prin multicast.
• Ca mecanism de măsurare a întârzierii se utilizează mecanismul de măsurare a întârzierii Peer.

Domeniul implicit – 0, domeniul recomandat – 93.

În filosofia creării C37.238-2011 a fost dorința de a reduce numărul caracteristicilor opționale și de a păstra doar funcțiile necesare pentru o interacțiune fiabilă între dispozitive și creșterea stabilității sistemului.

De asemenea, a fost definită frecvența de transmitere a mesajelor:

În esență, pentru alegere este disponibil un singur parametru – tipul ceasurilor principale (un singur nivel sau două niveluri).

Precizia trebuie să fie de maximum 1 μs. Cu alte cuvinte, într-o cale de sincronizare pot fi incluse maximal 15 ceasuri transparente sau 3 ceasuri de limită.

Sursa: habr.com