Kernel do Linux detectando frequência incorreta do processador

Após uma inicialização a frio de um servidor Debian 6.0.8 (HP ProLiant), ntpdcausou estragos no horário do sistema: offset e jitter com relação aos servidores de horário de referência usuais e confiáveis ​​que crescem sem limite. (Observe que um servidor idêntico duplo não teve nenhum problema.) Depois de muitas tentativas malsucedidas de corrigir o problema do ntpdlado, decidi tentar uma reinicialização e tudo deu certo.

Para investigar o problema, encontrei essa discrepância, o que poderia explicar meus problemas com o relógio:

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.

Observe que na segunda última inicialização (a problemática) a frequência da CPU detectada é claramente clara. Sem o outlier, o erro e o desvio padrão da frequência detectada em relação à nominal são de +0,15 MHz ± 0,25 MHz. Para a inicialização problemática, tenho um erro de -16,4 Mhz, que é cerca de 100 vezes maior que o esperado.

Minhas perguntas:

1. Um erro desse tipo pode tornar a ntpdisciplina do tempo instável / inutilizável? É este o motivo dos meus problemas com o relógio?

2. Esse tipo de comportamento é um sintoma de hardware inadequado? O servidor deve entrar em manutenção hw?

Atualizar

Alguns dados úteis:

• O kernel é 2.6.32-5-amd64 (Debian 2.6.32-48squeeze4)
• current_clocksource é tsc
• erro para lpj(é claro) é consistente com erro na freqüência da CPU

Algumas linhas de contexto para o acima 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)

Eu me convenci de que o problema era uma frequência de contador de data e hora (TSC) mal identificado .

Aparentemente, o kernel está calibrando o TSC contra o temporizador de intervalo programável (PIT). Geralmente, a frequência da CPU identificada é 2400,204 ± 0,134 MHz, o que corresponde a uma precisão de cerca de 56 ppm. Após a inicialização problemática, a frequência da CPU foi estimada em 2383.579 MHz, o que corresponde a um erro de cerca de 6900 ppm, que ntpdnão foi capaz de compensar. De fato, durante as primeiras 10h30m de funcionamento, o relógio do sistema ganhou cerca de 4m30s, ou seja, 7000 ppm.

Como o erro na frequência do TSC corresponde ao desvio no relógio do sistema, concluo que o comportamento anormal do relógio foi causado por uma calibração incorreta do TSC.

No entanto, eu nunca vi um problema tão grande: ainda estou me perguntando sobre as possíveis causas (hw, sw?) Dessa calibração errada.

Esse tipo de comportamento é atípico. Uma boa verificação seria monitorar os valores do ntp.driftarquivo para ver se mudanças significativas acontecem quando o comportamento está aparecendo. Se continuasse mudando significativamente, o NTP estava tentando desviar de um problema. Se for esse o caso, é um sinal de que o kernel identificou erroneamente a verdadeira frequência do relógio na inicialização ou o próprio relógio estava lento para as partes incorretas da inicialização. Infelizmente, esse evento não é um sinal claro de problemas de hardware.

Se isso acontecer novamente, observe o arquivo ntp.drift.