Linux-Kernel erkennt falsche Prozessorfrequenz

Nach einem Kaltstart eines 6.0.8-Debian-Servers (HP ProLiant) kam ntpdes zu Problemen mit der Systemzeit: Offset und Jitter im Vergleich zu den üblichen und zuverlässigen Referenzzeitservern, die unbegrenzt wachsen. (Beachten Sie, dass ein identischer Zwillingsserver überhaupt kein Problem hatte.) Nach vielen erfolglosen Versuchen, das Problem auf der ntpdSeite zu beheben, entschied ich mich für einen Neustart, und alles ging in Ordnung.

Um das Problem zu untersuchen, habe ich diese Diskrepanz gefunden, die meine Uhrprobleme erklären könnte:

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.

Beachten Sie, dass beim vorletzten Start (dem problematischen) die erkannte CPU-Frequenz ein deutlicher Ausreißer ist. Ohne den Ausreißer beträgt der Fehler und die Standardabweichung der erfassten Frequenz in Bezug auf die nominelle Frequenz +0,15 MHz ± 0,25 MHz. Für das problematische Booten habe ich einen Fehler von -16,4 Mhz, der ca. 100 mal größer ist als erwartet.

Meine Fragen:

1. Kann ein Fehler dieser Art die ntpZeitdisziplin instabil / unbrauchbar machen? Ist das der Grund für meine Uhrprobleme?

2. Ist diese Art von Verhalten ein Symptom für fehlerhafte Hardware? Sollte der Server in die Hardware-Wartung gehen?

Aktualisieren

Einige nützliche Daten:

• Kernel ist 2.6.32-5-amd64 (Debian 2.6.32-48squeeze4)
• current_clocksource ist tsc
• Fehler für lpjist (natürlich) konsistent mit Fehler auf der CPU-Frequenz

Einige Kontextzeilen für die oben genannten 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)

Ich habe mich selbst davon überzeugt, dass das Problem eine falsch identifizierte Zeitstempelzählerfrequenz (TSC) ist.

Anscheinend kalibriert der Kernel die TSC gegen den programmierbaren Intervall-Timer (PIT). Normalerweise beträgt die identifizierte CPU-Frequenz 2400,204 ± 0,134 MHz, was einer Genauigkeit von etwa 56 ppm entspricht. Nach dem problematischen Booten wurde die CPU-Frequenz auf 2383,579 MHz geschätzt, was einem Fehler von ca. 6900 ppm entspricht, der ntpdnicht kompensiert werden konnte. Tatsächlich hat die Systemuhr während der ersten 10h30m ungefähr 4m30s gewonnen, was ungefähr 7000 ppm entspricht.

Da der Fehler in der TSC-Frequenz der Drift in der Systemuhr entspricht, würde ich den Schluss ziehen, dass das abnormale Uhrverhalten durch eine falsche TSC-Kalibrierung verursacht wurde.

Allerdings habe ich noch nie ein so großes Problem gesehen: Ich wundere mich immer noch über die möglichen Ursachen (hw, sw?) Dieser falschen Kalibrierung.

Diese Art von Verhalten ist untypisch. Es empfiehlt sich, die Werte der ntp.driftDatei zu überwachen, um festzustellen, ob beim Auftreten des Verhaltens wesentliche Änderungen eingetreten sind. Wenn es sich ständig signifikant änderte, versuchte NTP, ein Problem zu umgehen. Wenn dies der Fall ist, ist dies ein Zeichen dafür, dass der Kernel die wahre Taktfrequenz beim Start falsch identifiziert hat oder dass die Taktfrequenz für die falschen Teile des Startvorgangs langsam war. Leider ist dieses eine Ereignis kein eindeutiges Signal für Hardwareprobleme.

Wenn es wieder vorkommt, beobachten Sie die Datei ntp.drift.