Comment puis-je mesurer et empêcher la dérive de l'horloge?

15

Sur plusieurs plates-formes de production, nous avons observé des symptômes qui semblent suggérer que l'heure du jour saute périodiquement vers l'avant ou vers l'arrière. Les sauts durent généralement environ 1 seconde, s'annulent généralement (sautent en avant puis en arrière très peu de temps après) et se produisent environ 50 fois par jour. Cette dérive est plus visible pendant les périodes d'utilisation maximale des applications et pendant les périodes d'opérations d'E / S de disque élevées telles que les sauvegardes quotidiennes. Ces dérives affectent notre application sensible sensible en temps réel.

Les systèmes sont des serveurs Oracle Netra X4250 et Netra X4270 exécutant SLES 11SP2 avec un noyau par défaut 3.0.58-0.6.6.

$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc hpet acpi_pm

$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc

Nous avons désactivé NTP , mais cela n'a eu aucun effet sur les dérives. Existe-t-il des outils qui mesurent la dérive de l'heure de la journée? Comment éviter cela?

Ce sont des plates-formes de production, et nous ne pouvons pas recréer le problème dans nos laboratoires, donc ma capacité à expérimenter est limitée. Si je le laisse à mes propres appareils, j'écrirai un outil pour mesurer la dérive et peut-être expérimenterai avec une source d'horloge HPET .

linux sles clock brett
la source
5
La désactivation de NTP rend les horloges beaucoup plus instables ... la seule raison que je vois pour NTP de ne pas garder l'horloge en ligne est que l'horloge est hors de contrôle, et NTP refuse de la mettre à jour (voir ntpdate(8)ou ntpd(8)).
vonbrand
1
NTPD suit et corrige la dérive de l'horloge, mais ce que vous avez n'est pas une dérive. La dérive est toujours dans la même direction à peu près la même quantité au fil du temps. S'il saute au hasard vers l'avant et vers l'arrière, il n'y a aucun moyen de le prévoir et de s'y adapter.
Patrick
1
Ce que @Patrick a dit est juste, le problème que vous décrivez est un saut discontinu dans le temps vers l'avant et vers l'arrière, plusieurs fois par jour. NTP fonctionne bien sur la dérive, mais cela ne vous aidera pas beaucoup. Quelque chose est en train de réinitialiser la date de votre système sur une source de temps externe qui n'a peut-être qu'une résolution d'une seconde. Si vos serveurs sont x86 *, le RTC matériel peut être la source et certains travaux cron le coupable. En ce qui concerne la mesure du décalage d'horloge, la réponse ntpdate de Bratchley est une approche raisonnable à condition qu'une bonne référence d'horloge de la strate 1 soit utilisée: exécutez une fois par minute et gnuplotez le résultat pour une image.
duanev
1
Parcourez cette évaluation du démarrage de NTP sur un nouveau serveur ( drdobbs.com/embedded-systems/… ). Il faut des heures NTP pour apprendre un nouveau cristal. Pour les très mauvais cristaux, le NTP devra «faire avancer» l'horloge de plusieurs fois plusieurs fois pendant l'entraînement (voir les figures 4 et 5 de cet article). Une valeur finale en ntp.drift de 118 ppm est de 10 secondes par jour ou 208 ms toutes les 30 minutes. Bien que ce ne soit pas ce que l'OP voyait, NTP peut initialement provoquer des sauts notables dans le temps.
duanev

Réponses:

8

Existe-t-il des outils qui mesurent la dérive de l'heure de la journée?

Les seuls outils que je connaisse sont les outils NTP qui devraient suffire. Vous n'avez pas à configurer réellement ntpd pour qu'il se synchronise avec une source d'horloge donnée, vous pouvez simplement utiliser l' -doption ntpdatepour récupérer le décalage calculé.

Exemple:

[davisja5@xxxadmvlm08 ~]$ ntpdate -d clock.redhat.com 2>/dev/null | egrep "^offset"
offset -0.004545
[davisja5@xxxadmvlm08 ~]$

-d est l'option de débogage qui fait le travail NTP sans toucher à l'horloge système.

Des conseils sur la façon d'éviter cela?

Je ne suis pas trop surpris que vous ne puissiez pas reproduire cela dans des environnements de développement / test car cela est probablement dû à l'horloge matérielle. Si vous avez un support matériel avec quelqu'un, j'essaierais de faire réparer vos machines. Une possibilité consiste à échanger l'une des machines de développement pour cette machine de production, à réparer les anciens systèmes PROD et à la réintroduire en tant que machine de développement pour remplacer celle qui est maintenant dans PROD.

En dehors de cela, la commutation de la source d'horloge matérielle est à peu près tout ce que vous pouvez faire. Si vous ne faites pas ou ne pouvez pas faire l'échange, je vous suggère de suivre la route hpet. Vous pouvez tester si la modification de la source d'horloge perturbe les services système, puis la déployer en production en tant que grêle.

Bratchley
la source
Par «mesurer la dérive de l'horloge», je ne voulais pas dire la dérive d'une source de temps de référence, telle que NTP vous donne. Je voulais dire un outil qui peut détecter des "sauts" dans le temps de l'horloge du jour sur une plage de temps continue. Par exemple, prenez des échantillons de l'heure du jour toutes les 50 ms et signalez si la différence par rapport au dernier échantillonnage est trop éloignée de 50 ms. Un tel outil montrerait si l'heure du jour dérive de l'horloge matérielle sous-jacente pour une raison quelconque.
brett
1
La présence d'une telle intervention ne provoquerait-elle pas probablement une dégradation des performances plus importante que ce que vous espérez résoudre? Selon toute probabilité, c'est un problème matériel, vous devrez donc faire réparer le matériel ou utiliser une source d'horloge sans ce problème. tscest basé sur le processeur, il est donc logique qu'une activité plus élevée du processeur déclenche de toute façon un problème avec l'horloge matérielle. Si hpet est assez rapide pour vous, alors vous devrez peut-être l'essayer, faire réparer ou faire l'échange. Ce sont les seules options que je peux voir pour vous.
Bratchley
3

Une solution consiste à utiliser HPET

Voir aussi Minuterie d'événement haute précision

Pour le définir comme paramètre de démarrage, utilisez

clocksource=hpet

Sur le matériel plus ancien, le TSCétait souvent instable et était désactivé par le noyau.

Avec l'avènement des processeurs multicœurs / hyper-threadés, des systèmes à plusieurs processeurs et des systèmes d'exploitation en veille prolongée, le TSC ne peut plus être utilisé pour fournir des résultats précis ...

Wikipedia: Compteur d'horodatage


la source
Sur un système de production présentant les symptômes de gigue d'horloge, j'ai commuté la source d'horloge sur hpet. Cela n'a eu aucun effet sur les symptômes de gigue d'horloge observés.
brett
HPET est une minuterie matérielle externe et ne peut pas trembler. Cette solution semble donc être un mauvais chemin. Il y avait beaucoup de problèmes de synchronisation avec le matériel plus ancien, en particulier lors de l'utilisation de la virtualisation. Avez-vous également vérifié cela avec différents logiciels?
1

J'ai écrit un outil plus détaillé pour corréler les mesures d'horloge avec les symptômes de latence présentés par notre application. Cet outil semble exclure ce que je soupçonnais auparavant de gigue dans l'horloge Linux.

Pour faire court, mon hypothèse initiale n'était pas valide. Mais j'ai beaucoup appris sur les horloges Linux grâce aux réponses et aux liens, donc merci à tous ceux qui ont répondu!

brett
la source
3
(...) mon hypothèse initiale n'était pas valide Pourriez-vous nous dire quelle était la véritable cause, alors?
Piotr Dobrogost
0

L'horloge n'est-elle pas censée être monotone à moins que quelqu'un ne la change? Les sauts en arrière ne devraient pas être possibles. Il doit y avoir quelque chose qui règle l'horloge - un travail cron ou un autre démon (par exemple un appel à hwclock --adjust). Je me souviens que ntp lui-même met à jour les statistiques de dérive et les compense régulièrement et si vous ne parvenez pas à exécuter ntp pendant une longue période et à obtenir un énorme décalage, il gâche du temps pendant des jours si vous ne réinitialisez pas /etc/adjtime. Vous pouvez avoir quelque chose comme ça mis en place - quelque chose qui réajuste périodiquement la dérive du temps (et provoque des sauts).

ntp est en fait destiné à contrer ce problème.

orion
la source
C'est ce que je pensais aussi. Ma lecture des sources d'horloge matérielle suggère que le compteur devrait augmenter de façon monotone. Si tel était le cas, au pire, nous devrions observer des taux de ticks irréguliers, mais jamais reculer. Sur un système multiprocesseur, je comprends que tsc doit être synchronisé entre les processeurs - c'est peut-être ce qui cause les sauts en arrière?
brett