Страниц: [1] 2 3 ... 11
  Печать  
Автор Тема: Системное время, RTC, QNX и Win NT/2k  (Прочитано 64238 раз)
ed1k
QOR.Moderator
*****
Offline Offline

Сообщений: 739


Просмотр профиля WWW
« : Августа 27, 2004, 05:54:25 am »

Решил перенести обсуждение откровенного офтопика из форума по QNX4 сюда. Не думаю, что многие заинтересуются, но все же. Многие затронутые в том обсуждении вопросы натолкнули меня на некоторую дополнительную работу, которая есть еще больший офтопик.
Изначальное обсуждение было здесь:
http://qnx.org.ru/viewthread11n2950.html

А теперь, чего хотелось бы сказать. QNX-овая утилита 'rtc' поддерживает опцию '-l' вполне прилично, так что для систем двойной загрузки с виндовс проблем быть не должно. Для "боевой" системы двойная загрузка не нужна, следовательно всё можно сделать правильно, т.е. установить аппаратные часы по Гринвичу и не использовать '-l'. Ключ в реестре виндовс, который позволяет поставить RTC по Гринвичу, и который недокументирован и не поддерживается Майкрософт - тоже понятно. Если кто-то как BooBot - хочет потестировать на предмет, какие еще есть баги, кроме выхода из suspend - тоже милости прошу сюда пообсуждать проблемы. Сразу скажу какая есть еще проблема (собственно из-за этого я эту тему и начал) и которую не видит BooBot. Если запущена служба "Windows Time", то я вообще не знаю, что будет и это отдельный разговор. Если запущен NTP синхронизатор, то он запрещает так называемый kernel time daemon windows NT. Просматривая сайты по тематике у меня сложилось впечатление, что с этим демоном людям повозится конкретно пришлось, особенно тем, кто занимался вопросами точного времени на виндовс NT По умолчанию, в системе, как у меня дома и как на работе (мне не нужна точная синхронизация времени), в Win2K разрешен и работает этот демон. Он активируется "примерно раз в час" (дословно из документации Майкрософт), и если текущее время системы отличается от хранимого в RTC более, чем на минуту , то он (sic!) изменяет системное время (скачком) в соответствии со временем в RTC. Именно поэтому у меня с "Zulu time" (жаргон военных USA) в RTC было все хорошо, я даже написал про секретный ключ в форум, а потом все поломалось. Эта новость, наличие этого демона и механизм его работы, меня, мягко говоря, расстроил. Чем плохо скачкообразное изменение времени в системе можно почитать достаточно в интернете. Это очень толстый вопрос. Меня же, как работающего с новым, т.е. потенциально опасным для системы, железом и драйверами под него, очень огорчил факт, что от меня скрывают правду. Поясню. Если время в системе начинает отставать от реального - это верный признак, что что-то не правильно с прерываниями и/или их обработкой, т.е. теряются прерывания на канале 0 от системного таймера. Или же, другими словами, за время системного тика (то, что ClockPeriod() в QNX6 устанавливает) вся цепочка на INT 0 не успевает обрабатываться.
В общем, написал я утилитку, которая запрещает этот самый демон. Заодно и inf файл, если кто хочет погонять виндовс с аппаратными часами по Гринвичу. Собс-но, чем я сейчас и занимаюсь. У меня в системах ничего страшного не произойдет, если системное время сглючит, но вот в одной из систем мне этот демон определенно не нужен.
Взять утилитку можно здесь (RAR 3.11, 3608 байт):
http://ed1k.qnx.org.ru/utils/winnt/timesync.rar
Забавно, что по умолчанию тик таймера на 2-х гигагерцовом Атлоне 15 мс (что соответствует документации NT для x86 SMP систем, хотя Атлон определенно один), а на домашнем PII-350 - 10 мс (что соответствует заявленому в документации NT для унипроцессорных x86 систем).
И не пинайте больно, я утилитку ваял "на коленке за пол часа" На NT4 пока не тестировал.
Записан
booBot
Участник
*
Offline Offline

Сообщений: 0


Просмотр профиля
« Ответ #1 : Августа 27, 2004, 04:19:05 pm »

этот самый демон - Имеется ввиду родная виньдовская "служба" времени?
На одной машине я его остановил и запретил перед установкой NTP v4.2.0 for windas, на другой - забыл. (Через некоторое время я - в порыве паранойи - остановил все, ненужные мне виньдовые службы, в том числе и Windows Time)

На обеих машинах ntpd работал и работает нормально.

По поводу rtc -l hw:
В машинах с несколькими OS'ями и виньдой - останется проблема перехода "зима|лето" в не-виньдах. Виньды же именно в rtc будут при этом переходе крючить время...

В секретном ключике есть другая опасность. В статье предупреждают о проблемах с датами файлов на NTFS-разделах... Именно её, на мой взгляд, надо опасаться в первую очередь.

Хотя убийственным аргументом против ключика является факт отскока времени в виньдах с локального на UTC. На круглосуточно включённой машине я не решился бы этот ключик применять...

А для постоянно перезагружаемой туда~сюда рабочей машине - он весьма кстати. С ноутбуком стало работать комфортнее...

PS
Взял timesync.rar, почитал utcrtc.inf...
Выяснилось, что я поторопился со своими комментариями относительно родной "службы" и ntpd.
Наличие "этого демона" - как бы третьего, после ntpd и windows time, для меня полнейшая неожиданность...

Как я понимаю, его (этого демона) действие можно заметить только если система суперзагружена процессами и начинает пропускать аппаратные прерывания irq0.
Записан
ed1k
QOR.Moderator
*****
Offline Offline

Сообщений: 739


Просмотр профиля WWW
« Ответ #2 : Августа 28, 2004, 06:38:26 am »

Попробую еще раз. Этот демон о котором идет речь - это действительно третий механизм. По порядку:
1) Обычная установка WinNT/2K, без ntpd или "windows time". Работает ядрёный демон, который раз в час переставляет системное время в соответствии с хранимым в RTC. На всякие ключи в реестре ему плевать. Именно поэтому у меня системное время отскочило к UTC ночью. Именно его присутствие в NT ядре меня растроило и я написал программку-выключатель. Мне она нужна, независимо от того в какой часовой зоне тикает мой RTC.
2) Активизация "Windows Time" на w2k. Ядреный демон или останавливается или меняется его функциональность - мне разбираться лень. Это полностью NTP совместимая служба от Майкрософт, нужная для синхронизации времени в домене для ихней системы кодирования [примерная цитата из документации]. RTC по гринвичу скорее всего работать не будет, потому как есть "плюшка от Майкрософт" - периодически эта служба обновляет время в RTC. Т.е., если в п.1 эталоном времени выступает RTC, то в п.2 эталоном является системное время, синхронизированное виндовой службой (т.е. демон работает в другом направлении и наверняка в реестр тоже не заглядывает).
3) Сторонний ntpd. Должно все работать. демон из п.1 очень попортил когда-то кому-то кровь, но отключать его научились. Думаю, что ерундой типа обновления RTC тоже никто не занимается. Т.е. если нужен RTC по Гринвичу - ключ в реестр и запретить суспенд моду как класс. Я этим не пользуюсь, например по причине "замерзания времени" в виртуальных машинах

Проблем с датами на разделах пока не обнаружил. Фигню с часами два раза в год на мультисистемных компах пережить можно. Я даже думаю, что с этим недокументированным ключиком проблем может быть гораздо больше. Выход из suspend mode - я думаю, что "code reuse technique cut&paste" сыграла свою злую штуку. В одном месте смотрим на ключ в реестре, в двух других ("ядреный демон" и "выход из suspend" ) не смотрим. Хотя делаем одно и тоже действие. Может не cut&paste с последующей правкой, а просто в разных отделах люди разрабатывали. И последнее - даже суперпуперзагруженная процессами система не должна терять прерывания от таймера, тем более, что тик по умолчанию у них 10 миллисекунд. Это система, которую не на всякий пень поставишь (ну или если поставишь, то она стоять и будет )
P.S. timesync.rar обновил. Теперь архив 3389 байт. Переписал лицо диалога и подправил общую структуру и сообщения по АВОСТам, потому как сообщение "Не могу получить жетон" на W98 меня развеселило. Надеюсь ничего не поломал. Работает на NT4/2000 (только). На Win9X все совсем не так и ключа в реестре, видимо, нет.
P.P.S.
Usage message for timesync:
'timesync -d' запретить "ядреный демон" тихо.
'timesync -e' разрешить, тоже тихо.
'timesync' сделать нужное действие мышью. Может быть полезным, чтобы увидеть текущую гранулированность времени системы
Записан
booBot
Участник
*
Offline Offline

Сообщений: 0


Просмотр профиля
« Ответ #3 : Августа 28, 2004, 11:02:51 am »

Мда...
Вот что я ещё заметил - без килятора "этого демона", но с установленным ntpd и ключиком - при достаточно длительном отсутствии network connectivity (25~45 минут) - ntpd (похоже) перестаёт килять "этого демона" своими средствами. В результате - получаем отскок системного времени к UTC.

Замечено сегодня, в ~00:20, я специально не выключал ноут с 23:50 до 01:15 и работал на нём, не допуская ухода в suspend.
Забрал почту в 23:55 и отключился от сети. Переход через полночь прошёл нормально, а ещё через некоторое время - заметил отскок...

Кстати - может быть именно с этим и проблемы suspend'а объясняются - уснувший комп не имеет network connectivity...
Записан
booBot
Участник
*
Offline Offline

Сообщений: 0


Просмотр профиля
« Ответ #4 : Августа 28, 2004, 04:24:02 pm »


Нет, не помогает килятор "этого демона" при выходе из suspend'а... Отскакивает время.
Записан
MebiusTrack
Участник
*
Offline Offline

Сообщений: 0


Просмотр профиля
« Ответ #5 : Октября 25, 2004, 04:40:33 pm »

Господа, прошу прощения за то, что влезаю в ваш разговор... Прошу помощи в подобной ситуации. Перечитал эту ветку форума, мало что понял (познания в QNX - чуть выше чайника), и поэтому решил задать вопрос. Ситуация такая - есть несколько машин под QNX 4.25 в сети, в этой же сети аппарат под Win2k, имеющий синхронизацию системного времени с GPS. Требуется синхронизировать время машин под QNX с этим аппаратом. Заранее извиняюсь и благодарю всех за помощь!
Записан
booBot
Участник
*
Offline Offline

Сообщений: 0


Просмотр профиля
« Ответ #6 : Октября 25, 2004, 06:27:14 pm »

2 MebiusTrack:
Вам нужен ntpd для QNX4.

Могу выслать бинарники.
Записан
MebiusTrack
Участник
*
Offline Offline

Сообщений: 0


Просмотр профиля
« Ответ #7 : Октября 28, 2004, 12:36:13 pm »

booBotесли не трудно - вышлите, пожалуйста! mebiustrack@nxt.ru
Записан
booBot
Участник
*
Offline Offline

Сообщений: 0


Просмотр профиля
« Ответ #8 : Октября 28, 2004, 04:25:20 pm »

Проверяйте почту.

Запускать его так:
/usr/ucb/ntpd &
Если нужны сообщения в syslog - то добавьте "-L".

Могу и патч, накладываемый поверх первого выслать.
Исходники взяты отсюда.
Инструкции.
Записан
MebiusTrack
Участник
*
Offline Offline

Сообщений: 0


Просмотр профиля
« Ответ #9 : Октября 28, 2004, 07:23:05 pm »

Огромное спасибо! От патча тоже совершенно не откажусь, особенно, если он будет с объяснениями - что он выполняет...
Записан
MebiusTrack
Участник
*
Offline Offline

Сообщений: 0


Просмотр профиля
« Ответ #10 : Октября 28, 2004, 08:22:36 pm »

И, сорри, еще вопрос - отредактировал ntp.conf, запустил ntpd с ключиком -L - а он мне в syslog пишет init_ntp: bad drift compensation value. Что бы это значило?
PS Еще раз извиняюсь за "чайниковые" вопросы...
Записан
booBot
Участник
*
Offline Offline

Сообщений: 0


Просмотр профиля
« Ответ #11 : Октября 29, 2004, 04:45:49 pm »

В присланных бинарниках все мои улучшения уже воплощены. Мой патч как раз и добавляет использование демоном ntpd syslog-файла, из существенных изменений - вместо множества мелких рывков времени, делаемых в оригинальной версии порта - в моём патче применяется функция qnx_adjtime().

Патч может понадобиться лишь при дальнейших работах с данным проектом. На ftp.qnx.com его нет, и при сборке того, что оттуда скачано произойдёт откат...

Сейчас его пришлю.

RE: ntp_drift
Видимо демон не нашел файла /etc/ntp.drift при первом включении и сообщил об этом факте. Сам файл появился?
Что сообщает ntpdc localhost?
Приблизительно через ~1час разбег времени должен быть в районе 10~20 миллисекунд.
Записан
MebiusTrack
Участник
*
Offline Offline

Сообщений: 0


Просмотр профиля
« Ответ #12 : Октября 31, 2004, 10:37:11 am »

Ошибка ntp_drift повторяется каждый запуск, файл ntp.drift появляется, но имеет нулевой размер.
ntpdc localhost:

udp/ntp: service unknown, using default 123
(rem)Address     (lcl)   Strat  Poll  Reach  Delay  Offset  Disp
-192.168.1.13   wildcard   0     64    000     0.0    0.0  64000.0

по остальным двум локальным серверам то же самое. На серверах работают серверы точного времени по формату SNTP (порт 123).
Записан
mike
QOR.Moderator
*****
Offline Offline

Сообщений: 1186


Welcome to Lunatic Asylum.


Просмотр профиля WWW
« Ответ #13 : Октября 31, 2004, 10:54:16 am »

ntpq -c pe что показывает?

про ntp.drift читаем http://www.eecis.udel.edu/~mills/ntp/html/debug.html и узнаем, что файл обновляется каждый час
Записан
booBot
Участник
*
Offline Offline

Сообщений: 0


Просмотр профиля
« Ответ #14 : Октября 31, 2004, 11:54:48 pm »

Да, в файл /etc/services надо добавить ntp 123/udp.

Похоже - демон не может общаться с указанным сервером.
Пинги туда идут?
Какой версии там сервер?

Ё! Не прочитал сообщение до конца!
SNTP не годится, нужен настоящий NTP-сервер.
Те, что были в присланном ntp.conf, работают?

Я на winXP поставил порт ntp v4.2.0, отлично ведёт QNX'овый узел.
Записан
Страниц: [1] 2 3 ... 11
  Печать  
 
Перейти в: