2.6.18 и ход системного таймера
Сейчас проверил на другой машине замеченную проблему с ходом системного таймера на SUBJ (в реадкции от openvz). Проблема повторилась. Поэтому это не связано с BIOS, это ошибка ядра.
Проблема: синхронизируемся с определённым источником времени, например с ntp0.zenon.net, с помощью ntpd. Потом можно ntpd остановить. Уход системного времени после этого не превышает десятков миллисекунд за 12 часов. И это стабильно. Но стоит перезагрузиться, и старые параметры настройки системного таймера уже не подходят. Уход составляет 100-200 микросекунд за секунду.
Впервые проблема была замечена при сравнени параметров, устанавлевыемых ntpd и chrony. Они довольно значительно отличались. Потом было замечено, что и ntpd после перезагрузки начинает устанавливать другие значения. Разброс не сильно значителен: у меня частота меняется от -124 до 65 по показаниям ntptime. Впечатление, что ядро использует для вычисления хода времени кроме стандартных параметров ещё и неинициализированную переменную, значение которой меняется от перезагрузки к перезагруке. Наверно поэтому и требуется устанавливать другие параметры частоты, чтобы компенсировать влияние этой переменной.
Соответсвенно хотелось бы, чтобы народ проверил у себя данное свойство, и если оно подтвердится, как-то оформить BUG-report.
- Для комментирования войдите или зарегистрируйтесь
Это не бага, скорее фича.
Это не бага, скорее фича. У работающей системы уже ооочень давно так. А перед шутдауном системное время надо бы сбрасывать в BIOS (hwclock).
Подробности
Начал разбираться с проблемой. Оказывется, теперь в Linux возможны разные источники для системного времени. Возможные источники показываются в /sys/devices/system/clocksource/clocksource0/avaible_clocksource
У меня этот список такой: acpi_pm jiffies tsc pit
Текущий clocksource показывается в том же каталоге в файле current_clocksource. У меня на одной машине в нём было tsc, на другой acpi_pm. Соответственно предположение, что от перезагрузки к перезагрузке может меняться этот самый current_clocksource. Правда можно указать в командной строке ядру, какой current_clocksource хочешь, задав clocksource=xxx Можно поменять clocksource и путём записи нового значения в current_clocksource. Так-что теперь посмотрю, как ведёт себя freq (вывод ntptime) после перезагрузки для разных clocksource.
Решение про clocksource
Стоит поставить проблему, и найти решение через GOOGLE не составляет труда.
В общем, у себя я выставил acpi_pm как clocksource. Ибо с tsc есть масса проблем.
1) не всегда работает на мультипроцессорных системах.
2) может меняться при изменении рабочей частоты процессора (процессоры с плавающей частотой в зависимости от загрузки)
3) в новых ядрах (новее 2.6.18) пытаются калибровать TSC с помощью acpi_pm. Ошибка калибрации может быть такова, что ntpd не сможет скомпенсировать уход. В 2.6.18 tsc не калибруют, и как видно из опыта, при перезагрузке эта частота всё равно меняется. Скорее всего, у современных процов что-то должно быть, задающее частоту хода tsc.
4) при паравиртуализации и при миграции VM тоже возникают проблемы с частотой TSC
Стабильность хода системного времени при использовании acpi_pm как clocksource меня вполне устраивает. То есть скорость ухода системного времени от точного достатоно мала и не меняется при перезагрузке.
Спасибо! Не знал :-[
Спасибо! Не знал :-[