Server NTP singolo su rete isolata

Ho due macchine linux (A e B) su una rete isolata. Devono essere sincronizzati nel tempo. La macchina A è alimentata in modo intermittente e deve servire l'ora, poiché è collegata a una fonte di tempo autorevole (GPS). La macchina B è alimentata solo se la macchina A è alimentata, ma è un dispositivo Linux incorporato e il suo stato di alimentazione cambierà frequentemente. Nessuna macchina ha accesso ad altri sistemi. È una rete chiusa.

Capisco che questo è un ordine piuttosto elevato per NTP, poiché NTP di solito prevede di avere contatti con diversi server. Sto riscontrando problemi per far funzionare correttamente la macchina B. La macchina A si sincronizza perfettamente con il GPS e la macchina B può raggiungere la macchina A e persino eseguire query sul tempo, ma la macchina A non è attendibile (forse da sola?). Dopo un'ora solida di macchina A in su, questo improvvisamente è cambiato e la macchina B ha funzionato. Tuttavia, quando la macchina A è caduta (e quindi la macchina B), la macchina B non è di nuovo in grado di trovare una buona sincronizzazione temporale.

Ecco alcune informazioni ntpdate. Si noti che anche quando lo strato della macchina A è 1, l'operazione non riesce con lo stesso output alla fine.

10.10.10.1: Server eliminato: strati troppo alti
server 10.10.10.1, porta 123
strato 16, precisione -19, salto 11, fiducia 000
refid [10.10.10.1], ritardo 0.02614, dispersione 0.00000
trasmesso 4, nel filtro 4
ora di riferimento: 00000000.00000000 Gio 7 feb 2036 6: 28: 16.000
timestamp di origine: d3a9bdc4.27ebb350 gio 12 lug 2012 21: 19: 00.155
timestamp trasmissione: bc17c803.b42dfffe sab, 1 gen 2000 0: 25: 39.703
ritardo filtro: 0,02625 0,02614 0,02618 0,02625 
         0,00000 0,00000 0,00000 0,00000 
filtro offset: 39544160 39544160 39544160 39544160
         0,000000 0,000000 0,000000 0,000000
ritardo 0,02614, dispersione 0,00000
offset 395441600.451568

 1 gen 00:25:39 ntpdate [677]: nessun server adatto per la sincronizzazione trovato

La mia ipotesi è che la macchina A non si fidi di se stessa per servire il tempo. Dopo 51 minuti (potrebbe essere accaduto prima, non lo so) di uptime e con l'orologio sincronizzato con il GPS, la macchina A ha iniziato a servire correttamente l'ora e la macchina B ha rilevato. Ho bisogno che questo accada prima. Come, in pochi secondi se possibile.

Con le seguenti configurazioni (e molte attese), alla fine ha successo.

Macchina A ntp.conf:

il server 127.127.28.0 preferisce il vero minpoll 4 maxpoll 4
fondente 127.127.28.0 strato 1 tempo1 0.420 refid GPS 

Machine B ntp.conf:

il server 10.10.10.1 preferisce il vero minpoll 4 maxpoll 4

ntpq -c peer sulla macchina B senza una buona correzione del tempo:

     t di riferimento remoto quando il polling raggiunge il ritardo jitter offset
================================================== ============================
 10.10.10.1. PASSO. 16 u 9 16 0 0.000 0.000 0.000

peer ntp1 -c sulla macchina B con una buona correzione temporale:

     t di riferimento remoto quando il polling raggiunge il ritardo jitter offset
================================================== ============================
* 10.10.10.1 SHM (0) 2 u 7 16 17 0.669 2.597 1.808

Quindi, ora la domanda diventa: come faccio a fidarmi rapidamente di Machine A?

Alcuni output di debug dalla macchina A prima e dopo la macchina B decidono che la macchina A è abbastanza buona da usare.

prima..

~ # ntpq -c rv
associd = 0 status = c418 leap_alarm, sync_uhf_radio, 1 evento, no_sys_peer,
version = "ntpd 4.2.6p4@1.2324 ven 24 feb 15:01:45 UTC 2012 (1)",
processore = "armv7l", system = "Linux / 2.6.35.14", salto = 11, strato = 2,
precisione = -19, ritardo root = 0.000, rootdisp = 44.537, refid = SHM (0),
reftime = d3ab0053.43b44780 ven, 13 lug 2012 20: 15: 15.264,
orologio = d3ab0062.e7e03154 ven, 13 lug 2012 20: 15: 30.905, peer = 34819, tc = 4,
mintc = 3, offset = 0.000, frequenza = 0.000, sys_jitter = 3.853,
clk_jitter = 36.492, clk_wander = 0.000

dopo...

~ # ntpq -c rv
associd = 0 status = 0415 leap_none, sync_uhf_radio, 1 evento, clock_sync,
version = "ntpd 4.2.6p4@1.2324 ven 24 feb 15:01:45 UTC 2012 (1)",
processore = "armv7l", system = "Linux / 2.6.35.14", salto = 00, strato = 2,
precisione = -19, ritardo root = 0.000, rootdisp = 41.278, refid = SHM (0),
reftime = d3ab0063.43b37856 Ven, 13 lug 2012 20: 15: 31.264,
clock = d3ab006d.9ee53ec2 Ven, 13 lug 2012 20: 15: 41.620, peer = 34819, tc = 4,
mintc = 3, offset = 0.000, frequenza = 43.896, sys_jitter = 0.762,
clk_jitter = 36.953, clk_wander = 0.000

NTP dovrebbe funzionare bene. Guarda alcune delle opzioni per una sincronizzazione rapida all'avvio. Guarda le opzioni burste iburstper il sistema B. Guarda le trueopzioni per l'orologio GPS.

Prendi in considerazione l'utilizzo dell'orologio hardware come origine temporale di backup su entrambi i sistemi. Impostare un sistema di strato superiore B. Qualcosa di simile al seguente dovrebbe funzionare:

server  127.127.1.0
fudge   127.127.1.0 stratum 8

Guarda l'output di ntpq -c peersper vedere quando ottieni una sorgente di clock affidabile. Normalmente ntpdesidera un numero di risposte da una fonte di tempo attendibile prima che si fidi di essa. Questo è indicato dal primo carattere su ogni riga.

Mentre a NTP piacciono più fonti, qualsiasi numero dispari di fonti di tempo entro un livello di strato dovrebbe funzionare bene. Dato che hai solo due server e un orologio GPS, la priorità (strato) delle fonti dovrebbe aumentare da GPS, orologio sul server A, orologio sul server B. L'aumento dello strato tra ciascuno di tre o quattro livelli garantirà il rispetto delle priorità.

EDIT: se si dispone del server NTP busybox sul server A, potrebbe essere utile installare il pacchetto completo del server ntp. Capire cosa sta succedendo con il server A dovrebbe fare molto per risolvere il tuo problema. Sarà necessaria almeno una fonte di tempo attendibile prima che il server B possa fidarsene. Se ntpq -c peersnon funziona, allora puoi provare ntpdc peers. Entrambi questi comandi consentono di interrogare altri host. Un peerstatsregistro potrebbe anche essere utile.

Sul server di usare B NtpClient come documentato il busybox ntp howto per accedere ciò che sta accadendo su di esso

Gli orologi dovrebbero essere ragionevolmente vicini all'ora corretta se i server non sono inattivi da molto tempo. Se devi sincronizzare i due sistemi, dovrebbe essere sufficiente. Il GPS porterà il tempo alla sincronizzazione con il mondo reale alla fine.

'ntpd -q' si sincronizza rapidamente, ma esce (comportamento ntpdate). Deve essere seguito da un ntpdcomando senza l'opzione quit per avere una sincronizzazione continua.

EDIT2: controllo il mio server e ho scoperto che uno dei server era spento per un secondo. Durante la correzione ho giocato con le impostazioni. iburstottiene un server di fiducia molto rapidamente. trueha assicurato che il driver dell'orologio fosse attendibile se non c'erano più altre fonti attendibili. L'orologio ha impiegato poco più di un minuto prima che fosse attendibile localmente e potesse essere attendibile da remoto.

Durante il test dovresti essere in grado di riavviare il ntpdprocesso una volta sincronizzato e testare la velocità con cui funzionano le impostazioni. Nel caso precedente, potrebbe essere necessario riavviare il server B per verificare la velocità di sincronizzazione. Durante il monitoraggio delle ntpdmodifiche utilizzo una riga come:

while ntpq -c peers localhost; do sleep 10; done

Il nome host e il tempo di sospensione vengono regolati in base alle esigenze. In alcuni casi ho incatenato due o più ntpqrighe di comando nel loop. Nel fare ciò, utilizzo un comando echo e / o date per fornire un'indicazione di dove cambiano le serie di dati.