Home » International » Russian » 2.6.18, RTC и ntpd
2.6.18, RTC и ntpd [message #33510] |
Sat, 18 October 2008 20:46 |
|
Пользую ядро 2.6.18 от openvz в варианте EL5. Работая над hwclock после мучений и непоняток выяснил, что как только ntpd уберёт в параметрах ядра флаг UNSYNC (см вывод ntptime), то ядро начинает автоматом с перидом 11 минут писать системное время в RTC. И ничего с этим не поделать, хотя если поглуглить, то можно найти советы собрать ядро без этой фичи. Такой фичи в 2.4.x ядрах не было и в 2.6.x она тоже не нужна. Ибо почти во всех дистрах для установки системного времени при старте используется hwclock. А она правильно работает только в том случае, когда последней время в RTC писала именно она. Если при выключении компа hwclock не вызывается, то и установка системного времени при включении будет не верна. А если вызывается, то фича ядра по обновлению RTC в SYNC-состоянии мешает точно определить уход RTC. Ибо чем дольше мы не трогаем содержимое RTC, тем точнее можно определить уход RTC-времени за сутки. Править ntpd -- не путь, ибо самому ядру RTC для работы не нужён и фича по его правке -- чистой воды "вражеская диверсия".
Вот собираюсь закоментировать вызов notify_arch_cmos_timer() из do_adjtimex() (файл kernel/time.c). Но может я не прав и есть более цивильный способ пользовать ntpd и при этом чтоб время в RTC не обновлялось ядром?
|
|
|
|
Re: 2.6.18, RTC и ntpd [message #33558 is a reply to message #33532] |
Wed, 22 October 2008 00:19 |
|
maratrus wrote on Mon, 20 October 2008 07:41 | Здравствуйте,
Quote: |
А она правильно работает только в том случае, когда последней время в RTC писала именно она. Если при выключении компа hwclock не вызывается, то и установка системного времени при включении будет не верна.
|
не могли бы пояснить, почему это так?
|
hwclock запоминает время последнвей записи в RTC и потом вычисляет смешение, на которое убежадо или отстало время RTC с момента последней записи. Если последней в RTC писала не она, то вычисленное смещение будет неверно и, соответственно, при включении компа будет установлено неточное время.
|
|
|
Re: 2.6.18, RTC и ntpd [message #33560 is a reply to message #33558] |
Wed, 22 October 2008 06:28 |
maratrus
Messages: 1495 Registered: August 2007 Location: Moscow
|
Senior Member |
|
|
Поправьте, пожалуйста, меня, если я говорю неправду, но на мой взгляд ситуация следующая.
Работающий ntp сервис держит системный часы в хорошей степени точности и периодически сбрасывает эту информацию в RTC. Таким, образом RTC тоже содержит точную информацию, поэтому и при включении из RTC мы достанем довольно точное значение.
Да, при каждом вызове hwclock --set или --systohc вычисляется приблизительное время отставания/спешки и записывается в /etc/adjtime, который используется при hwclock --adjust.
То есть перед тем, как сделать на старте системы hwclock --hctosys зовется hwclock --adjust? Если не зовется, то почему должны возникнуть проблемы?
|
|
|
Re: 2.6.18, RTC и ntpd [message #33567 is a reply to message #33560] |
Wed, 22 October 2008 16:41 |
|
maratrus wrote on Wed, 22 October 2008 02:28 | Поправьте, пожалуйста, меня, если я говорю неправду, но на мой взгляд ситуация следующая.
Работающий ntp сервис держит системный часы в хорошей степени точности и периодически сбрасывает эту информацию в RTC. Таким, образом RTC тоже содержит точную информацию, поэтому и при включении из RTC мы достанем довольно точное значение.
|
Последняя фраза неверна. Ошибка будет пропорциональна разнице между последим моментом записи в RTC c помощью hwclock и моментом записи туда ядром. И кроме того, запись в RTC времени ядром не дает точно определить величину спешки-отставания. Так что при отсутствии интернета иметь на компе точное время втаком случае трудно. А вот если ядро не трогает RTC, то получить ошибку не более 1с за полгода можно запросто.
|
|
|
|
Re: 2.6.18, RTC и ntpd [message #33570 is a reply to message #33567] |
Wed, 22 October 2008 17:20 |
maratrus
Messages: 1495 Registered: August 2007 Location: Moscow
|
Senior Member |
|
|
У себя на системе (Fedora 7) нашел только скрипт rc.sysinit, который делает hwclokc --hctosys, вот соответсвующий кусок
CLOCKFLAGS="$CLOCKFLAGS --hctosys"
case "$UTC" in
yes|true) CLOCKFLAGS="$CLOCKFLAGS --utc"
CLOCKDEF="$CLOCKDEF (utc)" ;;
no|false) CLOCKFLAGS="$CLOCKFLAGS --localtime"
CLOCKDEF="$CLOCKDEF (localtime)" ;;
esac
case "$ARC" in
yes|true) CLOCKFLAGS="$CLOCKFLAGS --arc"
CLOCKDEF="$CLOCKDEF (arc)" ;;
esac
case "$SRM" in
yes|true) CLOCKFLAGS="$CLOCKFLAGS --srm"
CLOCKDEF="$CLOCKDEF (srm)" ;;
esac
[ -x /sbin/hwclock ] && /sbin/hwclock $CLOCKFLAGS
То есть здесь используется adjusting при hwtosys?
[Updated on: Wed, 22 October 2008 17:21] Report message to a moderator
|
|
|
Re: 2.6.18, RTC и ntpd [message #33579 is a reply to message #33570] |
Fri, 24 October 2008 00:01 |
|
Про adjusting... Стандартная утилита hwclock имеет фунцию --adjust, которая вычисляет предполагаемый уход времени в RTC и пишет в RTC скорректированное на предполагаемуб величину ухода время. У себя (gentoo) я убрал эту фунцию из утилиты. Ибо она мешает точно вычислить величину ухода времени. Вместо этого у меня hwclock с функцией --hctosys для установки системного времени использует уже скорректированное на величину ухода время (в стандартной утилите это не выполняется и перед --hctosys сначала надо выполнить --adjust).
Скорее всего в Fedora..RedHat утилита стандартная. И при этом они исторически не делают вызов --adjust перед --hctosys (в отличии от Gentoo). Типа как нибудь установим время, а там ntpd всё выправит.
В Gentoo тоже норовят приколоться. Пользую OpenRC 0.2.5 (новая система загрузочных скриптов Gentoo). Так там при хранении в RTC времени UTC (не локального) вызов --adjust делают, а вызов --hctosys пропускают. Типа ядро само в таком случае правильно установит время. Может и установит, только незачем выбрасывать стандартный шаг (то есть если время RTC в localtime, то --hctosys выполняем, если в UTC, то не выполняем). В общем, глаз да глаз нужен.
В своей версии hwclock я добавил в вывод --show разницы между точным временем (скорректированным RTC) и системным. И вот наткнулся на проблему: всё выглядит так, как будто параметры хода системного таймера меняются от перезагрузки. Подберу их так, что разница времен практически не меняется и в пределах нескольких микросекунд на протяжении минимум получаса. Однако стоит перезагрузитьтся, и получаем уход минимум в 50 микросекунд за секунду. Что-то здесь не так. Как-будто в ядре для расчета времени используется не инициализированная переменная.
|
|
|
Re: 2.6.18, RTC и ntpd [message #33626 is a reply to message #33579] |
Mon, 27 October 2008 01:40 |
|
Начал разбираться с проблемой. Оказывется, теперь в 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.
PS: да, в 2.6.24 уже появилась переменная no_sync_cmos_clock, которая запрещает изменение значений cmos в состоянии SYNC. Правда снаружи (например через sysfs) она не доступна и используется для ядер, работающих под системой паравиртуализации.
|
|
|
Re: 2.6.18, RTC и ntpd [message #33630 is a reply to message #33579] |
Mon, 27 October 2008 07:37 |
maratrus
Messages: 1495 Registered: August 2007 Location: Moscow
|
Senior Member |
|
|
Здравствуйте еще раз,
никак не могу зацепиться за мысль, чтобы понять вашу проблему.
Quote: |
Подберу их так, что разница времен практически не меняется и в пределах нескольких микросекунд на протяжении минимум получаса.
|
Так как раз в 11 минут происходит синхронизация rtc и system clock, то достаточно следить, чтобы часы не разбегались в течение одиннадцати минут.
Quote: |
Однако стоит перезагрузитьтся, и получаем уход минимум в 50 микросекунд за секунду
|
То есть у Вас проблема не во всяких там алгоритмах adjusting'а, а в том, что rtc и системные часы идут с разной скоростью?
Quote: |
Как-будто в ядре для расчета времени используется не инициализированная переменная.
|
Вот, что я нарыл.
Текущее время и дата хранятся в переменной xtime типа
struct timespec xtime __attribute__ ((aligned (16)));
Инициализация происходит в функции time_init() (привожу выдержки из i386 архитектуры)
#define INITIAL_JIFFIES ((unsigned long)(unsigned int) (-300*HZ))
void __init time_init(void)
{
...
//Количество секунд, прошедших с 01.01.1970,
//берется информация из rtc
xtime.tv_sec = get_cmos_time();
//Количество наносекунд, прошедших с начала текущей секунды
//INITIAL_JIFFIES - это изначальное значение jiffies (его делают
"отрицательным")
//!!Это место мне не очень понятно
// cказано, что tv_nsec выбирают таким образом, чтобы первое переполнение jiffies попало на границу секунды,
//но с таким значение, как выбрано, этого не происходит. Попробую выяснить.
xtime.tv_nsec = (INITIAL_JIFFIES % HZ) * (NSEC_PER_SEC / HZ);
...
}
То есть, например, в этом месте количество tv_nsec ставится независимо от rtc.
Quote: |
Оказывется, теперь в Linux возможны разные источники для системного времени
|
Ага, у каждого есть свой рейтинг, насколько я понял, выбор должен происходить по рейтингу либо по имени, которое, например, может придти из sysfs или commandline.
Выбор происходит в функции:
static struct clocksource *select_clocksource(void)
Она просто смотрит на список доступных таймеров, если встретила таймер по требуемому имени, то его выбирает, иначе действует по рейтингу. Я выписал рейтинги:
jiffies = 0
pit = 110
acpi_pm = 200
hpet = 250
tsc = 300
Пока я не очень понимаю, когда и кто у Вас на машине выбрал acpi_pm вместо tsc.
Надо внимательнее присмотреться либо к коду ядра, либо к init скриптам на машине.
Надеюсь, что-нибудь из вышесказанного поможет.
|
|
|
Re: 2.6.18, RTC и ntpd [message #33645 is a reply to message #33630] |
Tue, 28 October 2008 04:20 |
|
У меня hpet в списке нет
Он возможен для i386 (не 64) ?
На машине с Amd Duron 800 сам по-себе выбирается acpi_pm вместо tsc. Хотя вручную можно и tsc установить и работает.
Да, моя задача -- чтоб подогнать ход скорректированного RTC и системного времени так, чтоб они не разбегались (практически) без наличия внешнего источника времени. В RTC ядро пришет, когда ntpd работает. Когда он перестает работаеть, то и ядро перестает писать в RTC. У себя я убрал из ядра эту фичу. Chrony (он только один реально может конкурировать с классическим ntpd) может писать в RTC сам. Так что и в ntpd теоретически это можно запихнуть. И незачем ядру заниматься исправлением недоделок в ntpd.
Пока проверил jiffies и pit на проблемной машине. С pit всё в порядке, при перезагрузке частота хода не меняется. Так что если проблема и существует, то тогда внутри tsc clocksource, а не в общей части кода. Ибо на проблемной-рабочей машине всегда выбирается именно tsc
У jiffies тоже частота хода не меняется при перезагрузке. Однако сам ход очень специфичен: в течение 50 секунл обгоняем образцовое время со скоростью примерно 75микросек за секунду, о потом резко (за секунду) сразу отстаем на примерно 3750 микромекунд. Такая вот пила своеобразная. Но пила не плывет и стоит на месте. На второй машине тоже пила, но более приятная: сначала плавно отстаем, потом резко подводим вперед.
При исполъзовании jiffies как clocksource запуск X-сервера затягивается почти на минуту, в течение которой он изображает подвисание: на клавиатуру машина не реагирует, экраны не переключаются, экран пуст. Потом всё же запускается. Ну кто-бы такое ожидал всего лишь от выбора другого clocksource.
[Updated on: Tue, 28 October 2008 04:30] Report message to a moderator
|
|
|
|
Re: 2.6.18, RTC и ntpd [message #33671 is a reply to message #33626] |
Thu, 30 October 2008 22:58 |
|
Стоит поставить проблему, и найти решение через 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 меня вполне устраивает. То есть скорость ухода системного времени от точного достатоно мала и не меняется при перезагрузке.
PS: да, tsc может быть помечен как нестабильный (есть такие проверки в ядре). И тогда выбирается всё равно acpi_pm (это к вопросу от том, кто на другой машине у меня устанавливает как clocksource acpi_pm)
На некоторых платах (типа ASUS) и с acpi_pm есть проблемы (умудрились как-то не так реализовать). Но это уже другая история.
[Updated on: Thu, 30 October 2008 23:35] Report message to a moderator
|
|
|
Re: 2.6.18, RTC и ntpd [message #34205 is a reply to message #33671] |
Sun, 14 December 2008 08:16 |
piavlo
Messages: 159 Registered: January 2007
|
Senior Member |
|
|
seyko2 wrote on Fri, 31 October 2008 00:58 | Стоит поставить проблему, и найти решение через GOOGLE не составляет труда.
В общем, у себя я выставил acpi_pm как clocksource. Ибо с tsc есть масса проблем.
1) не всегда работает на мультипроцессорных системах.
2) может меняться при изменении рабочей частоты процессора (процессоры с плавающей частотой в зависимости от загрузки)
|
В новых процессорах интела есть constant_tsc (meaning the TSC doesn't change with CPU core frequency).
Quote: |
3) в новых ядрах (новее 2.6.18) пытаются калибровать TSC с помощью acpi_pm. Ошибка калибрации может быть такова, что ntpd не сможет скомпенсировать уход. В 2.6.18 tsc не калибруют, и как видно из опыта, при перезагрузке эта частота всё равно меняется. Скорее всего, у современных процов что-то должно быть, задающее частоту хода tsc.
4) при паравиртуализации и при миграции VM тоже возникают проблемы с частотой TSC
Стабильность хода системного времени при использовании acpi_pm как clocksource меня вполне устраивает. То есть скорость ухода системного времени от точного достатоно мала и не меняется при перезагрузке.
PS: да, tsc может быть помечен как нестабильный (есть такие проверки в ядре). И тогда выбирается всё равно acpi_pm (это к вопросу от том, кто на другой машине у меня устанавливает как clocksource acpi_pm)
На некоторых платах (типа ASUS) и с acpi_pm есть проблемы (умудрились как-то не так реализовать). Но это уже другая история.
|
|
|
|
Goto Forum:
Current Time: Wed Oct 02 12:11:09 GMT 2024
Total time taken to generate the page: 0.04893 seconds
|