O kernel do Linux detectando a freqüência incorreta do processador

Question

Após uma inicialização a frio de um servidor Debian 6.0.8 (HP ProLiant), ntpd causou estragos na hora do sistema: offset e jitter em relação aos servidores de hora de referência usuais e confiáveis que crescem sem limite. (Observe que um servidor gêmeo idêntico não teve nenhum problema.) Depois de muitas tentativas malsucedidas de corrigir o problema no lado ntpd , decidi tentar uma reinicialização e tudo correu bem.

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.

Note que na segunda última inicialização (a problemática) a freqüência de CPU detectada é um outlier claro. Sem o outlier, o erro e desvio padrão da frequência detectada em relação ao nominal é 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 disciplina ntp instável / inutilizável? Esta é a razão para os problemas do meu relógio?

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

Atualizar

Alguns dados úteis:

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

Algumas linhas de contexto para o grep

acima

[    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)

    

Answer 1

Eu me convenci de que o problema era uma frequência contador de tempo (TSC) identificada incorretamente.

Aparentemente, o kernel está calibrando o TSC contra o temporizador de intervalo programável (PIT). Normalmente, a frequência da CPU identificada é de 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 ntpd não conseguiu compensar. De facto, durante as primeiras 10:30 horas de funcionamento, o relógio do sistema ganhou cerca de 4m30s, o que é cerca de 7000 ppm.

Como o erro na frequência do TSC corresponde ao desvio no relógio do sistema, eu concluiria que o comportamento anormal do relógio foi causado por uma calibração incorreta da 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.

    

Answer 2

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

Se isso acontecer novamente, assista ao arquivo ntp.drift.