Kernel Linux che rileva una frequenza del processore errata

Dopo un avvio a freddo di un server Debian 6.0.8 (HP ProLiant), si è ntpdcreato il caos con il tempo di sistema: offset e jitter rispetto ai soliti e affidabili server di riferimento che crescono senza limiti. (Si noti che un server gemello identico non ha avuto alcun problema.) Dopo molti tentativi falliti di risolvere il problema sul ntpdlato ho deciso di provare a riavviare e tutto è andato bene.

Per indagare sul problema ho riscontrato questa discrepanza, che potrebbe spiegare i miei problemi di clock:

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.

Si noti che nel secondo ultimo avvio (quello problematico) la frequenza di CPU rilevata è chiaramente un valore anomalo. Senza il valore anomalo, l'errore e la deviazione standard della frequenza rilevata rispetto a quella nominale è +0,15 MHz ± 0,25 MHz. Per l'avvio problematico ho un errore di -16,4 Mhz, che è circa 100 volte maggiore del previsto.

Le mie domande:

1. Un errore di questo tipo può rendere ntpinstabile / inutilizzabile la disciplina del tempo? È questo il motivo dei miei problemi di orologio?

2. Questo tipo di comportamento è un sintomo di hardware flacky? Il server dovrebbe andare in manutenzione hw?

Aggiornare

Alcuni dati utili:

• il kernel è 2.6.32-5-amd64 (Debian 2.6.32-48squeeze4)
• current_clocksource è tsc
• l'errore per lpj(ovviamente) è coerente con l'errore sulla frequenza CPU

Alcune linee di contesto per quanto sopra 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)

Mi convinsi che il problema era una frequenza di contatore timestamp (TSC) erroneamente identificata .

Apparentemente il kernel sta calibrando il TSC rispetto al timer di intervallo programmabile (PIT). Di solito la frequenza della CPU identificata è 2400.204 ± 0.134 MHz, che corrisponde a una precisione di circa 56 ppm. Dopo l'avvio problematico, la frequenza della CPU è stata stimata a 2383.579 MHz, che corrisponde a un errore di circa 6900 ppm, che ntpdnon è stato in grado di compensare. Infatti durante i primi 10h30m di funzionamento l'orologio di sistema ha guadagnato circa 4m30s, che è di circa 7000 ppm.

Poiché l'errore nella frequenza TSC corrisponde alla deriva nell'orologio di sistema, concluderei che il comportamento anomalo dell'orologio è stato causato da una calibrazione TSC errata.

Tuttavia non ho mai visto un problema così grande: mi chiedo ancora le possibili cause (hw, sw?) Di questa calibrazione errata.

Questo tipo di comportamento è atipico. Un buon controllo sarebbe quello di monitorare i valori del ntp.driftfile per vedere se si verificano cambiamenti significativi durante la visualizzazione del comportamento. Se continuava a cambiare in modo significativo, NTP stava tentando di distorcere un problema. In tal caso, è un segno che il kernel ha identificato erroneamente la vera frequenza di clock all'avvio o che l'orologio stesso era lento per le parti sbagliate dell'avvio. Sfortunatamente, questo evento non è un chiaro segnale di problemi hardware.

Se succede di nuovo, guarda quel file ntp.drift.