OpenVZ Forum


Home » International » Russian » 2.6.18, RTC и ntpd
2.6.18, RTC и ntpd [message #33510] Sat, 18 October 2008 20:46 Go to next message
seyko2 is currently offline  seyko2
Messages: 188
Registered: February 2007
Location: Moscow
Senior Member

Пользую ядро 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 #33532 is a reply to message #33510] Mon, 20 October 2008 11:41 Go to previous messageGo to next message
maratrus is currently offline  maratrus
Messages: 1495
Registered: August 2007
Location: Moscow
Senior Member
Здравствуйте,

Quote:


А она правильно работает только в том случае, когда последней время в RTC писала именно она. Если при выключении компа hwclock не вызывается, то и установка системного времени при включении будет не верна.



не могли бы пояснить, почему это так?
Re: 2.6.18, RTC и ntpd [message #33558 is a reply to message #33532] Wed, 22 October 2008 00:19 Go to previous messageGo to next message
seyko2 is currently offline  seyko2
Messages: 188
Registered: February 2007
Location: Moscow
Senior Member

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 Go to previous messageGo to next message
maratrus is currently offline  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 Go to previous messageGo to next message
seyko2 is currently offline  seyko2
Messages: 188
Registered: February 2007
Location: Moscow
Senior Member

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 #33569 is a reply to message #33567] Wed, 22 October 2008 17:14 Go to previous messageGo to next message
maratrus is currently offline  maratrus
Messages: 1495
Registered: August 2007
Location: Moscow
Senior Member
- Если ntp периодически пишет в RTC, то в RTC хранится точное время.
- При выключении в RTC точное время.
- При включении мы делает hwclock --hctosys. Здесь делается adjusting? Или где? Если не здесь, то как понимать
Quote:


Ошибка будет пропорциональна разнице между последим моментом записи в RTC c помощью hwclock и моментом записи туда ядром.


Эта разница влият только на то, как hwclock делает adjusting? Если при включении мы тупо берем информацию из RTC и засовываем в system clock, то эта разница не имеет значения.

Quote:


Так что при отсутствии интернета иметь на компе точное время втаком случае трудно.


Временное отсутствие интернета при работающем ntp или что?

Quote:


А вот если ядро не трогает RTC


Как это? А кто будет трогать?
Re: 2.6.18, RTC и ntpd [message #33570 is a reply to message #33567] Wed, 22 October 2008 17:20 Go to previous messageGo to next message
maratrus is currently offline  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 Go to previous messageGo to next message
seyko2 is currently offline  seyko2
Messages: 188
Registered: February 2007
Location: Moscow
Senior Member

Про 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 Go to previous messageGo to next message
seyko2 is currently offline  seyko2
Messages: 188
Registered: February 2007
Location: Moscow
Senior Member

Начал разбираться с проблемой. Оказывется, теперь в 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 Go to previous messageGo to next message
maratrus is currently offline  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 Go to previous messageGo to next message
seyko2 is currently offline  seyko2
Messages: 188
Registered: February 2007
Location: Moscow
Senior Member

У меня hpet в списке нет Sad
Он возможен для 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 #33647 is a reply to message #33645] Tue, 28 October 2008 07:28 Go to previous messageGo to next message
maratrus is currently offline  maratrus
Messages: 1495
Registered: August 2007
Location: Moscow
Senior Member
Насчет рейтинга и jiffies:

 * @rating:             rating value for selection (higher is better)
 *                      To avoid rating inflation the following
 *                      list should give you a guide as to how
 *                      to assign your clocksource a rating
 *                      1-99: Unfit for real use
 *                              Only available for bootup and testing purposes.
 *                      100-199: Base level usability.
 *                              Functional for real use, but not desired.
 *                      200-299: Good.
 *                              A correct and usable clocksource.
 *                      300-399: Desired.
 *                              A reasonably fast and accurate clocksource.
 *                      400-499: Perfect
 *                              The ideal clocksource. A must-use where
 *                              available.



/* The Jiffies based clocksource is the lowest common
 * denominator clock source which should function on
 * all systems. It has the same coarse resolution as
 * the timer interrupt frequency HZ and it suffers
 * inaccuracies caused by missed or lost timer
 * interrupts and the inability for the timer
 * interrupt hardware to accuratly tick at the
 * requested HZ value. It is also not reccomended
 * for "tick-less" systems.
 */


jiffies - наипростейший способ вести учет времени, основанный просто на значении переменной jiffies, учитываю возможность оключения прерываний очень ненадежный.
Re: 2.6.18, RTC и ntpd [message #33671 is a reply to message #33626] Thu, 30 October 2008 22:58 Go to previous messageGo to next message
seyko2 is currently offline  seyko2
Messages: 188
Registered: February 2007
Location: Moscow
Senior Member

Стоит поставить проблему, и найти решение через 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 Go to previous message
piavlo is currently offline  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 есть проблемы (умудрились как-то не так реализовать). Но это уже другая история.

Previous Topic: Боремся со спамом на VE: проблемы с iptables
Next Topic: Нужна помошь в настроке сети в двумя интерфейсами.
Goto Forum:
  


Current Time: Sat Feb 04 12:10:01 GMT 2023

Total time taken to generate the page: 0.00821 seconds