¿Sincronizar el reloj con NTP en línea y con RTC sin conexión?

¿Existe un mecanismo existente que sincronice un sistema Linux con NTP mientras está en línea, y con un RTC de deriva predecible mientras está fuera de línea?

Operamos "recopiladores" remotos: sistemas Linux integrados que recopilan y marcan los datos del sensor. Necesitamos que sus errores de reloj se mantengan razonablemente pequeños, digamos por debajo de 5 segundos. Usualmente usamos NTP para sincronizar sus relojes, y eso funciona bien, siempre y cuando el sistema esté en línea.

El problema es que algunos coleccionistas tienen enlaces ascendentes muy malos que pueden fallar durante horas, días o incluso semanas. Eso no detiene la recopilación de datos local, pero sin NTP, el reloj del sistema Linux se mueve mal y de manera bastante impredecible.

OTOH, el RTC del hardware también se desplaza fuertemente, pero a un ritmo constante. La tasa de deriva RTC varía de una placa a otra, pero es constante por placa y puede medirse.

Supongo que lo que necesitamos es un mecanismo que haga lo siguiente:

• Mida la tasa de deriva de RTC de una placa antes de su despliegue
• Ajuste el tiempo del sistema en curso / regularmente a través de NTP cuando sea posible
• Ajuste la hora del sistema regularmente desde RTC cuando NTP no esté disponible. Tenga en cuenta la tasa de deriva RTC conocida.
• Opcional: Mida y registre la tasa de deriva RTC en curso mientras está en línea (1)

Con 'mecanismo' me refiero a una pieza de software y / o configuración bien mantenida y documentada que puede manejar los dos estados "en línea" vs. "fuera de línea", asegúrese de que el reloj del sistema esté sincronizado con la fuente de tiempo correcta (ntp vs. rtc), detecta el cambio de estado y corrige la deriva del RTC. No importa mucho si se implementa como un complemento / configuración ntpd especial, como un demonio separado, como un trabajo cron o de lo contrario.

Eché un vistazo a Chrony , pero de acuerdo con su documentación , trata de predecir la deriva del reloj del sistema , que en nuestro caso deriva mucho más imprevisiblemente que el RTC. Chrony parece usar el RTC solo para mantener el tiempo entre reinicios.

(1) Nota: ntpd activa el 'modo de 11 minutos' del núcleo (actualiza rtc desde el reloj del sistema cada 11 minutos). Parece que no hay formas con los núcleos actuales y ntpd para evitar el modo de 11 minutos. Por lo tanto, cualquier información de deriva rtc se pierde mientras se ejecuta ntpd (thx @billthor).

Actualizaciones / ediciones:

• Estamos considerando agregar un radio reloj externo para la señal MSF o DCF77 (estamos en Europa) a través de USB o serie. Pero preferimos mantener el hardware delgado.
• Nuestros colectores están ubicados en interiores, a menudo en el sótano. Por lo tanto, agregar relojes GPS no ayudará.
• Usamos Debian 7. Eso significa hwclock de util-linux-2.20.1, ntpdate-4.2.6p5, ntpd de ntp-4.2.6.p5, chrony-1.24 (potencialmente 1.30).
• Tenga en cuenta que nuestro problema no es que no sabemos cómo utilizar ntpdate(8), hwclock(8), date(1), etc Por favor, consulte la sección añadida en cursiva sobre lo que quiero decir con 'mecanismo'.
• Se agregó una nota al pie sobre el 'modo de 11 minutos'
• Aquí hay una discusión muy interesante sobre la sincronización fuera de línea y la deriva de RTC

Su situación es inusual, y me sorprendería si a alguien se le ocurre una ntpdconfiguración estándar para hacer lo que desea. Dicho esto, me gusta que me sorprendan, y sucede con bastante frecuencia en estas partes.

Pero hasta que a alguien se le ocurra una idea mejor, ¿ha considerado una crontabentrada como esta?

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

Es decir, cada cinco minutos intente sincronizar el reloj a través de ntpdate, y si (y solo si) falla, ajuste el reloj del hardware para la deriva de acuerdo con el /etc/adjtimearchivo (cuyo formato se detalla man hwclocky cuya primera línea ha rellenado adecuadamente utilizando su conocimiento) de esa tasa particular de RTC), luego configure el reloj del sistema desde el RTC.

Tenga en cuenta que si busca una solución como esta y está implementando un número significativo de estos sistemas, se considera cortés trabajar con el grupo y contribuir con los servidores de nuevo en proporción a su uso. Puede encontrar más información en http://www.pool.ntp.org/en/vendors.html .

NTP ya tiene mecanismos para saber si está en línea o sin conexión, y cambiará a fuentes de menor prioridad según sea necesario. Es muy fácil verificar el valor de alcance para activar una fuente alternativa, pero me quedaría con NTP. Como se discute a continuación, es probable que el monitoreo y la corrección de la deriva de RTC sean difíciles.

En días anteriores a Internet, utilizaba un programa que llamaba por teléfono a una fuente de datos y sincronizaba el reloj. Todavía puede haber servicios disponibles que brinden una fuente de tiempo a través de un módem. Esto requeriría acceso a una línea telefónica.

Existen problemas conocidos con el reloj local que no se aplican al RTC. Algunos de los problemas están documentados en la lista de problemas conocidos del sistema operativo NTP . Estos pueden explicar su deriva del reloj. Resolverlos puede resolver su problema. En ausencia de ticks perdidos, he encontrado que la fuente de tiempo local (sistema) puede ser muy estable.

Es posible que pueda utilizar el controlador de reloj Dumb (33) con un programa que escriba la hora RTC adecuada en el dispositivo / dev / dumbclockX.

Hay varios otros controladores basados ​​en relojes de radio. Algunos de estos utilizan servicios de onda corta como WWV y CHU, que pueden funcionar en entornos donde las señales GPS no están disponibles. Para Europa, esta lista incluiría BBC, TDF, RBU y RMW.

Pavel Krejci también ha escrito un controlador RTC, pero no parece estar incorporado en los controladores oficiales. Esto puede funcionar con la sincronización de tipo PPS.

Debería ser posible medir la deriva de RTC antes del despliegue. Sin embargo, deberá asegurarse de que el RTC no se actualice automáticamente. Cuando el reloj del sistema se actualiza con la función adjtimex, el RTC se puede actualizar cada 11 minutos.

NTP actualizará el reloj cuando esté conectado. Normalmente, NTP se negará a hacer grandes ajustes en el reloj del sistema. Hay opciones para ajustar qué tan lejos se puede ajustar el reloj.

He sugerido opciones para usar el RTC anterior. Un radio reloj puede ser más adecuado que un reloj GPS.

Es probable que medir la deriva en ausencia de una fuente de tiempo confiable para compararlo sea un esfuerzo inútil. Si la hora local es inestable, no puede usarla para monitorear el RTC y viceversa. La medición de la deriva mientras NTP está conectado no funcionará si el núcleo está actualizando el RTC cada 11 minutos. Los RTC que he usado tienen una resolución de un segundo, por lo que tendrían que desplazarse significativamente para ser medibles de manera confiable.