Ядро Linux обнаруживает неправильную частоту процессора

После холодной загрузки сервера Debian 6.0.8 (HP ProLiant) произошел ntpdхаос с системным временем: смещение и дрожание по отношению к обычным и надежным эталонным серверам времени растут без ограничений. (Обратите внимание, что у идентичного сервера-близнеца проблем не было вообще.) После многих неудачных попыток решить проблему на ntpdстороне, я решил попробовать перезагрузить компьютер, и все прошло нормально.

Чтобы исследовать проблему, я нашел это несоответствие, которое могло объяснить мои проблемы с часами:

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.

Обратите внимание, что во второй последней загрузке (проблемной) обнаруженная частота процессора является явным выбросом. Без выброса погрешность и стандартное отклонение обнаруженной частоты относительно номинальной составляет +0,15 МГц ± 0,25 МГц. Для проблемной загрузки у меня ошибка -16,4 МГц, что примерно в 100 раз больше, чем ожидалось.

Мои вопросы:

1. Может ли ошибка этого типа сделать ntpвременную дисциплину нестабильной / непригодной для использования? Это причина моих проблем с часами?

2. Является ли этот тип поведения симптомом неисправного оборудования? Должен ли сервер перейти на обслуживание hw?

Обновить

Некоторые полезные данные:

• ядро 2.6.32-5-amd64 (Debian 2.6.32-48squeeze4)
• current_clocksource является tsc
• ошибка для lpj(конечно) согласуется с ошибкой на частоте процессора

Некоторые контекстные строки для вышеупомянутого 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)

Я убедил себя, что проблема заключается в неправильной частоте счетчика меток времени (TSC).

Очевидно, ядро ​​калибрует TSC по отношению к программируемому интервальному таймеру (PIT). Обычно идентифицируемая частота процессора составляет 2400,204 ± 0,134 МГц, что соответствует точности около 56 частей на миллион. После проблемной загрузки частота процессора оценивалась в 2383,579 МГц, что соответствует ошибке около 6900 ppm, которую ntpdне удалось компенсировать. Фактически, в течение первых 10 часов 30 минут работы системные часы набрали около 4 часов 30 минут, что составляет около 7000 частей на миллион.

Поскольку ошибка в частоте TSC соответствует дрейфу системных часов, я бы пришел к выводу, что неправильное поведение часов было вызвано неправильной калибровкой TSC.

Однако я никогда не видел такой большой проблемы: я все еще задаюсь вопросом о возможных причинах (hw, sw?) Этой неправильной калибровки.

Этот тип поведения нетипичен. Хорошей проверкой было бы следить за значениями ntp.driftфайла, чтобы увидеть, происходят ли значительные изменения при обнаружении поведения. Если это продолжало изменяться значительно, NTP пытался обойти проблему. Если это так, то это признак того, что ядро ​​неверно идентифицировало истинную тактовую частоту при запуске, или сами часы были медленными для неправильных частей загрузки. К сожалению, это одно событие не является четким сигналом аппаратных проблем.

Если это произойдет снова, посмотрите этот файл ntp.drift.