Introduzione
Il concetto di costruzione di una “sottostazione digitale” nel settore dell’energia elettrica richiede una sincronizzazione con una precisione di 1 μs. Anche le transazioni finanziarie richiedono una precisione al microsecondo. In queste applicazioni, la precisione temporale NTP non è più sufficiente.
Il protocollo di sincronizzazione PTPv2, descritto dallo standard IEEE 1588v2, consente una precisione di sincronizzazione di diverse decine di nanosecondi. PTPv2 consente di inviare pacchetti di sincronizzazione su reti L2 e L3.
Le aree principali in cui viene utilizzato PTPv2 sono:
- energia;
- apparecchiature di controllo e misurazione;
- complesso militare-industriale;
- telecomunicazioni;
- settore finanziario.
Questo post spiega come funziona il protocollo di sincronizzazione PTPv2.
Abbiamo più esperienza nel settore industriale e spesso vediamo questo protocollo nelle applicazioni energetiche. Di conseguenza, eseguiremo la revisione con cautela .
Perché è necessario?
Al momento, STO 34.01-21-004-2019 di PJSC Rosseti e STO 56947007-29.240.10.302-2020 di PJSC FGC UES contengono requisiti per l'organizzazione di un bus di processo con sincronizzazione dell'ora tramite PTPv2.
Ciò è dovuto al fatto che al bus di processo sono collegati terminali di protezione relè e dispositivi di misurazione, che trasmettono valori istantanei di corrente e tensione attraverso il bus di processo, utilizzando i cosiddetti flussi SV (flussi multicast).
I terminali di protezione relè utilizzano questi valori per implementare la protezione del vano. Se la precisione delle misurazioni del tempo è ridotta, alcune protezioni potrebbero funzionare in modo errato.
Ad esempio, le difese della selettività assoluta possono cadere vittime di una sincronizzazione temporale “debole”. Spesso la logica di tali difese si basa sul confronto di due quantità. Se i valori divergono di un valore sufficientemente elevato, viene attivata la protezione. Se questi valori vengono misurati con una precisione temporale di 1 ms, è possibile ottenere una grande differenza laddove i valorisono effettivamente normali se misurati con una precisione di 1 μs.
Versioni PTP
Il protocollo PTP è stato originariamente descritto nel 2002 nello standard IEEE 1588-2002 ed era chiamato “Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems”. Nel 2008 è stato rilasciato lo standard IEEE 1588-2008 aggiornato, che descrive PTP versione 2. Questa versione del protocollo ha migliorato la precisione e la stabilità, ma non ha mantenuto la compatibilità con le versioni precedenti del protocollo. Inoltre, nel 2019, è stata rilasciata una 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 immagine con le versioni:
PTPv1
(IEEE 1588-2002)
PTPv2
(IEEE 1588-2008)
PTPv2.1
(IEEE 1588-2019)
PTPv1 (IEEE 1588-2002)
-
incoerente
incoerente
PTPv2 (IEEE 1588-2008)
incoerente
-
compatibile
PTPv2.1 (IEEE 1588-2019)
incoerente
compatibile
-
Ma, come sempre, ci sono delle sfumature.
L'incompatibilità tra PTPv1 e PTPv2 significa che un dispositivo abilitato per PTPv1 non sarà in grado di sincronizzarsi con un orologio preciso in esecuzione su PTPv2. Usano diversi formati di messaggio per la sincronizzazione.
È comunque possibile combinare dispositivi con PTPv1 e dispositivi con PTPv2 sulla stessa rete. Per raggiungere questo obiettivo, alcuni produttori consentono di selezionare la versione del protocollo sulle porte edge clock. Cioè, un orologio limite può sincronizzarsi utilizzando PTPv2 e sincronizzare comunque altri orologi ad esso collegati utilizzando sia PTPv1 che PTPv2.
Dispositivi PTP. Cosa sono e in cosa differiscono?
Lo standard IEEE 1588v2 descrive diversi tipi di dispositivi. Tutti sono mostrati nella tabella.
I dispositivi comunicano tra loro su una LAN utilizzando PTP.
I dispositivi PTP sono chiamati orologi. Tutti gli orologi prendono l'ora esatta dall'orologio del Gran Maestro.
Esistono 5 tipi di orologi:
Orologio da Gran Maestro
La principale fonte di tempo preciso. Spesso dotato di un'interfaccia per il collegamento del GPS.
Orologio ordinario
Un dispositivo a porta singola che può essere master (orologio master) o slave (orologio slave)
Orologio principale (principale)
Sono la fonte dell'ora esatta con cui vengono sincronizzati gli altri orologi
Orologio schiavo
Dispositivo finale sincronizzato dall'orologio principale
Orologio di confine
Un dispositivo con più porte che può essere un master o uno slave.
Cioè, questi orologi possono sincronizzarsi dall'orologio master superiore e sincronizzare gli orologi slave inferiori.
Orologio trasparente end-to-end
Un dispositivo con più porte che non è né un orologio master né uno slave. Trasmette i dati PTP tra due orologi.
Durante la trasmissione dei dati, l'orologio trasparente corregge tutti i messaggi PTP.
La correzione avviene aggiungendo il tempo di ritardo su questo dispositivo al campo di correzione nell'intestazione del messaggio trasmesso.
Orologio trasparente peer-to-peer
Un dispositivo con più porte che non è né un orologio master né uno slave.
Trasmette i dati PTP tra due orologi.
Durante la trasmissione dei dati, l'orologio trasparente corregge tutti i messaggi PTP Sync e Follow_Up (maggiori informazioni di seguito).
La correzione si ottiene sommando al campo di correzione del pacchetto trasmesso il ritardo sul dispositivo trasmittente e il ritardo sul canale di trasmissione dati.
Nodo di gestione
Un dispositivo che configura e diagnostica altri orologi
Gli orologi master e slave vengono sincronizzati utilizzando i timestamp nei messaggi PTP. Esistono due tipi di messaggi nel protocollo PTP:
- I messaggi di evento sono messaggi sincronizzati che implicano la generazione di un timestamp nel momento in cui il messaggio viene inviato e nel momento in cui viene ricevuto.
- Messaggi generali: questi messaggi non richiedono timestamp, ma possono contenere timestamp per i messaggi correlati
Messaggi di eventi
Messaggi generali
Sincronizza
Ritardo_Richiesta
Pdelay_Req
Pdelay_Resp
Annunciare
Seguito
Ritardo_Resp
Pdelay_Resp_Follow_Up
Management
Segnalazione
Tutti i tipi di messaggi verranno discussi più dettagliatamente di seguito.
Problemi di sincronizzazione di base
Quando un pacchetto di sincronizzazione viene trasmesso su una rete locale, viene ritardato allo switch e nel collegamento dati. Qualsiasi commutazione produrrà un ritardo di circa 10 microsecondi, il che è inaccettabile per PTPv2. Dopotutto, dobbiamo raggiungere una precisione di 1 μs sul dispositivo finale. (Questo se parliamo di energia. Altre applicazioni potrebbero richiedere una maggiore precisione.)
IEEE 1588v2 descrive diversi algoritmi operativi che consentono di registrare il ritardo temporale e correggerlo.
Algoritmo di lavoro
Durante il normale funzionamento, il protocollo opera in due fasi.
- Fase 1 - definizione della gerarchia “Master Clock – Slave Clock”.
- Fase 2 - sincronizzazione dell'orologio tramite meccanismo End-to-End o Peer-to-Peer.
Fase 1 – Stabilire la Gerarchia Master-Slave
Ciascuna porta di un orologio normale o edge ha un certo numero di stati (orologio slave e orologio master). Lo standard descrive l'algoritmo di transizione tra questi stati. Nella programmazione, tale algoritmo è chiamato macchina a stati finiti o macchina a stati (maggiori dettagli in Wiki).
Questa macchina a stati utilizza il Best Master Clock Algorithm (BMCA) per impostare il master quando si collegano due orologi.
Questo algoritmo consente all'orologio di assumersi le responsabilità dell'orologio Grandmaster quando l'orologio Grandmaster a monte perde il segnale GPS, va offline, ecc.
Le transizioni di stato secondo il BMCA sono riassunte nel seguente diagramma:
Le informazioni sull'orologio all'altra estremità del "filo" vengono inviate in un messaggio speciale (Messaggio di annuncio). Una volta ricevute queste informazioni, viene eseguito l'algoritmo della macchina a stati e viene effettuato un confronto per vedere quale orologio è migliore. La porta dell'orologio migliore diventa l'orologio principale.
Una semplice gerarchia è mostrata nel diagramma seguente. I percorsi 1, 2, 3, 4, 5 possono contenere un orologio trasparente, ma non partecipano alla creazione della gerarchia Master Clock - Slave Clock.
Fase 2 - Sincronizzare i clock regolari e quelli edge
Subito dopo aver stabilito la gerarchia “Master Clock – Slave Clock”, inizia la fase di sincronizzazione degli orologi regolari e di confine.
Per sincronizzarsi, l'orologio master invia un messaggio contenente un timestamp agli orologi slave.
L'orologio principale può essere:
- singola fase;
- due stadi.
Gli orologi a stadio singolo inviano un messaggio di sincronizzazione per sincronizzarsi.
Un orologio a due fasi utilizza due messaggi per la sincronizzazione: Sync e Follow_Up.
Per la fase di sincronizzazione possono essere utilizzati due meccanismi:
- Ritardare il meccanismo di richiesta-risposta.
- Meccanismo di misurazione del ritardo del peer.
Per prima cosa, diamo un'occhiata a questi meccanismi nel caso più semplice, quando non vengono utilizzati orologi trasparenti.
Ritardare il meccanismo di richiesta-risposta
Il meccanismo prevede due passaggi:
- Misurazione del ritardo nella trasmissione di un messaggio tra l'orologio master e l'orologio slave. Eseguito utilizzando un meccanismo di richiesta-risposta ritardata.
- Viene eseguita la correzione dello spostamento temporale esatto.
Misurazione della latenza
t1 – Orario di invio del messaggio Sync da parte del master clock; t2 – Orario di ricezione del messaggio Sync da parte dell'orologio slave; t3 – Orario di invio della richiesta di ritardo (Delay_Req) da parte dell'orologio slave; t4 – Delay_Req orario di ricezione da parte dell'orologio master.
Quando l'orologio slave conosce i tempi t1, t2, t3 e t4, può calcolare il ritardo medio durante la trasmissione del messaggio di sincronizzazione (tmpd). Viene calcolato come segue:
Quando si trasmette un messaggio Sync e Follow_Up, viene calcolato il ritardo temporale dal master allo slave - t-ms.
Quando si trasmettono messaggi Delay_Req e Delay_Resp, viene calcolato il ritardo dallo slave al master - t-sm.
Se si verifica un'asimmetria tra questi due valori, viene visualizzato un errore nella correzione della deviazione dell'ora esatta. L'errore è causato dal fatto che il ritardo calcolato è la media dei ritardi t-ms e t-sm. Se i ritardi non sono uguali tra loro, non regoleremo l'ora in modo accurato.
Correzione dello spostamento temporale
Una volta noto il ritardo tra l'orologio master e l'orologio slave, l'orologio slave esegue la correzione dell'ora.
Gli orologi slave utilizzano il messaggio Sync e un messaggio Follow_Up opzionale per calcolare l'esatto spostamento temporale durante la trasmissione di un pacchetto dal master agli orologi slave. Lo spostamento viene calcolato utilizzando la seguente formula:
Meccanismo di misurazione del ritardo del peer
Anche questo meccanismo utilizza due passaggi per la sincronizzazione:
- I dispositivi misurano il ritardo verso tutti i vicini attraverso tutte le porte. Per fare ciò utilizzano un meccanismo di ritardo peer.
- Correzione dello spostamento temporale esatto.
Misurazione della latenza tra dispositivi che supportano la modalità Peer-to-Peer
La latenza tra le porte che supportano il meccanismo peer-to-peer viene misurata utilizzando i seguenti messaggi:
Quando la porta 1 conosce i tempi t1, t2, t3 e t4, può calcolare il ritardo medio (tmld). Si calcola utilizzando la seguente formula:
La porta utilizza quindi questo valore durante il calcolo del campo di regolazione per ciascun messaggio di sincronizzazione o messaggio di follow-up opzionale che passa attraverso il 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à contenuto in questo messaggio, abilitato sui dispositivi a monte.
I messaggi Pdelay_Req, Pdelay_Resp e opzionale Pdelay_Resp_Follow_Up consentono di ottenere il ritardo da master a slave e da slave a master (circolare).
Qualsiasi asimmetria tra questi due valori introdurrà un errore di correzione dell'offset temporale.
Regolazione dello spostamento temporale esatto
Gli orologi slave utilizzano un messaggio Sync e un messaggio Follow_Up opzionale per calcolare l'esatto spostamento temporale durante la trasmissione di un pacchetto dal master agli orologi slave. Lo spostamento viene calcolato utilizzando la seguente formula:
Vantaggi adattamento del meccanismo peer-to-peer: il ritardo temporale di ciascun messaggio Sync o Follow_Up viene calcolato man mano che viene trasmesso nella rete. Di conseguenza, la modifica del percorso di trasmissione non influirà in alcun modo sulla precisione della regolazione.
Utilizzando questo meccanismo, la sincronizzazione temporale non richiede il calcolo del ritardo temporale lungo il percorso percorso dal pacchetto di sincronizzazione, come avviene nello scambio base. Quelli. I messaggi Delay_Req e Delay_Resp non vengono inviati. In questo metodo, il ritardo tra gli orologi master e slave viene semplicemente sommato nel campo di regolazione di ciascun messaggio Sync o Follow_Up.
Un altro vantaggio è che il master clock è sollevato dalla necessità di elaborare i messaggi Delay_Req.
Modalità operative degli orologi trasparenti
Di conseguenza, questi erano semplici esempi. Supponiamo ora che sul percorso di sincronizzazione vengano visualizzati degli interruttori.
Se si utilizzano switch senza supporto PTPv2, il pacchetto di sincronizzazione verrà ritardato sullo switch di circa 10 μs.
Gli switch che supportano PTPv2 sono chiamati orologi trasparenti nella terminologia IEEE 1588v2. Gli orologi trasparenti non sono sincronizzati dall'orologio master e non partecipano alla gerarchia “Master Clock - Slave Clock”, ma quando trasmettono messaggi di sincronizzazione ricordano quanto tempo hanno ritardato il messaggio. Ciò consente di regolare il ritardo.
Gli orologi trasparenti possono funzionare in due modalità:
- Da un capo all'altro.
- Peer to peer.
End-to-end (E2E)
L'orologio trasparente E2E trasmette i messaggi di sincronizzazione e i messaggi di follow-up di accompagnamento su tutte le porte. Anche quelli bloccati da alcuni protocolli (ad esempio RSTP).
Lo switch ricorda il timestamp quando un pacchetto Sync (Follow_Up) è stato ricevuto sulla porta e quando è stato inviato dalla porta. Sulla base di questi due timestamp, viene calcolato il tempo necessario allo switch per elaborare il messaggio. Nello standard, questo tempo è chiamato tempo di residenza.
Il tempo di elaborazione viene aggiunto al campo CorrectionField del messaggio Sync (orologio a un passo) o Follow_Up (orologio a due passi).
L'orologio trasparente E2E misura il tempo di elaborazione per i messaggi Sync e Delay_Req che passano attraverso lo switch. Ma è importante capire che il ritardo temporale tra l'orologio master e l'orologio slave viene calcolato utilizzando il meccanismo di ritardo richiesta-risposta. Se cambia l'orologio master o cambia il percorso dall'orologio master all'orologio slave, il ritardo viene misurato nuovamente. Ciò aumenta il tempo di transizione in caso di modifiche alla rete.
L'orologio trasparente P2P, oltre a misurare il tempo necessario affinché uno switch elabori un messaggio, misura il ritardo sul collegamento dati al vicino più vicino utilizzando un meccanismo di latenza del vicino.
La latenza viene misurata su ogni collegamento in entrambe le direzioni, compresi i collegamenti bloccati da alcuni protocolli (come RSTP). Ciò consente di calcolare immediatamente il nuovo ritardo nel percorso di sincronizzazione se cambia l'orologio Grandmaster o la topologia della rete.
Il tempo di elaborazione dei messaggi tramite switch e la latenza vengono accumulati durante l'invio di messaggi Sync o Follow_Up.
Tipi di supporto PTPv2 tramite switch
Gli switch possono supportare PTPv2:
- a livello di programmazione;
- hardware.
Quando si implementa il protocollo PTPv2 nel software, lo switch richiede un timestamp dal firmware. Il problema è che il firmware funziona ciclicamente e dovrai attendere finché non termina il ciclo corrente, accetta la richiesta di elaborazione ed emette un timestamp dopo il ciclo successivo. Anche questa operazione richiederà tempo e si verificherà un ritardo, sebbene non così significativo come senza il supporto software per PTPv2.
Solo il supporto hardware per PTPv2 consente di mantenere la precisione richiesta. In questo caso la marca temporale viene emessa da un apposito ASIC installato sulla porta.
Formato del messaggio
Tutti i messaggi PTP sono costituiti dai seguenti campi:
- Intestazione: 34 byte.
- Corpo: la dimensione dipende dal tipo di messaggio.
- Il suffisso è facoltativo.
testata
Il campo Intestazione è lo stesso per tutti i messaggi PTP. La sua dimensione è di 34 byte.
Formato del campo di intestazione:
messageType – contiene il tipo di messaggio trasmesso, ad esempio Sync, Delay_Req, PDelay_Req, ecc.
messageLength – contiene l'intera dimensione del messaggio PTP, inclusi intestazione, corpo e suffisso (ma esclusi i byte di riempimento).
dominioNumero – determina a quale dominio PTP appartiene il messaggio.
Nome di dominio - si tratta di più orologi diversi raccolti in un gruppo logico e sincronizzati da un orologio principale, ma non necessariamente sincronizzati con orologi appartenenti a un dominio diverso.
bandiere – Questo campo contiene vari flag per identificare lo stato del messaggio.
campocorrezione – contiene il tempo di ritardo in nanosecondi. Il tempo di ritardo include il ritardo durante la trasmissione attraverso l'orologio trasparente, nonché il ritardo durante la trasmissione attraverso il canale quando si utilizza la modalità Peer-to-Peer.
sourcePortIdentity – questo campo contiene informazioni sulla porta da cui è stato originariamente inviato il messaggio.
sequenzaID – contiene un numero identificativo per i singoli messaggi.
controlField – campo artefatto =) Rimane dalla prima versione dello standard e contiene informazioni sul tipo di questo messaggio. Essenzialmente uguale a messageType, ma con meno opzioni.
logMessageInterval – questo campo è determinato dal tipo di messaggio.
Corpo
Come discusso in precedenza, esistono diversi tipi di messaggi. Questi tipi sono descritti di seguito:
Messaggio di annuncio
Il messaggio di annuncio viene utilizzato per "informare" altri orologi all'interno dello stesso dominio sui suoi parametri. Questo messaggio consente di impostare una gerarchia Master Clock - Slave Clock.
Sincronizza messaggio
Il messaggio di sincronizzazione viene inviato dall'orologio principale e contiene l'ora dell'orologio principale nel momento in cui è stato generato il messaggio di sincronizzazione. Se l'orologio principale è a due stadi, il timestamp nel messaggio Sync verrà impostato su 0 e il timestamp corrente verrà inviato nel messaggio Follow_Up associato. Il messaggio Sync viene utilizzato per entrambi i meccanismi di misurazione della latenza.
Il messaggio viene trasmesso utilizzando Multicast. Facoltativamente è possibile utilizzare Unicast.
Messaggio Delay_Req
Il formato del messaggio Delay_Req è identico al messaggio Sync. L'orologio slave invia Delay_Req. Contiene l'ora in cui Delay_Req è stato inviato dall'orologio slave. Questo messaggio viene utilizzato solo per il meccanismo di ritardo richiesta-risposta.
Il messaggio viene trasmesso utilizzando Multicast. Facoltativamente è possibile utilizzare Unicast.
Messaggio di follow_up
Il messaggio Follow_Up viene inviato opzionalmente dall'orologio master e contiene l'ora di invio Sincronizza i messaggi maestro. Solo gli orologi master a due stadi inviano il messaggio Follow_Up.
Il messaggio Follow_Up viene utilizzato per entrambi i meccanismi di misurazione della latenza.
Il messaggio viene trasmesso utilizzando Multicast. Facoltativamente è possibile utilizzare Unicast.
Messaggio Delay_Resp
Il messaggio Delay_Resp viene inviato dal master clock. Contiene l'ora in cui Delay_Req è stato ricevuto dal master clock. Questo messaggio viene utilizzato solo per il meccanismo di ritardo richiesta-risposta.
Il messaggio viene trasmesso utilizzando Multicast. Facoltativamente è possibile utilizzare Unicast.
Messaggio Pdelay_Req
Il messaggio Pdelay_Req viene inviato da un dispositivo che richiede un ritardo. Contiene l'ora in cui il messaggio è stato inviato dalla porta di questo dispositivo. Pdelay_Req viene utilizzato solo per il meccanismo di misurazione del ritardo del vicino.
Messaggio Pdelay_Resp
Il messaggio Pdelay_Resp viene inviato da un dispositivo che ha ricevuto una richiesta di ritardo. Contiene l'ora in cui il messaggio Pdelay_Req è stato ricevuto da questo dispositivo. Il messaggio Pdelay_Resp viene utilizzato solo per il meccanismo di misurazione del ritardo del vicino.
Messaggio Pdelay_Resp_Follow_Up
Il messaggio Pdelay_Resp_Follow_Up viene facoltativamente inviato dal dispositivo che ha ricevuto la richiesta di ritardo. Contiene l'ora in cui il messaggio Pdelay_Req è stato ricevuto da questo dispositivo. Il messaggio Pdelay_Resp_Follow_Up viene inviato solo da orologi master a due stadi.
Questo messaggio può essere utilizzato anche per l'ora di esecuzione anziché per un timestamp. Il tempo di esecuzione è il tempo dal momento in cui viene ricevuto Pdelay-Req fino all'invio di Pdelay_Resp.
Pdelay_Resp_Follow_Up vengono utilizzati solo per il meccanismo di misurazione del ritardo del vicino.
Messaggi di gestione
I messaggi di controllo PTP sono necessari per trasferire informazioni tra uno o più orologi e il nodo di controllo.
Trasferimento a LV
Un messaggio PTP può essere trasmesso a due livelli:
- Rete – come parte dei dati IP.
- Canale – come parte di un frame Ethernet.
Trasmissione di messaggi PTP su UDP su IP su Ethernet
PTP su UDP su Ethernet
Profili
PTP ha molti parametri flessibili che devono essere configurati. Per esempio:
- Opzioni BMCA.
- Meccanismo di misurazione della latenza.
- Intervalli e valori iniziali di tutti i parametri configurabili, ecc.
E nonostante abbiamo già detto in precedenza che i dispositivi PTPv2 sono compatibili tra loro, questo non è vero. I dispositivi devono avere le stesse impostazioni per poter comunicare.
Ecco perché esistono i cosiddetti profili PTPv2. I profili sono gruppi di impostazioni configurate e restrizioni di protocollo definite in modo che la sincronizzazione dell'ora possa essere implementata per un'applicazione specifica.
Lo stesso standard IEEE 1588v2 descrive un solo profilo: "Profilo predefinito". Tutti gli altri profili sono creati e descritti da varie organizzazioni e associazioni.
Ad esempio, il Power Profile, o PTPv2 Power Profile, è stato creato dal Power Systems Relaying Committee e dal Substation Committee della IEEE Power and Energy Society. Il profilo stesso si chiama IEEE C37.238-2011.
Il profilo descrive che il PTP può essere trasmesso:
- Solo tramite reti L2 (ovvero Ethernet, HSR, PRP, non IP).
- I messaggi vengono trasmessi solo tramite trasmissione Multicast.
- Il meccanismo di misurazione del ritardo peer viene utilizzato come meccanismo di misurazione del ritardo.
Il dominio predefinito è 0, il dominio consigliato è 93.
La filosofia di progettazione di C37.238-2011 era quella di ridurre il numero di funzionalità opzionali e mantenere solo le funzioni necessarie per un'interazione affidabile tra i dispositivi e una maggiore stabilità del sistema.
Inoltre, viene determinata la frequenza di trasmissione del messaggio:
Infatti è possibile selezionare un solo parametro: il tipo di orologio principale (monostadio o due stadi).
La precisione non deve essere superiore a 1 μs. In altre parole, un percorso di sincronizzazione può contenere al massimo 15 orologi trasparenti o tre orologi limite.
Fonte: habr.com