Как настроить время?

батарейку поменять, не? Та же самая фигня с роутером (каждое включение - 70-й год. Лечится натравлением ntp на ближайший сервер.

Не загружать Linux в течении часа и в BIOS смотреть отставание часов. Я не знаю как сейчас, но раньше системное время "тикало" на основании интервального таймера, а хардварные часы использовались только при загрузке системы. Но при этом время в харварные часы записывалось не часто. А если у вас постоянно системное время совпадает с показаниями hwclock --show, то мне это непонятно.

Ну ещё как вариант, вызвать "hwclock --set ..." и установить время, отличное от системного, а потом посмотреть, что покажет "hwclock --show".

>Не загружать Linux в течении часа и в BIOS смотреть отставание часов.

Ну, это понятно, но хочется более простого решения :) Машина из тех, что постоянно нужна.

>А если у вас постоянно системное время совпадает с показаниями hwclock --show, то мне это непонятно.

Вот-вот. При этом в /etc/conf.d/hwclock clock_systohc="NO"

>>батарейку поменять, не?

на кварцевый резонатор это никак не влияет

>на кварцевый резонатор это никак не влияет

В самом конце службы - влияет.

Другое дело, что машина не выключается. По идее, часы запитываются не батарейкой, а от БП.

IIRC, hwclock умеет учитывать clock drift. Ищи в man опцию adjust.

clock drift относится к выключенному состоянию системы, и вычисляется он на основании разницы между аппаратными часами и системными часами, возникающией на достаточно большом интервале времени. А у автора аппаратные часы (rtc) почемуто синхронизированны с системным временем.

Вот, отставание по сравнению с другой машиной (где время точное) уже составило почти 5 минут. Это где-то часа за полтора-два.

hwclock --show всё равно показывает разницу в десятые доли секунды :-/

Варианты, так на ночь глядя. а) ntpd, (openntpd), который синхается с неправильным ntp-сервером; б) свежее глючное ядро; в) что-то умерло в материке.

а) отпадает, т.к. передёргивание /etc/init.d/ntp-client выставляет правильное время :)

б) ядро - 2.6.30-r6. На двух других машинах всё ок.

в) но зачем тогда синкается время хардверное и софтверное? :)

sudo rm /var/lib/hwclock/adjtime
reboot

>sudo rm /var/lib/hwclock/adjtime

Нет такого. А /etc/adjtime и /var/lib/ntp/ntp.drift сносил.

Хм. Значит ntpd все-таки работает?
1. После сноса ntp.drift демона перезапускали? Кстати, в конфиге ntpd в качестве driftfile указан именно он?
2. Интересует вывод ntpq -p.

Хм. Значит ntpd все-таки работает?

Угу.

1. После сноса ntp.drift демона перезапускали?

Естественно. И всё повторялось не один раз. В разных комбинациях перезапусков ntp-client, ntpd, сносов adjtime, drift...

Кстати, в конфиге ntpd в качестве driftfile указан именно он?

Угу. Я, собственно, роясь в конфигах про этот файл сперва и узнал. Кстати, он создаётся сам (при перезапуске ntpd, кажется), но внутри - 0.000

2. Интересует вывод ntpq -p.

# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 moscow0.srv-hos 193.62.22.74     2 u   14   64  377    4.482  1115670 8050.72
 ns.mipt.ru      193.125.143.140  3 u   19   64  377    5.732  1115532 8078.07
 94.26.135.117   131.188.3.221    2 u   29   64  377   10.960  1115253 7990.69
 wooster.rojer.p 193.124.11.11    3 u    7   64  377    3.379  1115869 8081.91

...

За ночь часы отстали на 18 минут. У меня сейчас 11:02 :)

А совсем отключать ntpd не пробовали?
Емнип, driftfile характеризует погрешность системных часов с точки зрения ntpd. Обычно это десятки. А раз ноль... возможно, просто ntpd с ума сошел.
Вообще-то он должен примерно через час создаваться, после тщательной оценки этой погрешности.

Пробелы в remote потерялись, что-ли? Там, вроде, первый символ означал как ваш ntpd относится к удаленному. Если пробел, то он его reject, а разн нет '+' и '*', значит ntpd не пытается сихронизироваться. Наверное, в логах ntpd ругается про слишком большой дрейф системных часов.

>А совсем отключать ntpd не пробовали?

Попробовал. Пофиг, всё равно отстают.

>Пробелы в remote потерялись, что-ли?

Угу. Походу, code-тэг жрёт их.

>Наверное, в логах ntpd ругается про слишком большой дрейф системных часов.

Запустил (несколько часов было вырублено). Вот весь выхлоп:

Sep 27 20:34:45 [ntpd] ntpd 4.2.4p7@1.1607-o ._._к ._._н 21 14:05:49 UTC 2009 (1)
Sep 27 20:34:45 [ntpd] precision = 1.000 usec
Sep 27 20:34:45 [ntpd] Listening on interface #0 wildcard, 0.0.0.0#123 Disabled
Sep 27 20:34:45 [ntpd] Listening on interface #1 lo, 127.0.0.1#123 Enabled
Sep 27 20:34:45 [ntpd] Listening on interface #2 br0, 192.168.1.3#123 Enabled
Sep 27 20:34:45 [ntpd] kernel time sync status 0040
Sep 27 20:34:48 [ntpd] frequency initialized 0.000 PPM from /var/lib/ntp/ntp.drift

Походу, неправильно прописана TIME_ZONE. А демон синхронизации подводит часы под неправильную зону.

>Походу, неправильно прописана TIME_ZONE

Europe/Moscow. Симлинк на системный файл.

>А демон синхронизации подводит часы под неправильную зону.

Отставание принимает произвольные значения от 0 до полутора часов (максимум, до которого запускал машину)

Такая же хрень была под арчем, вылечилось установкой USEDIRECTISA=«yes» в инитах, чипсет нфорс.

У меня всё хитрее. С пол-дюжины Gentoo-машин, с совершенно идентичными настройками (времени). На всех всё ок, даже если аппаратные и софтерные часы ОЧЕНЬ сильно рассинхронизированы. А тут - фигня какая-то... При чём вылезла недавно, после смены железа (настройки системы старые оставались).

Обновить BIOS и сделать загрузку default-настроек BIOS Setup — для начала.

>Обновить BIOS

Стоит самый последний для этой матери. Не обновлялся больше, где-то, с 2006-го :)

>и сделать загрузку default-настроек BIOS Setup — для начала.

Делалось когда боролся с http://www.linux.org.ru/view-message.jsp?msgid=3972283 - т.е. месяц назад.

...

В любом случае, настройки BIOS никак не влияют ни на RTC, ни на системный таймер :)

а текущее время ты как определяешь - через date?

>а текущее время ты как определяешь - через date?

date и hwclock --show

...

ИТИТЬ-КОЛОТИТЬ!!!11одинадын

Сейчас у меня hwclock --show показывает _правильное_ время :)

$ date && sudo hwclock --show
Вск Сен 27 23:34:30 MSD 2009
Вск 27 Сен 2009 23:47:04 -0.098217 секунд

А может быть у Вас в биосе засыпание настроено? А то если комп засыпает-просыпается, то он вроде подстраивает время по хардварным часам. Тут может быть всякая черезжопица.

>А может быть у Вас в биосе засыпание настроено?

Не-а. Комп, вообще, 24/7/365 работает. Домашний серверок.

...

Дальше - веселее. Минут 5 назад я запускаю hwclock --sync, чтобы проверить обстановку и вижу, что время там опять системное. Ну, думаю, собака, засинхронизировался! Смотрю на соседнюю машину... опаньки! Там то же самое время.

Походу, сейчас время на моей машине правильное. То ли починилось, то ли засинкалось ... хотя синхронизация по cron'у у меня в 3:17 только запускается.

Странно, в общем :)

Cинхронизация чего с чем по cron'у в 3:17 ?

ntpdate -s ntp.cs.strath.ac.uk

...

А так - опять сейчас и системные часы, и RTC отстают на 12 минут.

С какого источника берутся отсчёты времени?

Например, на FreeBSD есть три источника:
sysctl kern.timecounter
...
kern.timecounter.choice: TSC(-100) ACPI-fast(1000) i8254(0) dummy(-1000000)

Системой выбирается этот:
kern.timecounter.hardware: ACPI-fast
Источник аппаратных часов TSC неправильно работает на многих SMP-системах.

Вроде, запускать ntpdate по крону это неправильно, это сбивает ntpd и мешает вычислять ему дрейф. Вроде достаточно запускать ntpdate при загрузке системы и всё, а дальше должен работать только ntpd.

Хотя в вашем случае я не знаю. Может вам каждую минуту вызывать ntpdate. А может у вас какой демон шибко умный, и время переводит и синхронизирует системные часы с аппаратными. Кстати, hwclock --show --directisa тоже выводит неправильное время?