Synchroniser l'horloge avec NTP en ligne et avec RTC hors ligne?

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

Votre situation est inhabituelle, et je serais surpris si quelqu'un propose une ntpdconfiguration standard pour faire ce que vous voulez. Cela dit, j'aime être surpris, et cela arrive assez souvent autour de ces parties.

Mais jusqu'à ce que quelqu'un vienne avec une meilleure idée, avez-vous envisagé une crontabentrée comme celle-ci?

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

IE, toutes les cinq minutes, essayez de synchroniser l'horloge via ntpdate, et si (et seulement si) cela échoue, ajustez l'horloge matérielle pour la dérive en fonction du /etc/adjtimefichier (dont le format est détaillé dans man hwclock, et dont la première ligne que vous avez remplie de manière appropriée en utilisant vos connaissances du débit de ce RTC particulier), puis réglez l'horloge système à partir du RTC.

Notez que si vous optez pour une solution comme celle-ci et que vous déployez un nombre important de ces systèmes, il est considéré comme poli de travailler avec le pool et de contribuer les serveurs en proportion de votre utilisation. Vous pouvez trouver plus d'informations sur http://www.pool.ntp.org/en/vendors.html .

NTP dispose déjà de mécanismes pour savoir s'il est en ligne ou hors ligne, et il basculera vers des sources de priorité inférieure si nécessaire. Il est très facile de vérifier la valeur de portée pour déclencher une autre source, mais je m'en tiendrai à NTP. Comme indiqué ci-dessous, la surveillance et la correction de la dérive RTC sont susceptibles d'être difficiles.

Dans les jours précédant Internet, j'utilisais un programme qui téléphonait à une source de données et synchronisait l'horloge. Certains services peuvent toujours fournir une source horaire via un modem. Cela nécessiterait l'accès à une ligne téléphonique.

Il y a des problèmes connus avec l'horloge locale, qui ne s'appliquent pas au RTC. Certains problèmes sont documentés dans la liste des problèmes connus du système d'exploitation NTP . Cela peut expliquer la dérive de votre horloge. Les résoudre peut résoudre votre problème. En l'absence de tiques manquées, j'ai trouvé que la source de temps locale (système) peut être très stable.

Vous pourrez peut-être utiliser le pilote d'horloge Dumb (33) avec un programme qui écrit l'heure RTC appropriée sur le périphérique / dev / dumbclockX.

Il existe un certain nombre d'autres pilotes basés sur les horloges radio. Certains d'entre eux utilisent des services en ondes courtes comme WWV et CHU, qui peuvent fonctionner dans des environnements où les signaux GPS ne sont pas disponibles. Pour l'Europe, cette liste comprendrait la BBC, TDF, RBU et RMW.

Pavel Krejci a également écrit un pilote RTC, mais il ne semble pas être intégré aux pilotes officiels. Cela peut fonctionner avec la synchronisation de type PPS.

Il devrait être possible de mesurer la dérive RTC avant le déploiement. Cependant, vous devrez vous assurer que le RTC n'est pas mis à jour automatiquement. Lorsque l'horloge système est mise à jour avec la fonction adjtimex, le RTC peut être mis à jour toutes les 11 minutes.

NTP mettra à jour l'horloge lorsqu'elle sera connectée. Normalement, NTP refusera de faire de gros ajustements à l'horloge du système. Il existe des options permettant d'ajuster dans quelle mesure l'horloge peut être réglée.

J'ai suggéré des options pour utiliser le RTC ci-dessus. Une horloge radio peut être plus appropriée qu'une horloge GPS.

Mesurer la dérive en l'absence d'une source de temps fiable pour la comparer est probablement un effort futile. Si l'heure locale est instable, vous ne pouvez pas l'utiliser pour surveiller le RTC et vice versa. La mesure de la dérive lorsque NTP est connecté ne fonctionnera pas si le noyau met à jour le RTC toutes les 11 minutes. Les RTC que j'ai utilisés ont une résolution d'une seconde, donc ils devraient dériver de manière significative pour être mesurables de manière fiable.