| RHEL5 028stab057.2 -- ход системного таймера [message #33623] |
Sun, 26 October 2008 14:33  |
|
|
Сейчас проверил на другой машине замеченную проблему с ходом системного таймера нв SUBJ. Проблема повторилась. Поэтому это не связано с BIOS, это ошибка ядра.
Проблема: синхронизируемся с определённым источником времени, например с ntp0.zenon.net, с помощью ntpd. Потом можно ntpd остановить. Уход системного времени после этого не превышает десятков миллисекунд за 12 часов. И это стабильно. Но стоит перезагрузиться, и старые параметры настройки системного таймера уже не подходят. Уход составляет 100-200 микросекунд за секунду.
Впервые проблема была замечена при сравнени параметров, устанавлевыемых ntpd и chrony. Они довольно значительно отличались. Потом было замечено, что и ntpd после перезагрузки начинает устанавливать другие значения. Разброс не сильно значителен: у меня частота меняется от -124 до 65 по показаниям ntptime. Впечатление, что ядро использует для вычисления хода времени кроме стандартных параметров ещё и неинициализированную переменную, значение которой меняется от перезагрузки к перезагруке. Наверно поэтому и требуется устанавливать другие параметры частоты, чтобы компенсировать влияние этой переменной.
Соответсвенно хотелось бы, чтобы народ проверил у себя данное свойство, и если оно подтвердится, как-то оформить BUG-report.
|
|
|
|
| Re: RHEL5 028stab057.2 -- ход системного таймера [message #33627 is a reply to message #33623] |
Mon, 27 October 2008 01:41  |
|
|
Начал разбираться с проблемой. Оказывется, теперь в Linux возможны разные источники для системного времени. Возможные источники показываются в /sys/devices/system/clocksource/clocksource0/avaible_clockso urce
У меня этот список такой: acpi_pm jiffies tsc pit
Текущий clocksource показывается в том же каталоге в файле current_clocksource. У меня на одной машине в нём было tsc, на другой acpi_pm. Соответственно предположение, что от перезагрузки к перезагрузке может меняться этот самый current_clocksource. Правда можно указать в командной строке ядру, какой current_clocksource хочешь, задав clocksource=xxx Можно поменять clocksource и путём записи нового значения в current_clocksource. Так-что теперь посмотрю, как ведёт себя freq (вывод ntptime) после перезагрузки для разных clocksource.
|
|
|
|
|
|
| Re: RHEL5 028stab057.2 -- ход системного таймера [message #33672 is a reply to message #33623] |
Thu, 30 October 2008 23:36 |
|
|
Стоит поставить проблему, и найти решение через GOOGLE не составляет труда.
В общем, у себя я выставил acpi_pm как clocksource. Ибо с tsc есть масса проблем.
1) не всегда работает на мультипроцессорных системах.
2) может меняться при изменении рабочей частоты процессора (процессоры с плавающей частотой в зависимости от загрузки)
3) в новых ядрах (новее 2.6.18) пытаются калибровать TSC с помощью acpi_pm. Ошибка калибрации может быть такова, что ntpd не сможет скомпенсировать уход. В 2.6.18 tsc не калибруют, и как видно из опыта, при перезагрузке эта частота всё равно меняется. Скорее всего, у современных процов что-то должно быть, задающее частоту хода tsc.
4) при паравиртуализации и при миграции VM тоже возникают проблемы с частотой TSC
Интересная статья про TSC: http://www.x86-secret.com/?option=newsd&nid=846
А вот здесть http://ltt.polymtl.ca/svn/trunk/lttv/doc/developer/tsc.txt прямо говорится, что пока дело не устаканиться, не стоит выбирать tsc как clocksource
Until TSC becomes invariant, AMD recommends that operating
system developers avoid TSC as a fast timer source on
affected systems. (AMD recommends that the operating system
should favor these time sources in a prioritized manner:
HPET first, then ACPI PM Timer, then PIT.) The following
pseudo-code shows one way of determining when to use TSC:
Стабильность хода системного времени при использовании acpi_pm как clocksource меня вполне устраивает. То есть скорость ухода системного времени от точного достатоно мала и не меняется при перезагрузке.
PS: да, tsc может быть помечен как нестабильный (есть такие проверки в ядре). И тогда выбирается всё равно acpi_pm (это к вопросу от том, кто на другой машине у меня устанавливает как clocksource acpi_pm)
На некоторых платах (типа ASUS) и с acpi_pm есть проблемы (умудрились как-то не так реализовать). Но это уже другая история.
[Updated on: Thu, 30 October 2008 23:57] Report message to a moderator |
|
|
|
OpenVZ Forum
Members
Search
Help
Register
Login
Home
