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


11

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

Si je comprends bien, une combinaison de ntpd et hwclock vous permet déjà de faire toutes ces choses.
Roy

@Roy Sure. La question est: comment combiner ntp (d) et RTC (hwclock) de manière cohérente pour obtenir une précision maximale?
Nils Toedtmann

Je comprends que l'horloge système dérive plus que RTC. Je suis curieux de savoir ce que vous avez trouvé inacceptable en ce qui concerne la manière / l'efficacité de la gestion de Chrony de la dérive du système? Comment Chrony a-t-il échoué pour vous?
dfc

@dfc chrony n'a pas échoué sur nous. Nous ne l'avons pas encore essayé car il semble ne pas utiliser le RTC pour garder du temps pendant les périodes hors ligne, ce qui, je pense, augmenterait la précision dans notre cas d'utilisation. Nous testerons chrony si aucune autre méthode plus prometteuse n'est suggérée.
Nils Toedtmann

Je pense que vous devriez vous pencher sur Chrony. Respectueusement, il semble que vous rejetez une bonne option basée sur une intuition. À mon avis, il est à l'envers d'enquêter sur chrony si aucun RTC-ntpd n'est trouvé. Il semble que la chose la plus simple soit de voir si Chrony répond à vos besoins et sinon de descendre ce
terrier de

Réponses:


4

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 .


Vous avez cloué l'idée de base :-) Mais cela ne compte pas (encore) comme réponse car il ne tient pas compte de la dérive RTC (constante, mais significative). Pouvons-nous l'améliorer, par exemple en utilisant /etc/adjtimeet hwclock --adjust?
Nils Toedtmann

Oui; voir au dessus.
MadHatter

C'est le genre de solution que j'avais en tête lorsque j'ai écrit mon commentaire précédent. De plus, si l'horloge système est actuellement synchronisée via ntpd, vous pouvez utiliser hwclock pour mesurer et définir un taux de dérive assez précis pour le RTC.
Roy

Malheureusement non, voir les commentaires sur ntpd & '11 -minute mode '
Nils Toedtmann

-1

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.


Je ne comprends pas comment cela se rapporte à ma question. Je ne pense pas que mon problème soit un manque de pilotes ... ou est-ce?
Nils Toedtmann

@NilsToedtmann Pour autant que je puisse trouver, il n'y a pas de pilote officiel pour le RTC. Je crois que le localpilote utilise simplement l'horloge des serveurs, que vous signalez des dérives. Je mettrai à jour ma réponse.
BillThor

Quand vous dites «pilotes», voulez-vous dire les pilotes du noyau Linux (dont il y en a beaucoup) ou les fonctionnalités ntpd? Merci pour vos conseils, certains d'entre eux sont intéressants - même si je pense qu'ils auraient dû être publiés plutôt sous forme de commentaires. Thx en particulier pour avoir mentionné les «11 minutes de plus», j'avais oublié cela. J'ai mis à jour ma question.
Nils Toedtmann

@NilsToedtmann Non, je veux dire les pilotes d'horloge NTP. D'après mon expérience, les RTC dérivent normalement, mais pas à des taux élevés si la pâte est bonne. Les tiques manquées peuvent être un problème avec l'horloge système.
BillThor
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.