Introduzione
Il concetto di costruzione di una «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 dallo 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 utilizzato PTPv2 sono:
- energia;
- strumentazione di controllo e misurazione;
- complesso militare-industriale;
- telecomunicazioni;
- settore finanziario.
In questo post analizziamo come funziona il protocollo di sincronizzazione PTPv2.
Abbiamo una notevole esperienza nell'industria e ci confrontiamo spesso con questo protocollo nelle applicazioni energetiche. Pertanto, anche la nostra panoramica sarà focalizzata .
Perché è necessario?
Attualmente, nelle normative 34.01-21-004-2019 di PJSC «Rosseti» e 56947007-29.240.10.302-2020 di PJSC «FSK EES» sono contenuti requisiti per l'organizzazione del bus di processo con garanzia di sincronizzazione temporale tramite PTPv2.
Questo è collegato al fatto che alla rete di processo si collegano terminali di protezione relè e dispositivi di misura, che attraverso la rete di processo, utilizzando 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 nel tempo è bassa, alcune protezioni possono attivarsi erroneamente.
Ad esempio, le protezioni di selettività assoluta possono essere vittime di una 'debole' sincronizzazione del tempo. Spesso, la logica di tali protezioni si basa sul confronto di due grandezze. Se le grandezze divergono di un valore abbastanza elevato, la protezione scatta. Se queste grandezze vengono misurate con una precisione di tempo di 1 ms, si può ottenere una grande differenza dove i valori sono in realtà normali, se misurati con una precisione di 1 µs.
Versioni PTP
Il protocollo PTP è stato inizialmente descritto nel 2002 nello standard IEEE 1588-2002 e portava il nome di «Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems». Nel 2008 è stato pubblicato uno standard aggiornato, l'IEEE 1588-2008, che descrive PTP Version 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 delle sfumature.
L'incompatibilità tra PTPv1 e PTPv2 implica che un dispositivo che supporta PTPv1 non potrà sincronizzarsi con orologi precisi che operano su PTPv2. Per la sincronizzazione, utilizzano formati di messaggio diversi.
È possibile integrare dispositivi con PTPv1 e dispositivi con PTPv2 nella stessa rete. Per questo motivo, alcuni produttori consentono di scegliere la versione del protocollo per le porte delle clock di confine. Ciò significa che le clock di confine possono sincronizzarsi tramite PTPv2 e allo stesso tempo sincronizzare altre clock collegate anche tramite PTPv1 e PTPv2.
Dispositivi PTP. Quali sono e in cosa si differenziano?
Lo standard IEEE 1588v2 descrive diversi tipi di dispositivi. Tutti sono elencati nella tabella.
I dispositivi interagiscono tra loro tramite una LAN, utilizzando PTP.
I dispositivi PTP sono chiamati clock. Tutte le clock prendono l'ora esatta dai clock di grandmaster.
Ci sono 5 tipi di clock:
Grandmaster clock
Fonte principale di tempo preciso. Spesso dotata di interfaccia per la connessione GPS.
Ordinary Clock
Dispositivo con una porta, che può essere master (clock principale) o slave (clock secondaria)
Clock master
È la fonte di tempo preciso, secondo la quale si sincronizzano altre clock
Clock slave
Dispositivo finale che si sincronizza con i clock master
Boundary Clock
Dispositivo con più porte, che può essere master o slave.
Cioè, questi orologi possono sincronizzarsi con orologi principali superiori e sincronizzare orologi secondari subordinati.
End-to-end Transparent Clock (Orologio Trasparente End-to-End)
Dispositivo con più porte, che non è né un orologio principale né un orologio secondario. Trasmette dati PTP tra due orologi.
Durante la trasmissione dei dati, gli orologi trasparenti correggono tutti i messaggi PTP.
La correzione avviene aggiungendo il tempo di latenza su questo dispositivo nel campo di correzione nell'intestazione del messaggio trasmesso.
Peer-to-Peer Transparent Clock (Orologio Trasparente Peer-to-Peer)
Dispositivo con più porte, che non è né un orologio principale né un orologio secondario.
Trasmette dati PTP tra due orologi.
Durante la trasmissione dei dati, gli orologi trasparenti correggono tutti i messaggi PTP Sync e Follow_Up (di cui si parla più avanti).
La correzione avviene aggiungendo al campo di correzione del pacchetto trasmesso la latenza sul dispositivo di trasmissione e la latenza sul canale di trasmissione.
Management Node (Nodo di Gestione)
Dispositivo che configura e diagnostica altri orologi
Gli orologi master e slave si sincronizzano mediante timestamp nei messaggi PTP. Ci sono due tipi di messaggi nel protocollo PTP:
- Event Messages – messaggi sincronizzati che prevedono la generazione di un timestamp al momento dell'invio e della ricezione del messaggio
- General Messages – questi messaggi non richiedono timestamp, ma possono contenere timestamp per messaggi correlati
Event Messages
General Messages
Sync
Delay_Req
Pdelay_Req
Pdelay_Resp
Announce
Follow_Up
Delay_Resp
Pdelay_Resp_Follow_Up
Management
Signaling
Tutti i tipi di messaggi saranno esaminati più in dettaglio.
Principali problemi di sincronizzazione
Quando un pacchetto di sincronizzazione viene trasmesso attraverso una rete locale, si verifica un ritardo nello switch e nel canale di trasmissione. Qualsiasi switch comporterà un ritardo di circa 10 μs, inaccettabile per PTPv2. Infatti, è necessaria una precisione di 1 μs sul dispositivo finale. (Questo è particolarmente rilevante per il settore energetico. Altre applicazioni possono richiedere una precisione ancora maggiore.)
Nell'IEEE 1588v2 vengono descritti diversi algoritmi operativi che consentono di misurare e correggere il ritardo temporale.
Algoritmo operativo
In condizioni normali, il protocollo opera in due fasi.
- Fase 1 — impostazione della gerarchia «Orari principali – Orari secondari».
- Fase 2 — sincronizzazione degli orari tramite il meccanismo End-to-End o Peer-to-Peer.
Fase 1 — Impostazione della gerarchia «Master-Slave»
Ogni porta di orari normali o di confine ha un certo numero di stati (orari secondari e orari principali). Lo standard descrive l'algoritmo di transizione tra questi stati. In programmazione, tale algoritmo è chiamato automa finale o macchina a stati (maggiori dettagli in Wiki).
Questo automa finale utilizza l'algoritmo Best Master Clock Algorithm (BMCA) per stabilire il master quando si collegano due orari.
Questo algoritmo consente agli orari di assumere le responsabilità degli orari grandmaster quando gli orari grandmaster superiori perdono il segnale GPS, si disconnettono dalla rete, ecc.
Le transizioni tra stati secondo il BMCA sono brevemente illustrate nel diagramma seguente:
Le informazioni sulle ore all'altro capo del «cavo» sono inviate in un messaggio speciale (Announce message). Quando queste informazioni sono ricevute, l'algoritmo della macchina a stati elabora e confronta quali orologi sono migliori. La porta sull'orologio migliore diventa l'orologio principale.
La semplice gerarchia è mostrata nello schema qui sotto. I percorsi 1, 2, 3, 4, 5 possono contenere orologi trasparenti (Transparent clock), ma non partecipano all'instaurazione della gerarchia «Orologi principali – Orologi secondari».
Fase 2 — Sincronizzazione degli orologi standard e di confine.
Subito dopo l'instaurazione della gerarchia «Orologi principali – Orologi secondari» inizia la fase di sincronizzazione degli orologi standard e di confine.
Per la sincronizzazione, gli orologi principali inviano agli orologi secondari un messaggio contenente un timestamp.
Gli orologi principali possono essere:
- monostadio;
- bistadio.
Gli orologi monostadio per la sincronizzazione inviano un unico messaggio Sync.
Gli orologi bistadio per la sincronizzazione utilizzano due messaggi – Sync e Follow_Up.
Per la fase di sincronizzazione possono essere utilizzati due meccanismi:
- Il meccanismo di richiesta-risposta per il delay (Delay request-response mechanism).
- Il meccanismo di misurazione del delay del nodo vicino (Peer delay measurement mechanism).
Iniziamo esaminando questi meccanismi nel loro caso più semplice: quando non vengono utilizzati orologi trasparenti.
Meccanismo di richiesta-risposta di ritardo (Delay request-response mechanism)
Il meccanismo prevede due fasi:
- Misurazione del ritardo nella trasmissione del messaggio tra gli orologi principali e quelli secondari. Viene eseguita utilizzando il meccanismo di richiesta-risposta di ritardo.
- Viene eseguita la correzione dello scostamento dell'ora esatta.
Misurazione del ritardo
t1 – Tempo di invio del messaggio Sync dagli orologi principali; t2 – Tempo di ricezione del messaggio Sync dagli orologi secondari; t3 – Tempo di invio della richiesta di ritardo (Delay_Req) dagli orologi secondari; t4 – Tempo di ricezione del Delay_Req dagli 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 si calcola come segue:
Durante la trasmissione del messaggio Sync e Follow_Up viene calcolato il ritardo temporale dal master allo slave – t-ms.
Durante la trasmissione dei messaggi Delay_Req e Delay_Resp viene calcolato il ritardo temporale dallo slave al master – t-sm.
Se tra questi due valori emerge qualche asimmetria, si verifica un errore nella correzione del tempo preciso. L'errore è dovuto al 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 del ritardo del tempo preciso
Una volta noto il ritardo tra gli orologi principali e secondari, gli orologi secondari eseguono la correzione del tempo.
Gli orologi secondari utilizzano il messaggio Sync e il messaggio opzionale Follow_Up per calcolare il ritardo del tempo preciso durante la trasmissione del pacchetto dagli orologi principali a quelli secondari. Il ritardo viene calcolato secondo la seguente formula:
Meccanismo di misurazione del ritardo dei nodi vicini
Questo meccanismo utilizza anche due passaggi per la sincronizzazione:
- I dispositivi misurano il ritardo temporale con tutti i nodi vicini attraverso tutte le porte. Per questo, utilizzano il meccanismo di misurazione del ritardo peer.
- Correzione del ritardo del tempo preciso.
Misurazione del ritardo tra dispositivi che supportano la modalità Peer-to-Peer
Il ritardo tra le porte che supportano il meccanismo peer-to-peer viene misurato utilizzando i seguenti messaggi:
Quando un porto 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 per calcolare il campo di correzione per ogni messaggio Sync o messaggio opzionale Follow_Up che passa attraverso questo dispositivo.
Il ritardo totale sarà pari alla somma del ritardo durante la trasmissione attraverso questo dispositivo, del ritardo medio durante la trasmissione attraverso il canale dati e del ritardo già presente in questo messaggio, incluso nei dispositivi superiori.
I messaggi Pdelay_Req, Pdelay_Resp e l'opzionale Pdelay_Resp_Follow_Up consentono di ottenere il ritardo dal master allo slave e dallo slave al master (circolare).
Qualsiasi asimmetria tra questi due valori introdurrà un errore nella correzione del ritardo di tempo preciso.
Correzione del ritardo di tempo preciso
Gli orologi slave utilizzano il messaggio Sync e il messaggio opzionale Follow_Up per calcolare il ritardo di tempo preciso durante la trasmissione del pacchetto dagli orologi master agli orologi slave. Il ritardo viene calcolato secondo la seguente formula:
I vantaggi della correzione del meccanismo peer-to-peer – il ritardo di ogni messaggio Sync o Follow_Up viene calcolato durante il suo passaggio attraverso la rete. Pertanto, anche un cambiamento nel percorso di trasmissione non influenzerà in alcun modo l'accuratezza della correzione.
Utilizzando questo meccanismo, la sincronizzazione del tempo non richiede il calcolo del ritardo sul percorso percorso dal pacchetto di sincronizzazione, come avviene nel trading di base. Cioè, i messaggi Delay_Req e Delay_Resp non vengono inviati. In questo metodo, il ritardo tra gli orologi principali e secondari viene semplicemente sommato nel campo di correzione di ogni messaggio Sync o Follow_Up.
Un ulteriore vantaggio è che gli orologi principali sono sollevati dall'onere di gestire i messaggi Delay_Req.
Modalità di funzionamento degli orologi trasparenti
Di conseguenza, questi erano semplici esempi analizzati. Ora supponiamo che lungo il percorso di sincronizzazione appaiano degli switch.
Se si utilizzano switch non supportati da PTPv2, il pacchetto di sincronizzazione sarà ritardato dallo switch di circa 10 microsecondi.
Gli switch con supporto PTPv2 nel linguaggio IEEE 1588v2 sono conosciuti come orologi trasparenti. Gli orologi trasparenti non vengono sincronizzati con orologi principali e non partecipano alla gerarchia "Orologi principali – Orologi secondari", ma durante la trasmissione dei messaggi di sincronizzazione memorizzano quanto tempo un messaggio è rimasto in attesa. Questo 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 E2E trasmettono i messaggi Sync e i messaggi correlati Follow_Up su tutte le porte, anche su quelle bloccate da protocolli (ad esempio, RSTP).
Lo switch memorizza il timestamp in cui il pacchetto Sync (Follow_Up) è stato ricevuto sulla porta e quando è stato inviato da essa. Queste due marcature temporali permettono di calcolare il tempo di elaborazione del messaggio da parte dello switch. Secondo lo standard, questo tempo è chiamato residence time.
Il tempo di elaborazione viene aggiunto al campo correctionField del messaggio Sync (orologi monostadio) o Follow_Up (orologi a due stadi).
Gli orologi trasparenti E2E misurano il tempo di elaborazione per i messaggi Sync e Delay_Req che passano attraverso lo switch. È importante comprendere che il ritardo temporale tra orologi master e slave viene calcolato tramite un meccanismo di richiesta-risposta sul ritardo. Se gli orologi master cambiano o cambia il percorso dagli orologi master agli slave, 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 verso il vicino più vicino, utilizzando un meccanismo di misurazione del ritardo del nodo vicino.
Il ritardo viene misurato su ciascun canale in entrambe le direzioni, inclusi i canali bloccati da qualche protocollo (come RSTP). Questo permette di calcolare immediatamente un nuovo ritardo sul percorso di sincronizzazione se gli orologi del grandmaster o la topologia della rete sono cambiati.
Il tempo di elaborazione dei messaggi da parte degli switch e il tempo di ritardo vengono accumulati durante la trasmissione dei messaggi Sync o Follow_Up.
Tipi di supporto PTPv2 da parte degli switch
Gli switch possono supportare PTPv2:
- software;
- hardware.
Nella realizzazione del protocollo PTPv2, lo switch richiede un timestamp al firmware. Il problema è che il firmware lavora in cicli, quindi bisognerà attendere che completi il ciclo in corso per elaborare la richiesta e fornire il timestamp al termine del ciclo successivo. Questo richiederà tempo, e quindi avremo un ritardo, anche se non così significativo come senza supporto software per PTPv2.
Solo il supporto hardware per PTPv2 permette di mantenere la necessaria precisione. In questo caso, il timestamp viene emesso da un ASIC speciale installato sulla porta.
Formato del messaggio
Tutti i messaggi PTP consistono nei 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 – contiene il tipo di messaggio trasmesso, ad esempio Sync, Delay_Req, PDelay_Req, ecc.
messageLength – contiene la dimensione totale del messaggio PTP, inclusi header, body e suffix (escludendo i byte di riempimento).
domainNumber – determina a quale dominio PTP appartiene il messaggio.
Dominio – sono diversi orologi raggruppati in un'unica logica e sincronizzati da un orologio principale, ma non necessariamente sincronizzati con 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 durante il passaggio attraverso orologi trasparenti, nonché il ritardo durante il passaggio attraverso il canale quando si utilizza la modalità Peer-to-Peer.
sourcePortIdentity – questo campo contiene informazioni su quale porta è stato originariamente inviato il messaggio.
sequenceID – contiene un numero identificativo per messaggi individuali.
controlField – campo-artefatto=) È rimasto dalla prima versione dello standard e contiene informazioni sul tipo di messaggio. È essenzialmente lo stesso di messageType, ma con meno opzioni.
logMessageInterval – questo campo è definito dal tipo di messaggio.
Corpo
Come discusso sopra, ci sono diversi tipi di messaggi. Questi tipi sono descritti di seguito:
Messaggio Announce
Il messaggio Announce viene utilizzato per "comunicare" ad altri orologi all'interno di un dominio le proprie caratteristiche. Questo messaggio consente di stabilire una gerarchia tra "Orologi Primari – Orologi Secondari".
Messaggio Sync
Il messaggio di sincronizzazione (Sync) è inviato dagli orologi primari e contiene l'ora degli orologi primari al momento in cui il messaggio Sync è stato creato. Se gli orologi primari sono in configurazione a due stadi, il timestamp nel messaggio Sync verrà impostato a 0, mentre il timestamp attuale verrà inviato nel messaggio collegato Follow_Up. Il messaggio Sync è utilizzato per entrambi i meccanismi di misurazione del ritardo.
Il messaggio viene trasmesso tramite Multicast. Facoltativamente, è possibile utilizzare Unicast.
Messaggio Delay_Req
Il formato del messaggio Delay_Req è identico a quello del messaggio Sync. Gli orologi secondari inviano Delay_Req. Contiene il tempo di invio del Delay_Req da parte degli orologi secondari. Questo messaggio è utilizzato solo per il meccanismo di richiesta-risposta del ritardo.
Il messaggio viene trasmesso tramite Multicast. Facoltativamente, è possibile utilizzare Unicast.
Messaggio Follow_Up
Il messaggio Follow_Up è facoltativamente inviato dagli orologi primari e contiene il tempo di invio del messaggio Sync da parte del master. Il messaggio Follow_Up è inviato solo dagli orologi primari a due stadi.
Il messaggio Follow_Up è utilizzato per entrambi i meccanismi di misurazione del ritardo.
Il messaggio viene trasmesso tramite Multicast. Facoltativamente, è possibile utilizzare Unicast.
Messaggio Delay_Resp
Il messaggio Delay_Resp è inviato dai master clock. Esso contiene il tempo di ricezione del Delay_Req da parte dei master clock. Questo messaggio è utilizzato solo per il meccanismo di richiesta e risposta del ritardo.
Il messaggio viene trasmesso tramite Multicast. Facoltativamente, è possibile utilizzare Unicast.
Messaggio Pdelay_Req
Il messaggio Pdelay_Req è inviato dal dispositivo che richiede il ritardo. Esso contiene il tempo di invio del messaggio dalla porta di questo dispositivo. Pdelay_Req è utilizzato solo per il meccanismo di misurazione del ritardo del nodo adiacente.
Messaggio Pdelay_Resp
Il messaggio Pdelay_Resp è inviato dal dispositivo che ha ricevuto la richiesta per il ritardo. Esso contiene il tempo di ricezione del messaggio Pdelay_Req da parte di questo dispositivo. 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 dal dispositivo che ha ricevuto la richiesta per il ritardo. Esso contiene il tempo di ricezione del messaggio Pdelay_Req da parte di questo dispositivo. Il messaggio Pdelay_Resp_Follow_Up è inviato solo dai master clock a due stadi.
Questo messaggio può essere utilizzato anche per il tempo di esecuzione invece del timestamp. Il tempo di esecuzione è il tempo che intercorre tra la ricezione di un Pdelay-Req e l'invio di un Pdelay_Resp.
I Pdelay_Resp_Follow_Up vengono utilizzati solo per il meccanismo di misurazione della latenza del nodo adiacente.
Messaggi di gestione
I messaggi di gestione PTP sono necessari per la trasmissione di informazioni tra uno o più orologi e il nodo di gestione.
Trasmissione su LV
Un messaggio PTP può essere trasmesso a due livelli:
- Livello di rete – come parte dei dati IP.
- Livello di collegamento – come parte del frame Ethernet.
Trasmissione di messaggi PTP tramite UDP su IP su Ethernet
PTP tramite UDP su Ethernet
Profili
PTP ha un numero sufficiente di parametri "flessibili" da configurare. Ad esempio:
- Opzioni BMCA.
- Meccanismo di misurazione della latenza.
- 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 specifiche restrizioni del protocollo, per consentire la sincronizzazione del tempo per una specifica applicazione.
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 dell'energia o PTPv2 Power Profile è stato creato dal Power Systems Relaying Committee e dal Substation Committee della IEEE Power and Energy Society. Il profilo stesso è chiamato IEEE C37.238-2011.
Il profilo descrive che il PTP può essere trasmesso:
- Solo attraverso reti L2 (cioè Ethernet, HSR, PRP, non IP).
- I messaggi vengono trasmessi solo tramite multicast.
- Come meccanismo di misurazione della latenza viene utilizzato il meccanismo di misurazione del ritardo peer.
Il dominio predefinito è 0, il dominio consigliato è 93.
Alla base della creazione del C37.238-2011 c'era il desiderio di ridurre il numero di caratteristiche opzionali e mantenere solo le funzioni necessarie per un'interazione affidabile tra i dispositivi e per aumentare la stabilità del sistema.
È stata anche definita la frequenza di trasmissione dei messaggi:
In sostanza, c'è solo un parametro da scegliere: il tipo di orologio di riferimento (a un livello o a due livelli).
La precisione non deve superare 1 microsecondo. In altre parole, un singolo percorso di sincronizzazione può contenere al massimo 15 orologi di riferimento trasparenti o tre orologi di riferimento di confine.
Fonte: habr.com
