Sincronizzazione dell'orologio in una rete con ritardi asimmetrici

Supponiamo che un computer abbia un orologio preciso che non è inizializzato. Cioè, l'ora sull'orologio del computer è l'ora reale più un offset costante. Il computer dispone di una connessione di rete e vogliamo utilizzare tale connessione per determinare l'offset costante .$B$

Il metodo semplice è che il computer invia una query a un server orario, rilevando l'ora locale . Il server temporale riceve la query alla volta e invia una risposta contenente al client, che la riceve alla volta B + C_2 . Quindi B + C_1 \ le T \ le B + C_2 , ovvero T - C_2 \ le B \ le T - C_1 . T T B + C 2 B + C 1 ≤ T ≤ B + C 2 T - C 2 ≤ B ≤ T - C $B + C_1$$T$$T$$B + C_2$$B + C_1 \le T \le B + C_2$$T - C_2 \le B \le T - C_1$

Se il tempo di trasmissione della rete e il tempo di elaborazione del server sono simmetrici, allora $B = T - \dfrac{C_1 + C_2}{2}$ . Per quanto ne so, NTP , il protocollo di sincronizzazione dell'ora utilizzato in natura, opera su questo presupposto.

Come può essere migliorata la precisione se i ritardi non sono simmetrici? C'è un modo per misurare questa asimmetria in una tipica infrastruttura Internet?

Incapacità di misurare l'asimmetria

No, non puoi misurare l'asimmetria. Considera questi due diagrammi di comunicazione, il primo con un offset di clock negativo e ritardi uguali e il secondo senza offset di clock e ritardi completamente asimmetrici (ma lo stesso tempo di andata e ritorno).

La cosa importante da notare è che, dal punto di vista sia del PC che del server, le due interazioni sono esattamente identiche. Ricevono messaggi allo stesso tempo. Mandano messaggi allo stesso tempo.

È possibile creare più casi "afferrando" la linea temporale del PC e "facendola scorrere", mantenendo i punti di invio / ricezione del messaggio fissi rispetto alle rispettive linee temporali. Le asimmetrie che causi sono esattamente negate dall'offset dell'orologio. In effetti, puoi anche fare in modo che i messaggi vadano INDIETRO IN TEMPO in un modo (purché il tempo di andata e ritorno sia sempre lo stesso) e il server / client STILL non può dirlo!

Pertanto è impossibile misurare le asimmetrie di latenza. Nel peggiore dei casi, dove non si hanno informazioni diverse da quelle latenze a senso unico che si sommano al tempo di andata e ritorno, l'accuratezza della sincronizzazione dell'orologio è limitata al tempo di andata e ritorno.

Le infrastrutture intermedie possono aiutare?

Il fatto che l'infrastruttura intermedia possa aiutare o meno dipenderà fortemente dal modello teorico della situazione.

Se l'asimmetria è costante e l'infrastruttura intermedia sono i router sul percorso di comunicazione tra l'utente e il server, allora no. Anche se ogni router sincronizzasse il proprio clock con il router adiacente, gli errori si sarebbero combinati allo stesso modo come se si fosse sincronizzato con il server tramite la comunicazione attraverso i router.

Nel mondo reale puoi fare affidamento sul fatto che i ritardi sono in qualche modo simmetrici per motivi architettonici, ripetute sincronizzazioni per ridurre l'asimmetria dovuta a ritardi di accodamento (ecc.) E percorsi di comunicazione multipli per ridurre altri tipi di asimmetria.

Se metti le ipotesi del tuo modello nel mezzo (perché è interessante esplorare lo spazio del modello, ovviamente) mi aspetto che il risultato dovrebbe essere anche nel mezzo.

Si consideri una rete di server di tempo note per essere sincrona, , e una macchina client .$\theta = \{A, B, C\}$$P$

Sia il tempo di sola andata per il volo dalla macchina alla macchina , con la possibilità che . X Y T X Y ≠ T Y $T_{XY}$$X$$Y$$T_{XY}\neq T_{YX}$

Letla misura della asimmetria tra macchina e .X $\Delta_{XY} = |T_{XY} - T_{YX}|$$X$$Y$

Ora, considera che l'asimmetria tra due macchine sincrone può essere misurata facendo in modo che le macchine sincrone acconsentano a scambiarsi un messaggio a senso unico contemporaneamente. La differenza nei tempi di arrivo è tra quelle macchine, ovvero:$\Delta$

$\Delta_{AB} = |T_{AB} - T_{BA}|$

$\Delta_{BC} = |T_{BC} - T_{CB}|$

$\Delta_{CA} = |T_{CA} - T_{AC}|$

può essere misurato.

Ora considera il tempo di volo dei circuiti:

C A $P \rightarrow A \rightarrow B \rightarrow P$ , indicato con ,$C_{AB}$

C B $P \rightarrow B \rightarrow A \rightarrow P$ , indicato con .$C_{BA}$

$C_{AB} = T_{PA} + T_{AB} + T_{BP}$

$C_{BA} = T_{PB} + T_{BA} + T_{AP}$

Considera la macchina client per avviare entrambi questi circuiti contemporaneamente e misura la differenza nei tempi di arrivo, :$P$$x$

$x = C_{AB} - C_{BA} = \Delta_{PA} + \Delta_{AB} + \Delta_{BP}$

Sia che sono noti con misure precedentemente menzionate, quindi spostando le incognite sul lato sinistro:Δ A $x$$\Delta_{AB}$

$x - \Delta_{AB} = \Delta_{PA} + \Delta_{BP}$

Allo stesso modo, per e si può dimostrare che:{ C B C , C C B$\{C_{AC}, C_{CA}\}$$\{C_{BC}, C_{CB}\}$

$y - \Delta_{BC} = \Delta_{PB} + \Delta_{CP}$

$z - \Delta_{CA} = \Delta_{PC} + \Delta_{AP}$

Controllo con attenzione, si nota che . I lati di sinistra contengono valori noti dalle misurazioni, i lati di destra contengono 3 incognite in 3 equazioni.$\Delta_{XY} \equiv \Delta_{YX}$

Risolvendo contemporaneamente,

$\Delta_{AP} = \frac{r + s - t}{2}$

$\Delta_{BP} = \frac{r - s + t}{2}$

$\Delta_{CP} = \frac{t - r + s}{2}$

dove,

$r = x - \Delta_{AB}$

$s = y - \Delta_{BC}$

$t = z - \Delta_{CA}$

Se controlli solo gli endpoint. Non puoi. Vedi la risposta di Craig.

Anche se aggiungi più macchine e un set di computer più complesso, come nella risposta di Bingo, puoi ridurre a solo macchine che fanno in modo che quelle sincronizzate abbiano accesso istantaneo alle altre (ritardo = 0).$T_{XY}$

Nota che se fai , otterrai Δ A P = Δ $T_{AB} = T_{BC} = T_{CA} = 0$ .$\Delta_{AP} = \Delta_{BP} = \Delta_{CP} = 0$

Quindi cosa c'è che non va? $x = C_{AB}-C_{BA} = \Delta_{PA}+\Delta_{AB}+\Delta_{BP}$

, non Δ P A = $\Delta_{PA} = |T_{PA} - T_{AP}|$$\Delta_{PA} = T_{PA} - T_{AP}$

E se usi il secondo, non puoi usare l'assunzione (e se non lo usi, le tue equazioni finali si annullano a vicenda).$\Delta_{XY} \equiv \Delta_{YX}$

Che cosa si può fare? Invia un orologio davvero buono attraverso la posta. ;)

Oppure, se si ha il controllo su tutti i nodi tra loro, è possibile controllare il tempo di elaborazione di ciascun pacchetto e calcolare il ritardo tra ciascuna coppia consecutiva, che dovrebbe essere simmetrico, se utilizzano lo stesso supporto fisico in entrambi i modi.

Potrebbe essere necessario tenere conto della relatività generale e ricordare che la simultaneità non esiste.

NTP attualmente utilizza 4 misurazioni del tempo per calcolare lo "scostamento". sono i "punti temporali" nel round trip del pacchetto da client a server di nuovo al client, ma possono essere considerati offset del tempo. si presume che l'offset di tempo possa essere spento tra client e server ma che entrambi possano contare accuratamente gli offset di tempo locali trascorsi.$t_0, t_1, t_2, t_3$

il client dopo aver ricevuto il pacchetto di ritorno ha tutti e 4 i valori e calcola l'offset effettivo. una volta calcolato l'offset relativo tra client e server, l'offset del "tempo assoluto" può essere sincronizzato, ovvero il client può stimare con precisione l'offset esatto del server misurato con il suo offset dell'ora locale, ovvero il "delta".

$t_0$ = tempo [offset] inviato al client
= tempo [offset] recd sul server t 2 = tempo [offset] inviato al server$t_1$
$t_2$
= tempo [offset] recd sul client$t_3$

la formula effettiva è $\theta = {(t_1 - t_0) + (t_2 - t_3) \over 2}$

nota che questa formula può gestire il caso in cui il tempo dal client al server non è uguale a quello dal server al client t 3$t_1 - t_0$ (più breve o più lungo).$t_3 - t_2$

sulle reti, il ritardo è dovuto a due fattori principali, principalmente latenza e larghezza di banda.

• la latenza è il breve ritardo nei router nell'invio di nuovi [piccoli] pacchetti ed è approssimativamente una costante diversa su ciascun router. può essere misurato con l' utilità traceroute .
• la larghezza di banda è la velocità con cui è possibile inviare grandi quantità di dati, ad esempio "tempo di upload vs download" e può anche essere misurata da siti Web remoti di "misurazione della larghezza di banda".

in molte moderne connessioni Internet domestiche / aziendali la velocità di upload è molto più bassa delle velocità di download e questo probabilmente influenzerebbe la vs t 3 - t $t_1 - t_0$$t_3 - t_2$ differenza mentre la latenza potrebbe essere piccola o in qualche modo simile tra client-server e server-to-client.

un algoritmo di base per migliorare la precisione del calcolo dell'offset utilizzato in NTP (e può correggere per un certo grado di latenza di rete casuale) è ripetere il processo più volte e utilizzare l '"apice del diagramma a cuneo". questo può essere visto sull'algoritmo "filtro filtro" sulla diapositiva 10 di questo PPT su NTP di David Mills. vedi anche algoritmo filtro orologio di Mills. (nota che può ancora essere impiegato tra un singolo server e client sebbene il codice generale sia scritto per consentire più server.) fa parte degli "algoritmi di mitigazione" descritti nell'architettura e negli algoritmi NTP .

Se solo potessimo inviare i pacchetti indietro nel tempo

ipotesi:

$(B+C_2) - T_b = T_f - (B+C_1)$

$T_f - (B + C_2) = (B + C_1) - T_b$

Ecco un'idea che mi sembra assolutamente convincente e potrebbe quindi essere assolutamente sbagliata in modo stupido.

Considera il seguente scenario. Abbiamo due nodi$N_1$ e $N_2$ con gli orologi $C_1$ e $C_2$, rispettivamente. Per semplicità, supponiamo che gli orologi funzionino alla stessa velocità; denotiamo la loro differenza con$\delta = C_1 - C_2$che è costante per i nostri scopi. Supponiamo inoltre che i ritardi di trasmissione$d_{1 \to 2}$ e $d_{2 \to 1}$ sono costanti¹.

Avere $N_1$ invia un messaggio con data e ora $T_1^m$ a $N_2$ e lascia $T_2^r$ l'ora corrente $C_2$dopo averlo ricevuto (fare lo stesso per l'altra direzione). Inoltre, misurare il tempo di andata e ritorno (su entrambi i nodi)$D$inviando un messaggio avanti e indietro. Ora imposta questo sistema di equazioni:

$\qquad\begin{align*} T_2^r - T_1^m &= d_{1 \to 2} + \delta \\ T_1^r - T_2^m &= d_{2 \to 1} - \delta \\ D &= d_{1 \to 2} + d_{2 \to 1} \end{align*}$

Poiché questo sistema è composto da tre equazioni, ha tre incognite e sappiamo che esiste una soluzione, può essere risolto. Naturalmente i nodi devono scambiare le loro misurazioni in modo che entrambi possano calcolare lo stesso valore per$\delta$ (se necessario).

1] Penso che le ipotesi siano naturali e necessarie. Possono essere giustificati con la speranza che le rispettive quantità non cambino troppo per la durata del nostro tentativo di sincronizzazione.