Cos'è la dispersione NTP e come la controllo?

Distribuiamo i server Ubuntu 14.04 su reti isolate, con ntpd 4.2.6p5, configurati per utilizzare più server NTP forniti dai clienti (nessun accesso a pool.ntp.org). I nostri stupidi terminali client eseguono una vecchia versione di BusyBox (1.00-rc2) e ntpclient 2010 di Larry Doolittle.

Questa configurazione ha funzionato alla grande per anni, ma recentemente abbiamo raggiunto un blocco con un nuovo cliente. Ci hanno fornito 5 indirizzi di server NTP interni che sembrano funzionare da soli, per quanto ntpdate-debianriguarda il server Linux. Sul lato BusyBox, tuttavia, si ntpclientlamenta di "Dispersione troppo elevata". ntpclientDall'output di debug, ottiene "1217163.1" dal server NTP ma il valore massimo supportato è assoluto (65536).

$ /usr/sbin/ntpclient -s -i 15 -h 10.17.162.250 -d
Configuration:
  -c probe_count 1
  -d (debug)     1
  -g goodness    0
  -h hostname    10.17.162.250
  -i interval    15
  -l live        0
  -p local_port  0
  -q min_delay   800.000000
  -s set_clock   1
  -x cross_check 1
Listening...
Sending ...
recvfrom
packet of length 48 received
Source: INET Port 123 host 10.17.162.250
LI=0  VN=3  Mode=4  Stratum=4  Poll=4  Precision=-20
Delay=60745.2  Dispersion=1346801.8  Refid=10.31.10.21
Reference 3668859928.942079
(sent)    3668859928.708371
Originate 3668859928.708371
Receive   3668859928.963271
Transmit  3668859928.963369
Our recv  3668859928.708371
Total elapsed:      0.00
Server stall:      93.09
Slop:             -93.09
Skew:          255443.94
Frequency:             0
 day   second     elapsed    stall     skew  dispersion  freq
42463 56728.708  rejected packet: abs(DISP)>65536

Questi sono tutti dispositivi sulla stessa LAN, così francamente sono sbalordito. Sorpreso anche.

Ecco l' ntpq -pnoutput dal server Ubuntu 14.04:

user@host:~$ ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 127.127.1.0     .LOCL.          10 l 1025   64    0    0.000    0.000   0.000
 10.17.162.249   10.17.6.10       5 u   23 1024   37    0.865  1381.07 697.260
 10.31.10.22     .LOCL.           1 u 1044 1024   17   29.586  -838.06 397.342
 10.17.6.10      10.31.10.21      4 u 1065 1024   17    0.366  105.245 402.999
*10.31.10.21     132.246.11.238   3 u    5 1024   37   29.418  794.292 616.796
 10.17.6.11      10.31.10.21      4 u 1038 1024   17    0.408  120.030 381.058

Le mie domande sono:

1. Cos'è la dispersione e cosa può alterarne il valore?
2. Quali comandi posso eseguire per ottenere maggiori dettagli dai server NTP?
3. L'errore potrebbe risiedere sul lato server di Ubuntu, con un errore ntp.conf? Non c'è niente di speciale lì davvero.
4. Il passaggio a Chrony cambierebbe qualcosa in questo caso?

Vedo un po 'di confusione nelle risposte qui. Per cominciare, ntpclientalmeno in -smodalità, non agisce come un client NTP completo, sta solo inviando e ricevendo un pacchetto , quindi non ci sono "ultimi 8 pacchetti ricevuti". In realtà non sta affatto stimando la propria dispersione.

Invece, il valore che sta stampando è il valore chiamato "dispersione root" (rootdisp) nel pacchetto restituito dal server, che è una stima della quantità totale di errore / varianza tra quel server e l'ora corretta. Il modo in cui viene calcolato è piuttosto semplice: ogni server NTP riceve l'ora da un orologio esterno (ad esempio un ricevitore radio o GPS) o da un altro server NTP. Se un server riceve l'ora da un clock esterno, la sua dispersione root è l'errore massimo stimato di quell'orologio. Se arriva il suo tempo da un altro server NTP, la sua dispersione root è la dispersione root di quel server più la dispersione aggiunta dal collegamento di rete tra di loro.

Un punto di confusione qui è che mentre ntpq e chrony mostrano la dispersione e la dispersione delle radici in pochi secondi, che è ciò a cui le persone sono abituate a guardare, ntpclient lo mostra in microsecondi . Indipendentemente da ciò, un valore di 1217163 è ancora piuttosto elevato. Un buon server NTP conosce il tempo entro pochi millisecondi; uno cattivo in poche decine o centinaia di millisecondi. Il tuo ti sta dicendo che si può fidare del suo tempo entro +/- 1,2 secondi.

Puoi effettivamente ottenere ntpclient per la sincronizzazione con questo server comunque passando l' opzione -x 0o -t(a seconda della versione di ntpclient), che disabilita i controlli di integrità NTP. Se hai bisogno solo di un tempo approssimativamente preciso (entro pochi secondi), potrebbe essere abbastanza buono. Tuttavia, ntpclient è abbastanza ragionevole nel rifiutarsi di sincronizzarsi con un server così male. Il tuo ntpqoutput sulla macchina Ubuntu sta mostrando un jitter di centinaia di millisecondi per tutti i suoi server, anche se hanno un ritardo basso, il che indica una rete molto inaffidabile, una cospirazione di tutti i server per fornire tempo irregolare, o una base problema di indicazione dell'ora sul server stesso.

Mi preoccupa anche il fatto che il server 10.31.10.22 stia pubblicando un refid di LOCL(orologio locale indisciplinato) ma abbia uno strato di 1. Di solito l'orologio locale viene spostato su uno strato di 10 in modo che venga utilizzato solo come sorgente di sincronizzazione dell'ultima risorsa per evitare che un branco si allontani. O 10.31.10.22 è configurato in modo errato e fornisce un brutto momento al resto della rete, oppure è disciplinato a tempo debito da un programma al di fuori del controllo di NTP, nel qual caso la configurazione errata è semplicemente che sta pubblicizzando il LOCLrefid; dovrebbe essere ignorato, ad esempio, GPSo qualunque cosa stia fornendo il suo tempo.

Solo una risposta parziale per "Cos'è la dispersione?":

Un tipico round trip NTP:

client |        | server
    t1 |------->| t2
    t3 |<-------| t4

Ciò produce due valori, offset (la differenza di tempo tra client e server) e il ritardo (essenziale il tempo di percorrenza della rete) con le seguenti formule:

offset= ((t4 - t3) + (t1 - t2)) / 2
delay = (t4 - t1) - (t3 - t2)

Il client seleziona l'offset corrente tra gli ultimi 8 pacchetti ricevuti, scegliendo quello con il minor ritardo.

Gli stessi 8 pacchetti vengono utilizzati per calcolare la dispersione facendo una media ponderata della differenza di questi 8 offset rispetto a quella selezionata nell'ultimo passaggio, in cui il ritardo viene utilizzato come fattore di ponderazione, dando maggiore peso a ritardi minori. È una misura per la "diffusione" dei valori e viene utilizzata per calcolare la qualità di un time server, soprattutto se si dispone di più tra cui scegliere.

La tua dispersione e inclinazione sono enormi, c'è un grande offset dall'orologio locale a quel peer. Dovresti confrontare gli offset con il locale datee impostare l'orologio manualmente.

Ottieni ntpd in esecuzione e mostra ntpq -pda un host utilizzando tutti i peer. Seleziona quelli migliori.

Secondo questa documentazione di Cisco , "la dispersione , riportata in pochi secondi, è la massima differenza di tempo mai osservata tra l'orologio locale e l'orologio del server". Con i server ntp che non sono completamente rotti, non dovrebbe mai verificarsi un'alta dispersione. L'unico scenario possibile è quando il tuo client accede a ntp e finora ha solo il suo orologio locale disponibile. E anche in questo caso, una dispersione alta come si dice corrisponde a orologi che sono spenti per più di due settimane .

Dovrebbe essere sufficiente garantire che l'orologio locale non sia troppo lontano all'inizio (anche un paio d'ore sarebbe comunque accettabile), sia regolando l'orologio (e la data anche!) Nel BIOS o emettendo ntpdateuna volta prima di iniziare ntpdsul client.