Introduzione
Il concetto di costruzione della «Sottostazione Digitale» nell'energia elettrica richiede una sincronizzazione con una precisione di 1 µs. Anche per le transazioni finanziarie è necessaria una precisione in microsecondi. In queste applicazioni, la precisione del tempo NTP non è più sufficiente.
Il protocollo di sincronizzazione PTPv2, descritto nello standard IEEE 1588v2, consente di raggiungere una precisione di sincronizzazione nell'ordine di decine di nanosecondi. PTPv2 permette di inviare pacchetti di sincronizzazione attraverso reti L2 e L3.
Le principali aree in cui viene applicato PTPv2 sono:
- energia;
- apparecchiature di controllo e misura;
- complesso della difesa e industriale;
- telecomunicazioni;
- settore finanziario.
Questo post esplora come funziona il protocollo di sincronizzazione PTPv2.
Abbiamo più esperienza nell'industria e ci troviamo spesso a confrontarci con questo protocollo nelle applicazioni energetiche. Di conseguenza, daremo una panoramica con un occhio di riguardo .
Perché è necessario?
Attualmente, nello standard 34.01-21-004-2019 di PAO «Rosseti» e nello standard 56947007-29.240.10.302-2020 di PAO «FSK EES» sono presenti requisiti per l'organizzazione del bus di processo con garanzia di sincronizzazione temporale tramite PTPv2.
Questo è dovuto al fatto che al bus di processo si collegano terminali di protezione relè e dispositivi di misura, i quali attraverso il bus di processo, tramite i cosiddetti flussi SV (flussi multicast), trasmettono valori istantanei di corrente e tensione.
I terminali di protezione relè utilizzano questi valori per implementare le protezioni delle connessioni. Se la precisione delle misurazioni temporali è bassa, alcune protezioni possono attivarsi erroneamente.
Ad esempio, una vittima di una «debole» sincronizzazione temporale possono essere le protezioni di assoluta selettività. Spesso la logica di tali protezioni si basa sul confronto di due grandezze. Se le grandezze divergono di un valore sufficientemente elevato, la protezione si attiva. Se queste grandezze vengono misurate con una precisione temporale di 1 ms, si possono ottenere grandi differenze dove i valori sono in realtà nella norma, se misurati con una precisione di 1 µs.
Versioni PTP
Il protocollo PTP è stato descritto per la prima volta nel 2002 nello standard IEEE 1588-2002 ed era denominato "Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems". Nel 2008 è stato pubblicato lo standard aggiornato IEEE 1588-2008, che descrive la versione PTP 2. In questa versione del protocollo è stata migliorata la precisione e la stabilità, ma non è stata mantenuta la retrocompatibilità con la prima versione del protocollo. Inoltre, nel 2019 è stata rilasciata la versione dello standard IEEE 1588-2019, che descrive PTP v2.1. Questa versione aggiunge piccoli miglioramenti a PTPv2 ed è retrocompatibile con PTPv2.
In altre parole, abbiamo la seguente situazione con le versioni:
PTPv1
(IEEE 1588-2002)
PTPv2
(IEEE 1588-2008)
PTPv2.1
(IEEE 1588-2019)
PTPv1 (IEEE 1588-2002)
—
Incompatibili
Incompatibili
PTPv2 (IEEE 1588-2008)
Incompatibili
—
Compatibili
PTPv2.1 (IEEE 1588-2019)
Incompatibili
Compatibili
—
Ma, come sempre, ci sono sfumature.
L'incompatibilità tra PTPv1 e PTPv2 implica che un dispositivo che supporta PTPv1 non potrà sincronizzarsi con orologi di alta precisione che funzionano su PTPv2. Per la sincronizzazione utilizzano diversi formati di messaggio.
Tuttavia, è comunque possibile combinare dispositivi con PTPv1 e dispositivi con PTPv2 nella stessa rete. A tal fine, alcuni produttori consentono di selezionare la versione del protocollo sulle porte degli orologi di frontiera. Ciò significa che gli orologi di frontiera possono sincronizzarsi tramite PTPv2 e nel contempo sincronizzare altri orologi collegati a loro sia tramite PTPv1 che PTPv2.
Dispositivi PTP. Quali sono e come si differenziano?
Lo standard IEEE 1588v2 descrive diversi tipi di dispositivi. Tutti sono elencati nella tabella.
I dispositivi interagiscono tra loro attraverso una rete locale, utilizzando PTP.
I dispositivi PTP sono chiamati orologi. Tutti gli orologi prendono il tempo preciso da orologi grandmaster.
Esistono 5 tipi di orologi:
Grandmaster clock (Orologio Master)
Fonte principale del tempo preciso. Spesso dotata di un'interfaccia per la connessione GPS.
Ordinary Clock (Orologio Ordinario)
Dispositivo con una porta che può essere master (orologio principale) o slave (orologio secondario)
Orologio principale (master)
È la fonte del tempo preciso, a cui si sincronizzano altri orologi
Orologi secondari (slave)
Dispositivo finale che si sincronizza con gli orologi principali
Boundary Clock (Orologio di Frontiera)
Dispositivo con più porte, che può essere master o slave.
Quindi, questi orologi possono sincronizzarsi dagli orologi principali superiori e sincronizzare gli orologi secondari inferiori.
Orologio Trasparente End-to-End
Dispositivo con porte multiple che non è né un orologio principale né un orologio secondario. Trasmette dati PTP tra due orologi.
Durante la trasmissione dei dati, l'orologio trasparente corregge tutti i messaggi PTP.
La correzione avviene aggiungendo un tempo di ritardo a questo dispositivo nel campo di correzione nell'intestazione del messaggio inviato.
Orologio Trasparente Peer-to-Peer
Dispositivo con porte multiple che non è né un orologio principale né un orologio secondario.
Trasmette dati PTP tra due orologi.
Durante la trasmissione dei dati, l'orologio trasparente corregge tutti i messaggi PTP Sync e Follow_Up (di cui si parlerà più dettagliatamente di seguito).
La correzione si ottiene aggiungendo al campo di correzione del pacchetto trasmesso il ritardo sul dispositivo di trasmissione e il ritardo sul canale di trasmissione dei dati.
Nodo di Gestione
Dispositivo che configura e diagnostica altri orologi
Gli orologi principali e secondari si sincronizzano tramite timestamp nei messaggi PTP. Ci sono due tipi di messaggi nel protocollo PTP:
- Messaggi di Evento – sono messaggi sincronizzati che presuppongono la generazione di un timestamp nel momento dell'invio del messaggio e nel momento della sua ricezione.
- Messaggi Generali – questi messaggi non richiedono timestamp, ma possono contenere timestamp per messaggi correlati.
Messaggi di Evento
Messaggi Generali
Sync
Delay_Req
Pdelay_Req
Pdelay_Resp
Annuncio
Follow_Up
Delay_Resp
Pdelay_Resp_Follow_Up
Gestione
Segnalazione
Di seguito saranno esaminati tutti i tipi di messaggi più in dettaglio.
Problemi principali di sincronizzazione
Durante la trasmissione del pacchetto di sincronizzazione attraverso una rete locale, esso viene ritardato dallo switch e dal canale di trasmissione dei dati. Qualsiasi switch darà un ritardo di circa 10 µs, che è inaccettabile per PTPv2. Infatti, sul dispositivo finale abbiamo bisogno di una precisione di 1 µs. (Questo nel caso dell'energia. Altre applicazioni possono richiedere anche maggiore precisione.)
Nell'IEEE 1588v2 sono descritti diversi algoritmi di funzionamento che permettono di registrare il tempo di ritardo e di correggerlo.
Algoritmo di funzionamento
In condizioni normali, il protocollo funziona in due fasi.
- Fase 1 – stabilimento della gerarchia "Orologi Principali – Orologi Secondari".
- Fase 2 – sincronizzazione degli orologi tramite il meccanismo End-to-End o Peer-to-Peer.
Fase 1 — Impostazione della gerarchia «Master-Slave»
Ogni porta di orologi normali o di bordo ha un numero definito di stati (orologi slave ed orologi master). Lo standard descrive l'algoritmo di transizione tra questi stati. In programmazione, tale algoritmo è chiamato automa a stati finiti o macchina a stati (ulteriori dettagli su Wiki).
Questo automa a stati utilizza l'algoritmo Best Master Clock Algorithm (BMCA) per stabilire il master durante il collegamento di due orologi.
Questo algoritmo consente agli orologi di assumere i doveri degli orologi master quando gli orologi master superiori perdono il segnale GPS, si scollegano dalla rete, ecc.
Le transizioni tra stati secondo il BMCA sono brevemente rappresentate nello schema sottostante:
Le informazioni sugli orologi dall'altro lato del «cavo» vengono inviate in un messaggio speciale (Announce message). Quando queste informazioni vengono ricevute, l'algoritmo della macchina a stati viene eseguito e viene effettuato un confronto per determinare quale orologio sia migliore. La porta sull'orologio migliore diventa l'orologio master.
Una gerarchia semplice è rappresentata nello schema sottostante. I percorsi 1, 2, 3, 4, 5 possono contenere orologi trasparenti (Transparent clock), ma non partecipano all'impostazione della gerarchia «Orologi master – Orologi slave».
Fase 2 — Sincronizzazione degli orologi normali e di bordo
Subito dopo l'impostazione della gerarchia «Orologi master – Orologi slave» inizia la fase di sincronizzazione degli orologi normali e di bordo.
Per la sincronizzazione, gli orologi master inviano agli orologi slave un messaggio contenente un timestamp.
Gli orologi master possono essere:
- a una fase;
- a due fasi.
Gli orologi a una fase per la sincronizzazione inviano un singolo messaggio Sync.
Gli orologi a due fasi per la sincronizzazione utilizzano due messaggi: Sync e Follow_Up.
Per la fase di sincronizzazione possono essere utilizzati due meccanismi:
- Meccanismo di richiesta-risposta per il ritardo (Delay request-response mechanism).
- Meccanismo di misurazione del ritardo del nodo vicino (Peer delay measurement mechanism).
Iniziamo a considerare questi meccanismi nel caso più semplice — quando non vengono utilizzati orologi trasparenti.
Meccanismo di richiesta-risposta per il ritardo (Delay request-response mechanism)
Il meccanismo prevede due passaggi:
- Misurazione del ritardo nella trasmissione del messaggio tra orologi master e slave. Viene effettuata tramite il meccanismo di richiesta-risposta per il ritardo.
- Viene eseguita la correzione dello spostamento del tempo esatto.
Misurazione del ritardo
t1 – Tempo di invio del messaggio Sync da parte degli orologi principali; t2 – Tempo di ricezione del messaggio Sync da parte degli orologi secondari; t3 – Tempo di invio della richiesta di ritardo (Delay_Req) da parte degli orologi secondari; t4 – Tempo di ricezione di Delay_Req da parte degli orologi principali.
Quando gli orologi secondari conoscono i tempi t1, t2, t3 e t4, possono calcolare il ritardo medio nella trasmissione del messaggio di sincronizzazione (tmpd). Questo viene calcolato nel seguente modo:
Durante la trasmissione del messaggio Sync e Follow_Up si calcola il ritardo di tempo dal master allo slave – t-ms.
Durante la trasmissione dei messaggi Delay_Req e Delay_Resp si calcola il ritardo di tempo dallo slave al master – t-sm.
Se tra questi due valori c'è qualche asimmetria, si genera un errore di correzione del tempo esatto. L'errore è determinato dal fatto che il ritardo calcolato è la media dei ritardi t-ms e t-sm. Se i ritardi non sono uguali tra loro, correggeremo il tempo in modo impreciso.
Correzione dello sfasamento del tempo esatto
Dopo che il ritardo tra orologi principali e secondari è noto, gli orologi secondari eseguono la correzione del tempo.
Gli orologi secondari utilizzano il messaggio Sync e il messaggio opzionale Follow_Up per calcolare lo sfasamento del tempo esatto durante la trasmissione del pacchetto dagli orologi principali agli orologi secondari. Lo sfasamento viene calcolato secondo la seguente formula:
Meccanismo di misurazione del ritardo del nodo vicino (Peer delay measurement mechanism)
Questo meccanismo utilizza anch'esso due passaggi per la sincronizzazione:
- I dispositivi misurano il ritardo di tempo verso tutti i vicini attraverso tutte le porte. Per questo utilizzano il meccanismo di ritardo peer.
- Correzione dello sfasamento del tempo esatto.
Misurazione del ritardo tra dispositivi che supportano la modalità Peer-to-Peer
Il ritardo tra le porte che supportano il meccanismo peer-to-peer è misurato utilizzando i seguenti messaggi:
Quando la porta 1 conosce i tempi t1, t2, t3 e t4, può calcolare il ritardo medio (tmld). Questo viene calcolato secondo la seguente formula:
Successivamente, la porta utilizza questo valore nel calcolo del campo di correzione per ciascun messaggio Sync o messaggio opzionale Follow_Up che passa attraverso questo dispositivo.
Il ritardo totale sarà uguale alla somma del ritardo nella trasmissione attraverso questo dispositivo, del ritardo medio nella trasmissione attraverso il canale dati e del ritardo già presente in questo messaggio, incluso in dispositivi superiori.
I messaggi Pdelay_Req, Pdelay_Resp e l'opzionale Pdelay_Resp_Follow_Up consentono di ottenere il ritardo dal maestro allo slave e dallo slave al maestro (circolare).
Qualsiasi asimmetria tra questi due valori introdurrà un errore nella correzione del ritardo dell'orario preciso.
Correzione del ritardo dell'orario preciso
Gli orologi slavi utilizzano il messaggio Sync e l'opzionale messaggio Follow_Up per calcolare il ritardo dell'orario preciso durante la trasmissione del pacchetto dagli orologi principali agli orologi slavi. Il ritardo viene calcolato secondo la seguente formula:
I vantaggi della correzione del meccanismo peer-to-peer – il ritardo di ciascun messaggio Sync o Follow_Up viene calcolato mentre viene trasmesso nella rete. Di conseguenza, anche il cambiamento del percorso di trasmissione non influirà in alcun modo sulla precisione della correzione.
Utilizzando questo meccanismo, la sincronizzazione dell'orario non richiede il calcolo del ritardo temporale sul percorso del pacchetto di sincronizzazione, come avviene nello scambio di base. Cioè, i messaggi Delay_Req e Delay_Resp non vengono inviati. In questo metodo, il ritardo tra gli orologi principali e slavi viene semplicemente sommato nel campo di correzione di ciascun messaggio Sync o Follow_Up.
Un altro vantaggio è che gli orologi principali sono alleggeriti dall'obbligo di elaborare i messaggi Delay_Req.
Modalità di funzionamento degli orologi trasparenti
Di conseguenza, sono stati analizzati semplici esempi. Ora supponiamo che si presentino switch lungo il percorso di sincronizzazione.
Se si utilizzano switch senza supporto per PTPv2, il pacchetto di sincronizzazione subirà un ritardo nello switch di circa 10 µs.
Gli switch con supporto PTPv2 nella terminologia IEEE 1588v2 sono chiamati orologi trasparenti (Transparent clock). Gli orologi trasparenti non vengono sincronizzati dagli orologi principali e non partecipano all' gerarchia "Orologi principali – Orologi slavi", ma durante la trasmissione dei messaggi di sincronizzazione memorizzano quanto tempo messaggio è stato ritardato su di essi. Ciò consente di correggere il ritardo temporale.
Gli orologi trasparenti possono operare in due modalità:
- End-to-End.
- Peer-to-Peer.
End-to-End (E2E)
Gli orologi trasparenti E2E trasmettono i messaggi Sync e i messaggi correlati Follow_Up a tutte le porte. Anche a quelle bloccate da alcuni protocolli (ad esempio, RSTP).
Lo switch registra il timestamp in cui il pacchetto Sync (Follow_Up) è stato ricevuto sulla porta e quando è stato inviato dalla porta. Sulla base di questi due timestamp viene calcolato il tempo di elaborazione del messaggio da parte dello switch. In standard, questo tempo è chiamato residence time.
Il tempo di elaborazione viene aggiunto al campo correctionField del messaggio Sync (orologi a singolo stadio) o Follow_Up (orologi a doppio stadio).
Gli orologi trasparenti E2E misurano il tempo di elaborazione per i messaggi Sync e Delay_Req che passano attraverso lo switch. Ma è importante capire che il ritardo di tempo tra gli orologi principali e secondari viene calcolato tramite il meccanismo di richiesta-risposta del ritardo. Se gli orologi principali cambiano o cambia il percorso dagli orologi principali a quelli secondari, il ritardo viene misurato nuovamente. Questo aumenta il tempo di transizione in caso di modifiche nella rete.
Gli orologi trasparenti P2P, oltre a misurare il tempo di elaborazione del messaggio da parte dello switch, misurano il ritardo sul canale di trasmissione dati fino al vicino più vicino, utilizzando il meccanismo di misurazione del ritardo del nodo vicino.
Il ritardo viene misurato su ciascun canale in entrambe le direzioni, compresi i canali bloccati da qualche protocollo (ad esempio, RSTP). Questo consente di calcolare immediatamente il nuovo ritardo sul percorso di sincronizzazione se gli orologi grandmaster o la topologia di rete cambiano.
Il tempo di elaborazione dei messaggi da parte degli switch e il tempo di ritardo si accumulano durante la trasmissione dei messaggi Sync o Follow_Up.
Tipi di supporto PTPv2 da parte degli switch
Gli switch possono supportare PTPv2:
- in modo software;
- in modo hardware.
Con l'implementazione software del protocollo PTPv2, lo switch richiede un timestamp dal firmware. Il problema è che il firmware funziona ciclicamente e bisogna aspettare che completi il ciclo corrente, prenda in carico la richiesta e alla fine del ciclo successivo fornisca il timestamp. Questo richiederà tempo, e quindi avremo un ritardo, sebbene non così sostanziale come senza supporto software per PTPv2.
Per garantire la necessaria precisione è possibile solo con il supporto hardware di PTPv2. In questo caso, la fornitura del timestamp viene eseguita da un ASIC speciale installato sulla porta.
Formato del messaggio
Tutti i messaggi PTP sono composti dai seguenti campi:
- Header – 34 byte.
- Body – la dimensione dipende dal tipo di messaggio.
- Suffix – opzionale.
Header
Il campo Header è identico per tutti i messaggi PTP. La sua dimensione è di 34 byte.
Formato del campo Header:
messageType – indica il tipo di messaggio trasmesso, ad esempio Sync, Delay_Req, PDelay_Req, e così via.
messageLength – contiene la dimensione totale del messaggio PTP, inclusi header, body e suffix (escludendo i byte di riempimento).
domainNumber – determina a quale dominio appartiene il messaggio PTP.
Dominio – è composto da diversi orologi riuniti in un unico gruppo logico e sincronizzati da un orologio principale, ma non necessariamente sincronizzati con gli orologi appartenenti a un altro dominio.
flags – questo campo contiene vari flag per identificare lo stato del messaggio.
correctionField – contiene il tempo di ritardo in nanosecondi. Il tempo di ritardo include il ritardo di trasmissione attraverso orologi trasparenti, oltre al ritardo nella trasmissione attraverso il canale quando si utilizza la modalità Peer-to-Peer.
sourcePortIdentity – questo campo contiene informazioni su quale porta ha originariamente inviato il messaggio.
sequenceID – contiene un numero identificativo per i messaggi individuali.
controlField – campo artefatto =) È rimasto dalla prima versione dello standard e contiene informazioni sul tipo di messaggio. In sostanza, è la stessa cosa del messageType, ma con meno opzioni.
logMessageInterval – questo campo è determinato dal tipo di messaggio.
Body
Come discusso sopra, esistono diversi tipi di messaggi. Questi tipi sono descritti di seguito:
Messaggio Announce
Il messaggio Announce viene utilizzato per "informare" gli altri orologi all'interno di un dominio dei propri parametri. Questo messaggio consente di stabilire una gerarchia "Orologi principali – Orologi subordinati".
Messaggio Sync
Il messaggio di sincronizzazione (Sync) viene inviato dagli orologi principali e contiene il tempo degli orologi principali al momento in cui il messaggio Sync è stato creato. Se gli orologi principali sono a doppio passo, il timestamp nel messaggio Sync sarà impostato a 0, mentre il timestamp attuale sarà inviato nel messaggio associato Follow_Up. Il messaggio Sync viene utilizzato per entrambi i meccanismi di misurazione del ritardo.
Il messaggio è trasmesso tramite Multicast. In modo opzionale, è possibile utilizzare Unicast.
Messaggio Delay_Req
Il formato del messaggio Delay_Req è identico a quello del messaggio Sync. Gli orologi subordinati inviano Delay_Req. Contiene il tempo di invio del Delay_Req da parte degli orologi subordinati. Questo messaggio è utilizzato solo per il meccanismo di richiesta-risposta del ritardo.
Il messaggio è trasmesso tramite Multicast. In modo opzionale, è possibile utilizzare Unicast.
Messaggio Follow_Up
Il messaggio Follow_Up viene inviato facoltativamente dai cronometri principali e contiene l'orario di invio messaggi Sync dal maestro. Il messaggio Follow_Up è inviato solo dai cronometri principali a due fasi.
Il messaggio Follow_Up è utilizzato per entrambi i meccanismi di misurazione del ritardo.
Il messaggio è trasmesso tramite Multicast. In modo opzionale, è possibile utilizzare Unicast.
Messaggio Delay_Resp
Il messaggio Delay_Resp è inviato dai cronometri principali. Contiene il tempo di ricezione di Delay_Req da parte dei cronometri principali. Questo messaggio è utilizzato solo per il meccanismo di richiesta-risposta del ritardo.
Il messaggio è trasmesso tramite Multicast. In modo opzionale, è possibile utilizzare Unicast.
Messaggio Pdelay_Req
Il messaggio Pdelay_Req è inviato dall'apparato che richiede un ritardo. Contiene l'orario di invio del messaggio dalla porta di questo apparato. Pdelay_Req è utilizzato solo per il meccanismo di misurazione del ritardo del nodo adiacente.
Messaggio Pdelay_Resp
Il messaggio Pdelay_Resp è inviato dall'apparato che ha ricevuto la richiesta di ritardo. Contiene il tempo di ricezione del messaggio Pdelay_Req da parte di questo apparato. I messaggi Pdelay_Resp sono utilizzati solo per il meccanismo di misurazione del ritardo del nodo adiacente.
Messaggio Pdelay_Resp_Follow_Up
Il messaggio Pdelay_Resp_Follow_Up è inviato facoltativamente dall'apparato che ha ricevuto la richiesta di ritardo. Contiene il tempo di ricezione del messaggio Pdelay_Req da parte di questo apparato. Il messaggio Pdelay_Resp_Follow_Up è inviato solo dai cronometri principali a due fasi.
Inoltre, questo messaggio può essere utilizzato per il tempo di esecuzione invece del timestamp. Il tempo di esecuzione è il tempo che intercorre dal momento di ricezione del Pdelay-Req fino all'invio del Pdelay_Resp.
I Pdelay_Resp_Follow_Up sono utilizzati solo per il meccanismo di misurazione del ritardo del nodo adiacente.
Messaggi di gestione (Messaggio Management)
I messaggi di gestione PTP sono necessari per la trasmissione delle informazioni tra uno o più orologi e il nodo di gestione.
Trasmissione in LV
Il messaggio PTP può essere trasmesso su due livelli:
- Livello di rete - come parte dei dati IP.
- Livello di collegamento - come parte del frame Ethernet.
Trasmissione del messaggio PTP tramite UDP su IP via Ethernet
PTP tramite UDP su Ethernet
Profili
PTP ha molti parametri "flessibili" che devono essere configurati. Ad esempio:
- Opzioni BMCA.
- Meccanismo di misurazione del ritardo.
- Intervalli e valori iniziali di tutti i parametri configurabili, ecc.
E nonostante abbiamo detto in precedenza che i dispositivi PTPv2 sono compatibili tra loro, in realtà non è così. I dispositivi devono avere impostazioni identiche per interagire.
Esistono quindi i cosiddetti profili PTPv2. I profili sono gruppi di impostazioni configurate e di limitazioni specifiche del protocollo, in modo da poter realizzare la sincronizzazione temporale per un'applicazione specifica.
Lo standard IEEE 1588v2 descrive solo un profilo: il “Default Profile”. Tutti gli altri profili sono stati creati e descritti da varie organizzazioni e associazioni.
Ad esempio, il profilo per il settore energetico o PTPv2 Power Profile è stato creato dal comitato Power Systems Relaying Committee e dal comitato Substation Committee della IEEE Power and Energy Society. Questo profilo è noto come IEEE C37.238- 2011.
Il profilo descrive cosa può essere trasmesso tramite PTP:
- Solo attraverso reti L2 (cioè Ethernet, HSR, PRP, non IP).
- I messaggi sono trasmessi solo tramite multicast.
- Come meccanismo di misurazione del ritardo si utilizza il meccanismo di misurazione del ritardo dei peer.
Il dominio predefinito è 0, il dominio raccomandato è 93.
La filosofia alla base della creazione del C37.238- 2011 era quella di ridurre il numero di caratteristiche opzionali e mantenere solo le funzioni necessarie per una comunicazione affidabile tra i dispositivi e per aumentare la stabilità del sistema.
Inoltre, è stata definita la frequenza di trasmissione dei messaggi:
Di fatto, è disponibile solo un parametro per la scelta: il tipo di orologio principale (monostadio o bistadio).
La precisione non deve superare 1 microsecondo. In altre parole, in un percorso di sincronizzazione possono esserci al massimo 15 orologi trasparenti o tre orologi di confine.
Fonte: habr.com
