Noyau Linux détectant une mauvaise fréquence de processeur

Après un démarrage à froid d'un serveur Debian 6.0.8 (HP ProLiant), ntpdfait des ravages avec l'heure du système: décalage et gigue par rapport aux serveurs de temps de référence habituels et fiables qui croissent sans limite. (Notez qu'un serveur jumeau identique n'a eu aucun problème du tout.) Après de nombreuses tentatives infructueuses pour résoudre le problème sur le ntpdcôté, j'ai décidé d'essayer un redémarrage, et tout s'est bien passé.

Afin d'étudier le problème, j'ai trouvé cette anomalie, ce qui pourrait expliquer mes problèmes d'horloge:

root@n1:~# zgrep Detected /var/log/dmesg*
/var/log/dmesg:[    0.004000] Detected 2400.110 MHz processor.
/var/log/dmesg.0:[    0.004000] Detected 2383.579 MHz processor.
/var/log/dmesg.1.gz:[    0.004000] Detected 2400.036 MHz processor.
/var/log/dmesg.2.gz:[    0.004000] Detected 2400.298 MHz processor.
/var/log/dmesg.3.gz:[    0.004000] Detected 2400.165 MHz processor.
/var/log/dmesg.4.gz:[    0.004000] Detected 2400.410 MHz processor.

Notez que dans l'avant-dernier démarrage (celui qui pose problème), la fréquence du processeur détectée est une valeur aberrante claire. Sans la valeur aberrante, l'erreur et l'écart-type de la fréquence détectée par rapport à la fréquence nominale est de +0,15 MHz ± 0,25 MHz. Pour le démarrage problématique, j'ai une erreur de -16,4 Mhz, ce qui est environ 100 fois plus important que prévu.

Mes questions:

1. Une erreur de ce type peut-elle rendre la ntpdiscipline temporelle instable / inutilisable? Est-ce la raison de mes problèmes d'horloge?

2. Ce type de comportement est-il un symptôme de matériel flacky? Le serveur doit-il passer en maintenance matérielle?

Mise à jour

Quelques données utiles:

• le noyau est 2.6.32-5-amd64 (Debian 2.6.32-48squeeze4)
• current_clocksource est tsc
• l'erreur pour lpjest (bien sûr) cohérente avec l'erreur sur la fréquence du processeur

Quelques lignes de contexte pour ce qui précède grep

[    0.000000] hpet clockevent registered
[    0.000000] Fast TSC calibration using PIT
[    0.004000] Detected 2400.110 MHz processor.
[    0.000008] Calibrating delay loop (skipped), value calculated using timer frequency.. 4800.22 BogoMIPS (lpj=9600440)

Je me suis convaincu que le problème était une fréquence de compteur d'horodatage (TSC) mal identifié .

Apparemment, le noyau calibre le TSC par rapport à la minuterie d'intervalle programmable (PIT). Habituellement, la fréquence CPU identifiée est de 2400,204 ± 0,134 MHz, ce qui correspond à une précision d'environ 56 ppm. Après le démarrage problématique, la fréquence du processeur a été estimée à 2383,579 MHz, ce qui correspond à une erreur d'environ 6900 ppm, qui ntpdn'a pas pu compenser. En fait, au cours des 10 premiers 30h30 de fonctionnement, l'horloge système a gagné environ 4h30, soit environ 7 000 ppm.

Étant donné que l'erreur dans la fréquence TSC correspond à la dérive de l'horloge système, je conclurais que le comportement anormal de l'horloge a été causé par un mauvais étalonnage TSC.

Cependant je n'ai jamais vu un si gros problème: je me demande toujours les causes possibles (hw, sw?) De ce mauvais calibrage.

Ce type de comportement est atypique. Une bonne vérification serait de surveiller les valeurs du ntp.driftfichier pour voir si des changements importants se produisent lorsque le comportement se présente. S'il continuait à changer de manière significative, NTP tentait de contourner un problème. Si c'était le cas, c'est un signe que le noyau a mal identifié la vraie fréquence d'horloge au démarrage, ou que l'horloge elle-même était lente pour les mauvaises parties de démarrage. Malheureusement, cet événement n'est pas un signal clair de problèmes matériels.

Si cela se reproduit, regardez ce fichier ntp.drift.