Kernel de Linux que detecta una frecuencia de procesador incorrecta

Después de un arranque en frío de un servidor Debian 6.0.8 (HP ProLiant), ntpdcausó estragos en el tiempo del sistema: compensación y fluctuación con respecto a los servidores de tiempo de referencia habituales y confiables que crecen sin límite. (Tenga en cuenta que un servidor gemelo idéntico no tuvo ningún problema). Después de muchos intentos fallidos de solucionar el problema ntpd, decidí intentar reiniciar, y todo salió bien.

Para investigar el problema, encontré esta discrepancia, que podría explicar mis problemas de reloj:

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.

Tenga en cuenta que en el segundo último arranque (el problemático) la frecuencia de CPU detectada es un valor atípico claro. Sin el valor atípico, el error y la desviación estándar de la frecuencia detectada con respecto a la frecuencia nominal es +0.15 MHz ± 0.25 MHz. Para el arranque problemático, tengo un error de -16.4 Mhz, que es aproximadamente 100 veces mayor de lo esperado.

Mis preguntas:

1. ¿Puede un error de este tipo hacer que la ntpdisciplina de tiempo sea inestable / inutilizable? ¿Es esta la razón de mis problemas con el reloj?

2. ¿Es este tipo de comportamiento un síntoma de hardware flacky? ¿Debería el servidor entrar en mantenimiento hw?

Actualizar

Algunos datos útiles:

• el núcleo es 2.6.32-5-amd64 (Debian 2.6.32-48squeeze4)
• current_clocksource es tsc
• el error lpjes (por supuesto) consistente con el error en la frecuencia de la CPU

Algunas líneas de contexto para lo anterior 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)

Me convencí de que el problema era una frecuencia de contador de sello de tiempo (TSC) mal identificada .

Aparentemente, el núcleo está calibrando el TSC contra el temporizador de intervalo programable (PIT). Por lo general, la frecuencia de CPU identificada es 2400.204 ± 0.134 MHz, que corresponde a una precisión de aproximadamente 56 ppm. Después del arranque problemático, la frecuencia de la CPU se estimó en 2383.579 MHz, lo que corresponde a un error de aproximadamente 6900 ppm, que ntpdno pudo compensar. De hecho, durante las primeras 10h30m de funcionamiento, el reloj del sistema ganó aproximadamente 4m30s, que es de aproximadamente 7000 ppm.

Dado que el error en la frecuencia del TSC corresponde a la deriva en el reloj del sistema, concluiría que el comportamiento anormal del reloj fue causado por una calibración incorrecta del TSC.

Sin embargo, nunca vi un problema tan grande: todavía me pregunto sobre las posibles causas (hw, sw?) De esta calibración incorrecta.

Este tipo de comportamiento es atípico. Una buena comprobación sería monitorear los valores del ntp.driftarchivo para ver si ocurren cambios significativos cuando se mostraba el comportamiento. Si seguía cambiando significativamente, NTP intentaba sesgar un problema. Si ese fuera el caso, es una señal de que el kernel identificó erróneamente la frecuencia real del reloj en el inicio, o que el reloj en sí era lento para las partes incorrectas del arranque. Desafortunadamente, este evento no es una señal clara de problemas de hardware.

Si vuelve a ocurrir, mire ese archivo ntp.drift.