Sincronizzare l'orologio con NTP quando si è online e con RTC quando si è offline?

Esiste un meccanismo esistente che sincronizza un sistema linux con NTP mentre è online e con un RTC alla deriva prevedibilmente mentre è offline?

Operiamo "collettori" remoti: sistemi Linux incorporati che raccolgono e timestamp i dati dei sensori. Abbiamo bisogno che i loro errori di clock rimangano ragionevolmente piccoli, diciamo sotto 5 secondi. Di solito utilizziamo NTP per sincronizzare i loro orologi, e questo funziona benissimo, purché il sistema sia online.

Il problema è che alcuni collezionisti hanno uplink pessimi che possono andare giù per ore, giorni o addirittura settimane. Ciò non impedisce la raccolta di dati locali, ma senza NTP, l'orologio del sistema Linux si sposta in modo errato e abbastanza imprevedibile.

OTOH, anche l'RTC dell'hardware va alla deriva pesantemente, ma a un ritmo costante. La velocità di deriva RTC varia da scheda a scheda, ma è costante per scheda e può essere misurata.

Immagino che ciò di cui abbiamo bisogno sia un meccanismo che faccia quanto segue:

• Misurare il tasso di deriva RTC di una scheda prima del suo spiegamento
• Regola l'ora di sistema in corso / regolarmente via NTP quando possibile
• Regola regolarmente l'ora di sistema da RTC quando l'NTP non è disponibile. Tenere conto del tasso di deriva RTC noto.
• Opzionale: misurare e registrare la velocità di deriva RTC in corso mentre si è online (1)

Con "meccanismo" intendo un software ben documentato e / o una configurazione ben documentata in grado di gestire i due stati "online" anziché "offline", assicurarsi che l'orologio di sistema sia sincronizzato con l'origine temporale corretta (ntp vs. rtc), rileva il cambio di stato e corregge la deriva RTC. Non importa se viene implementato come speciale configurazione / plug-in ntpd, come demone separato, cron job o altro.

Ho dato un'occhiata a Chrony , ma secondo la sua documentazione cerca di prevedere la deriva dell'orologio di sistema , che nel nostro caso va alla deriva molto più imprevedibilmente dell'RTC. Chrony sembra utilizzare RTC solo per mantenere il tempo durante i riavvii.

(1) Nota ntpd attiva la '11 -minute mode 'del kernel (aggiorna rtc dall'orologio di sistema ogni 11 minuti). Sembra che non ci siano modi con i kernel attuali e ntpd per impedire la modalità 11 minuti. Pertanto, qualsiasi informazione di deriva rtc viene persa mentre ntpd è in esecuzione (thx @billthor).

Aggiornamenti / Modifiche:

• Stiamo valutando di aggiungere un orologio radio esterno per il segnale MSF o DCF77 (basato in Europa) tramite USB o seriale. Ma preferiamo mantenere l'hardware snello.
• I nostri collezionisti si trovano all'interno, spesso nel seminterrato. Quindi l'aggiunta di orologi GPS non aiuta.
• Usiamo Debian 7. Ciò significa che hwclock da util-linux-2.20.1, ntpdate-4.2.6p5, ntpd da ntp-4.2.6.p5, chrony-1.24 (potenzialmente 1.30).
• Nota che il nostro problema non è che non sappiamo come utilizzare ntpdate(8), hwclock(8), date(1), ecc Si prega di consultare la sezione aggiunta in corsivo su ciò che voglio dire con 'meccanismo'.
• Aggiunta nota a piè di pagina sulla modalità '11 -minute '
• Ecco una discussione molto interessante sulla sincronizzazione offline e sulla deriva RTC

La tua situazione è insolita e sarei sorpreso se qualcuno avesse una ntpdconfigurazione standard per fare ciò che desideri. Detto questo, mi piace essere sorpreso, e succede abbastanza spesso da queste parti.

Ma fino a quando qualcuno non ha avuto un'idea migliore, hai considerato una crontabvoce come questa?

*/5 * * * *   ntpdate 0.pool.ntp.org || ( hwclock --adjust; hwclock --hctosys )

Ad esempio, ogni cinque minuti prova a sincronizzare l'orologio tramite ntpdate, e se (e solo se) fallisce, regola l'orologio hardware per la deriva in base al /etc/adjtimefile (il cui formato è dettagliato in man hwclocke la cui prima riga hai popolato in modo appropriato usando le tue conoscenze di quel particolare RTC), quindi impostare l'orologio di sistema dall'RTC.

Si noti che se si cerca una soluzione come questa e si sta distribuendo un numero significativo di questi sistemi, è considerato educato lavorare con il pool e contribuire con i server in proporzione al proprio utilizzo. Puoi trovare maggiori informazioni su http://www.pool.ntp.org/en/vendors.html .

NTP ha già dei meccanismi per sapere se è online o offline e passerà a fonti con priorità più bassa come richiesto. È molto facile controllare il valore di copertura per attivare una fonte alternativa, ma rimarrei con NTP. Come discusso di seguito, è probabile che il monitoraggio e la correzione della deriva RTC siano difficili.

Nei giorni precedenti a Internet utilizzavo un programma che telefonava a un'origine dati e sincronizzava l'orologio. Potrebbero essere ancora disponibili servizi che forniscono una fonte di tempo tramite un modem. Ciò richiederebbe l'accesso a una linea telefonica.

Esistono problemi noti con l'orologio locale, che non si applicano all'RTC. Alcuni dei problemi sono documentati nell'elenco dei problemi noti del sistema operativo NTP . Questi potrebbero spiegare la deriva dell'orologio. Risolverli potrebbe risolvere il tuo problema. In assenza di segni di spunta persi, ho scoperto che l'origine locale (di sistema) potrebbe essere molto stabile.

Potrebbe essere possibile utilizzare il driver Dumb clock (33) con un programma che scrive l'ora RTC appropriata sul dispositivo / dev / dumbclockX.

Esistono numerosi altri driver basati sugli orologi radio. Alcuni di questi utilizzano servizi a onde corte come WWV e CHU, che potrebbero funzionare in ambienti in cui i segnali GPS non sono disponibili. Per l'Europa questo elenco includerebbe BBC, TDF, RBU e RMW.

Anche Pavel Krejci ha scritto un driver RTC, ma non sembra essere incorporato nei driver ufficiali. Questo potrebbe funzionare con la sincronizzazione del tipo PPS.

Dovrebbe essere possibile misurare la deriva RTC prima dell'implementazione. Tuttavia, sarà necessario assicurarsi che l'RTC non venga aggiornato automaticamente. Quando l'orologio di sistema viene aggiornato con la funzione adjtimex, l'RTC può essere aggiornato ogni 11 minuti.

NTP aggiornerà l'orologio quando è collegato. Normalmente NTP rifiuta di apportare grandi modifiche all'orologio di sistema. Ci sono opzioni per regolare fino a che punto è possibile regolare l'orologio.

Ho suggerito opzioni per l'utilizzo dell'RTC sopra. Un orologio radio può essere più adatto di un orologio GPS.

Misurare la deriva in assenza di una fonte di tempo affidabile per confrontarla è probabilmente uno sforzo inutile. Se l'ora locale è instabile, non è possibile utilizzarla per monitorare l'RTC e viceversa. La misurazione della deriva mentre NTP è collegato non funzionerà se il kernel aggiorna l'RTC ogni 11 minuti. Gli RTC che ho usato hanno una risoluzione di un secondo, quindi dovrebbero spostarsi in modo significativo per essere misurabili in modo affidabile.