Existe-t-il un mécanisme existant qui synchronise un système Linux avec NTP lorsqu'il est en ligne et avec un RTC à la dérive prévisible lorsqu'il est hors ligne?
Nous exploitons des «collecteurs» distants: des systèmes Linux embarqués qui collectent et horodatent les données des capteurs. Nous avons besoin de leurs erreurs d'horloge pour rester raisonnablement petites, disons en dessous de 5 secondes. Habituellement, nous utilisons NTP pour synchroniser leurs horloges, et cela fonctionne très bien - tant que le système est en ligne.
Le problème est que certains collecteurs ont de très mauvaises liaisons montantes qui peuvent descendre pendant des heures, des jours ou même des semaines. Cela n'arrête pas la collecte de données locales, mais sans NTP, l'horloge système Linux dérive mal et de manière assez imprévisible.
OTOH, le RTC du matériel dérive fortement aussi, mais à un rythme constant. Le taux de dérive RTC varie d'une carte à l'autre, mais est constant par carte et peut être mesuré.
Je suppose que nous avons besoin d'un mécanisme qui fait ce qui suit:
- Mesurer le taux de dérive RTC d'une carte avant son déploiement
- Ajustez l'heure système en cours / régulièrement via NTP lorsque cela est possible
- Ajustez régulièrement l'heure du système à partir de RTC lorsque NTP n'est pas disponible. Tenez compte du taux de dérive RTC connu.
- Facultatif: mesurez et enregistrez le taux de dérive RTC en cours tout en étant en ligne (1)
Par «mécanisme», je veux dire un logiciel et / ou une configuration bien entretenus et documentés qui peuvent gérer les deux états «en ligne» contre «hors ligne», assurez-vous que l'horloge système est synchronisée avec la bonne source de temps (ntp contre rtc), détecter les changements d'état et corriger la dérive RTC. Peu importe qu'il soit implémenté en tant que configuration / plugin ntpd spécial, en tant que démon séparé, en tant que tâche cron, ou autre.
J'ai jeté un coup d'œil à Chrony , mais selon sa documentation, il essaie de prédire la dérive de l' horloge système , qui dans notre cas dérive de manière beaucoup plus imprévisible que le RTC. Chrony semble utiliser le RTC uniquement pour garder le temps entre les redémarrages.
(1) Remarque ntpd active le «mode 11 minutes» du noyau (mise à jour rtc de l'horloge système toutes les 11 minutes). Il semble qu'il n'y ait aucun moyen avec les noyaux actuels et ntpd d'empêcher le mode 11 minutes. Par conséquent, toutes les informations de dérive rtc sont perdues pendant que ntpd est en cours d'exécution (thx @billthor).
Mises à jour / modifications:
- Nous envisageons d'ajouter une horloge radio externe pour le signal MSF ou DCF77 (nous sommes basés en Europe) via USB ou série. Mais nous gardons plutôt le matériel léger.
- Nos collectionneurs sont situés à l'intérieur, souvent au sous-sol. L'ajout d'horloges GPS n'aidera donc pas.
- Nous utilisons Debian 7. Cela signifie hwclock depuis util-linux-2.20.1, ntpdate-4.2.6p5, ntpd depuis ntp-4.2.6.p5, chrony-1.24 (potentiellement 1.30).
- Notez que notre problème n'est pas que nous ne savons pas comment utiliser
ntpdate(8)
,hwclock(8)
,date(1)
, etc. S'il vous plaît voir la section ajoutée en italique sur ce que je veux dire avec « mécanisme ». - Ajout d'une note de bas de page sur le «mode 11 minutes»
- Voici une discussion très intéressante sur la synchronisation hors ligne et la dérive RTC