Моя текущая система резко отличается от hwclock и ntpd. Я просмотрел множество форумов и сообщений в Интернете и в SF, но не нашел подходящего решения.
Вот мой вывод ntpq -pn:
remote refid st t when poll reach delay offset jitter ============================================================================= 122.226.192.4 66.220.9.122 2 u 30 64 3 53.734 146507. 127822. 120-88-46-10.sn 158.43.128.33 2 u 33 64 3 150.373 12823.5 127821. suisho.attritio 133.100.9.2 2 u 29 64 3 34.351 148556. 133910. 123.146.124.27 61.153.197.226 3 u 27 64 3 21.123 152572. 133909. 114.80.81.1 204.152.184.72 2 u 29 64 3 55.605 148520. 129851.
На данный момент мои часы говорят:
Fri 25 Mar 2011 03:27:06 PM CST -0.048504 seconds
Мое «свидание» говорит:
Fri Mar 25 15:21:17 CST 2011
Они отключились примерно на 6 минут, и я только что сделал ntpdate -u около 10 минут назад ...
Кроме того, в настоящее время я использую 32-разрядную версию Centos 5.5 с ядром 2.6.18-194.32.1.el5.
Что мне делать, чтобы исправить системные часы? Аппаратные часы вроде работают нормально.
РЕДАКТИРОВАТЬ: Добавлены новые значения в мою строку загрузки ядра, как описано Sacx. Хотя после перезагрузки задержка намного лучше, но после 16 часов время все равно замедляется на 35 минут. Только что проверил мой current_clocksource, и он все еще говорит tsc. Я попытался изменить его на acpi_pm, но это не сработало. Глядя на мой available_clocksource, он показывает: jiffies tsc pit
Добавьте эти параметры в строку загрузки ядра
notsc divider=10 clocksource=acpi_pm
и перезапустите вашу систему. Это связано с RHEL 5 Hyper-V Guest - не удается синхронизироваться с NTP после обновления ядра.
Вы можете попробовать использовать другой NTPd, например OpenBSD: openntpd
Может это кому-то поможет. Недавно у нас была такая же проблема, и мы получили дрейф в разумных пределах после установки adtimex.
aptitude install adjtimex