OpenVZ Forum


Home » International » Russian » RHEL5 028stab057.2 -- ход системного таймера
RHEL5 028stab057.2 -- ход системного таймера [message #33623] Sun, 26 October 2008 14:33 Go to next message
seyko2 is currently offline  seyko2
Messages: 184
Registered: February 2007
Location: Moscow
Senior Member

From: *tc-exe.ru
Сейчас проверил на другой машине замеченную проблему с ходом системного таймера нв 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 Go to previous messageGo to next message
seyko2 is currently offline  seyko2
Messages: 184
Registered: February 2007
Location: Moscow
Senior Member

From: *tc-exe.ru
Начал разбираться с проблемой. Оказывется, теперь в 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 #33629 is a reply to message #33623] Mon, 27 October 2008 07:32 Go to previous messageGo to next message
koct9i is currently offline  koct9i
Messages: 51
Registered: February 2008
Member
From: *sw.ru
а вы проверяли как ведёт себя rhel5 ядро без openvz патчей?
Re: RHEL5 028stab057.2 -- ход системного таймера [message #33672 is a reply to message #33623] Thu, 30 October 2008 23:36 Go to previous message
seyko2 is currently offline  seyko2
Messages: 184
Registered: February 2007
Location: Moscow
Senior Member

From: *magma.at-nk.tc-exe.ru
Стоит поставить проблему, и найти решение через 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

Previous Topic: Запуск vzlist не под root
Next Topic: ioprio для VE0
Goto Forum:
  


Current Time: Sat Oct 20 17:02:57 GMT 2018