Interesse acquisito da parte mia: sono un agente Meinberg :-)
Sì NTP può raggiungere una precisione end-to-end fino a ca. 50 noi (che sono microsecondi) di jitter, se sincronizzi un "client" linux su bare metal con Chrony o ntpd, su un server NTP basato su Linux disciplinato da un GPS, un orologio atomico locale o qualche altra fonte.
Sulla macchina che ha un GPS locale (con un'interconnessione PPS), probabilmente vedrai 0-2 microsecondi di offset, tra l'istanza ntpd in esecuzione nel sistema operativo e l'input del driver di refclock PPS.
I restanti 50 "end to end over LAN" sono il risultato di diverse fasi di buffering, latenza IRQ variabile, altro traffico che interferisce sulla LAN e sui bus dei computer coinvolti e quant'altro. 50 us significa una LAN con pochissimo traffico. Anche solo uno switch può aggiungere alcuni microsecondi di jitter - e switch di fascia alta con funzionalità complesse aggiungono più latenza e jitter. In altre parole, può essere abbastanza difficile ottenere quei 50 microsecondi nelle condizioni del mondo reale su una LAN pratica.
Allo stesso modo, quelli cca <2us dell'offset PPS derivano solo dall'incertezza di latenza IRQ e dal jitter generale di latenza del bus su hardware PC ben educato.
Si noti che NTP e le sue implementazioni ntpd e Chrony misurano certamente il tempo di andata e ritorno della transazione NTP e sottraggono (aggiungono, in realtà) metà di quel viaggio di andata e ritorno, come misura per filtrare la latenza sistematica del trasporto (solo andata). Eseguono anche il rifiuto anomalo, il consenso sul quorum, l'elezione di syspeer e qualsiasi demone NTP filtra le risposte che riceve alle sue domande a monte. Quindi, come altri hanno già detto, i millisecondi che vedi in Ping e Traceroute non compensano direttamente l'orologio locale. Ciò che conta è la variabilità del viaggio di andata e ritorno delle transazioni, ovvero dell'altro traffico sul percorso verso il server NTP upstream. Ntpq -p è tuo amico.
Un ricevitore GPS di base per il cronometraggio, con un TCXO, può avere forse 100-200 ns di jitter residuo + vagare sulla sua uscita PPS. Abbastanza buono per NTP, purché il GPS rimanga bloccato. (Le prestazioni di Holdover non sono molto buone con i TCXO.) Un GPS di temporizzazione di qualità con un OCXO può essere ben entro 100 ns, forse più come 10-30 ns di errore residuo (offset dall'UTC globale).
Nota che i satelliti reali che volano in alto e ti irradiano attraverso un'atmosfera possono essere un gioco leggermente più difficile per il ricevitore, rispetto al benchmarking in un laboratorio con un generatore GPS.
PTP è un martello. È necessario il supporto HW nel grandmaster, negli slave e in tutti gli switch, ma se si ottiene tutto ciò, sono possibili offset residui fino a una bassa doppia cifra di nanosecondi. L'ho visto personalmente in ptp4l in esecuzione con una scheda di rete i210 con supporto HW (timestamp con risoluzione di un nanosecondo).
Il chip i210 è una meraviglia. Dispone di 4 pin di uso generale che possono essere utilizzati per immettere o emettere un segnale PPS. La scheda NIC addon di riferimento Intel con i210 (e le sue versioni OEM di diversi grandi fornitori) è dotata di un'intestazione pin che consente di accedere ad almeno 2 di quei pin GPIO (SDP chiamati da Intel). Oltre all'implementazione di una porta grandmaster PTP, l'input PPS può essere sfruttato per un timestamp preciso nella cattura dei pacchetti. È necessario disporre di una fonte precisa di PPS e di un software personalizzato per eseguire un servo loop, perfezionando il PHC dell'i210 su ext.PPS. Sul mio banco di prova, ciò ha comportato ns a una cifra (per 1 s iterazione) di offset residuo. Questa è la precisione che ottieni nei tuoi timestamp di acquisizione, se si esegue un recente tcpdump o WireShark su un moderno kernel Linux (tutto il software necessita di supporto per la risoluzione di livello di nanosecondi). Meglio ancora: sono andato fino in fondo e ho costruito un semplice sintetizzatore PLL per produrre 25 MHz per gli orologi NIC, bloccato su un preciso riferimento a 10 MHz a monte. Dopodiché, l'offset residuo nel loop servo del mio impianto di acquisizione di pacchetti è sceso a uno zero pulito (una prova che il mio riferimento a 10 MHz è sincronizzato in fase con il PPS dallo stesso box GPS).
Si noti che i grandmaster PTP possono essere specificati per fornire timestamp con una granularità effettiva per 8 ns (in un tipo di dati con risoluzione 1 ns). Questo ha senso: Gigabit Ethernet tende a usare un clock a 125 MHz, usato come clock byte all'interno del MAC, questo clock è probabilmente usato anche in GMII, ed è anche il clock simbolo in 1000Base-TX metallico (quattro coppie in parallelo, 2 bit per simbolo per coppia). Quindi, a meno che tu non stia usando 1000Base-FX (fibra ottica) con SERDES e un'implementazione estremista dell'unità di timestamp HW nel PHY che funziona fino a singoli bit SERDES, quegli 8 ns sono tutto ciò che puoi realisticamente sperare su Ethernet Gigabit. Alcuni fogli dati su chip (con supporto PTP) sostengono addirittura che il percorso dei dati MII non sia privo di buffering e che un po 'di jitter possa provenire da lì.
I pacchetti PTP in realtà contengono timestamp memorizzati in un tipo di dati che consente una risoluzione profonda dei sub-nanosecondi. Ma il "campo frazionario sub-nanosecondo" è oggi in genere inutilizzato. AFAIR solo il progetto White Rabbit (correlato al CERN il centro di ricerca svizzero) ha finora implementato la precisione dei sub-ns.
PTP è disponibile anche in software puro, senza accelerazione HW. In tal caso, per un GM basato su SW e un client basato su SW, si prevede di ottenere un jitter residuo simile a quello con NTP, ovvero circa 50 utenti su una LAN dedicata ma PTP inconsapevole. Ricordo di aver ottenuto una precisione al di sotto del microsecondo da un grandmaster HW su un'interconnessione diretta (nessuna commutazione intermedia) e un client solo SW (su una scheda NIC PC inconsapevole). Rispetto a NTP, il servo del PTP converge molto più velocemente.
Mentre facevo alcuni "compiti a casa", recentemente mi è venuto in mente che il trasporto di PPS o segnali di temporizzazione "discreti" simili su percorsi in fibra ottica ad ampia area può essere suscettibile al "vagare" del tempo di propagazione dipendente dalla temperatura. E anche se non ho modo di testarlo sperimentalmente, alcune fonti nelle interwebs citano cifre comprese tra 40 e 76 picosecondi per km e Kelvin. Si noti che mentre questo tipo di "distorsione termica" è impossibile da mitigare "in banda" nella trasmissione PPS simplex, la PTP lo avrebbe post-compensato intrinsecamente, in base alle sue misure di ritardo del percorso standard (che dipendono dalla trasmissione full duplex).
Questo per quanto riguarda una panoramica di come appaiono le "precisazioni", a diverse tecnologie / interfacce di temporizzazione. Quale livello di precisione è abbastanza buono per te, dipende dalla tua applicazione, dalle tue reali esigenze.