После холодной загрузки сервера 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 Mhz, что примерно в 100 раз больше, чем ожидалось.
Мои вопросы:
Может ли ошибка такого типа сделать ntp временная дисциплина нестабильна / непригодна для использования? Это причина моих проблем с часами?
Является ли такое поведение признаком ненадежного оборудования? Следует ли серверу перейти на техническое обслуживание?
Обновить
Некоторые полезные данные:
current_clocksource является tsclpj (конечно) согласуется с ошибкой на частоте процессораНекоторые контекстные строки для вышеизложенного 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 по программируемый интервальный таймер (ПИТ). Обычно идентифицируемая частота процессора составляет 2400,204 ± 0,134 МГц, что соответствует точности около 56 ppm. После проблемной загрузки частота процессора была оценена как 2383,579 МГц, что соответствует ошибке около 6900 ppm, что ntpd не смог компенсировать. Фактически, за первые 10:30 работы системные часы набрали около 4:30, что составляет около 7000 ppm.
Поскольку ошибка в частоте TSC соответствует дрейфу системных часов, я бы сделал вывод, что аномальное поведение часов было вызвано неправильной калибровкой TSC.
Однако я никогда не видел такой большой проблемы: мне все еще интересно узнать о возможных причинах (hw, sw?) Этой неправильной калибровки.
Такое поведение нетипично. Хорошей проверкой будет наблюдение за значениями ntp.drift файл, чтобы увидеть, произошли ли существенные изменения при обнаружении поведения. Если он продолжал значительно меняться, NTP пытался обойти проблему. Если это было так, это признак того, что ядро неправильно определило истинную тактовую частоту при запуске, или что сами часы были медленными для неправильных частей загрузки. К сожалению, это единственное событие не является явным сигналом об аппаратных проблемах.
Если это произойдет снова, посмотрите файл ntp.drift.