странности со временем на часах %)

[gaux]

Может в release такого нет. Сейчас у меня FreeBSD 6.3 RC2 - качаю release. По сети не настраивал и не хочу. Не должно оно работать только так. Время из биоса берется. Почему то не корректно устанавливается после запуска - мне так запомнилось. Было даже, что дата не меналась. Так и висело - суббота в понедельник - в биосе все корректно настроено. Чудно. И секунды бегут. У меня такое было с линухом 32битным, но там решилось обновлением биоса. Было у кого-нибудь что-нибудь подобное?

[Shura]

Вообще ничего не понял...

[gaux]

У меня время на часах во фре отсчитывается не правильно - быстрее чем положено. И дата неверно выставляется. Хотя кажется доку нашел. Такое чувство, что используется не тот таймер. Уж больно симптомы совпадают.

Под линухом такое было в 32 битных дистрах, но вылечилось перепрошивкой биоса.

Есть вариант обновления времени по сети в соответсвии с атомными часами, но все же хотелось бы, чтобы и то, что берется из биоса было корректно потому, что иногда сеть не доступна и трафик тратить на это не хочу.

[gaux]

Точно. Нашел в troubleshooting:)

# sysctl kern.timecounter.hardware
kern.timecounter.hardware: ACPI-fast

Почему часы на моем лэптопе показывают неправильное время?

В вашем лэптопе установлены двое или большее количество таймеров, а FreeBSD выбрала не тот.

Запустите dmesg(8) и посмотрите строки, содержащие слово Timecounter. В последней из них указан таймер, выбранный системой, и, скорее всего, это будет TSC.

# dmesg | grep Timecounter
Timecounter "i8254" frequency 1193182 Hz
Timecounter "TSC" frequency 595573479 Hz

Вы можете удостовериться в этом, проверив sysctl(3)-переменную kern.timecounter.hardware.

# sysctl kern.timecounter.hardware
kern.timecounter.hardware: TSC

BIOS может изменить частоту TSC--может, для изменения скорости работы процессора при работе от батареек или переводя в режим пониженного электропитания, но FreeBSD не отслеживает это и в результате часы начинают спешить или отставать.

В этом примере имеется также и таймер i8254, и он может быть выбран записью его имени в sysctl(3)-переменную kern.timecounter.hardware.

# sysctl -w kern.timecounter.hardware=i8254
kern.timecounter.hardware: TSC -> i8254

Теперь ваш лэптоп будет аккуратнее следить за временем.

Чтобы это изменение вступало в силу во время загрузки системы, добавьте в файл /etc/sysctl.conf такую строчку.

kern.timecounter.hardware=i8254

Ах тыж. Так настроили разработчики DBSD.

# Better time counters, especially for laptops (honors power saving modes)
kern.timecounter.hardware=i8254
kern.timecounter.hardware=ACPI-fast # If available

[gaux]

Вот этого никак найти не могу. Вчера выключил комп примерно в 23.30. Включаю с утра в 8.05. На часах все те же четверг 23.30. Что за ерунда? Почему время из CMOS не читается? Такая мелочь, не вводить же каждый день его вручную %) ЗЫ Обновление времени по сети не предлагать. Не должно это работать только так. Использую фрю как дестоп и мне нравится, но есть мелочи, которые нужно подкрутить.

Теперь хоть часы не спешат

[gaux]

Разобрался - подхватывается ACPI-fast в любом случае при загрузке. Потом меняю на i8254, но часы уже отмотаны на несколько часов назад. Буду разбираться как настроить на нужный таймер.

[daloman]

ЗЫ Обновление времени по сети не предлагать. Не должно это работать только так. Использую фрю как дестоп и мне нравится...

И все-таки рискну предложить как возможный вариант использовать "ntpdate" или "ntpd -q", тем более на десктопе.

Так у Вас чего в итоге кажет

Код: Выделить всё

$ sysctl -a | grep kern.timecounter.hardware

[gaux]

Во время загрузки вижу, что таймер ACPI-fast заменяется на i8254. Потом то все как надо отсчитывается. Лишнюю строку убрал из /etc/sysctl.conf. Только во время загрузки еще до этой явной замены время не от туда дергается. Может это и настраивается, но пока не успел разобраться. Вижу как мелькает строчка: ACPI-fast -> i8254.

По сети не подходит потому, что линия и без того медленная - 155 Кбит/с. Безлимитка - много скачиваю Полоса узкая.

И кроме того велико желание разобраться почему

[daloman]

Только во время загрузки еще до этой явной замены время не от туда дергается.

Вот, собственно, нагуглил...

During boot, the kernel probes several time counters and assigns "quality" values. Typically you have three of them (i8254, ACPI, TPC). The time counter with the highest quality value will be used for timing by default, but you can change it via sysctl if you know what you are doing. Type "sysctl kern.timecounter" and see the result.
> Can anyone explain me the "mystics" behind Hz quality,
> and why or how this quality is computed and what are the
> efforts?
The reason for that is to have a time counter that is as precise and reliable as possible. For example, TPC has issues on SMP and power-managed machines, therefore it is not as reliable as ACPI, so usually the ACPI timecounter has higher quality (although it takes more clock cycles to query it).

Oh, there's also a timecounter called "dummy", which does not count time at all. :-) It exists for debugging purposes only, AFAIK, and has a negative quality value, so it is never selected automatically.

Как я понял, при загрузке, ядро определяет счетчики и "выставляет" им рейтинг в зависимости от их надежности. ACPI-счетчик по-умолчанию ядро считает самым надежным.

Может это и настраивается, но пока не успел разобраться.

Настраивается, именно в sysctl.conf, как и многие другие параметры системы.
Опять же, как я понял из прочитанного, можно и более радикально настроить - переписать в исходниках ядра

> are those quality values preset (i.e. TSC = 800) or are they computed
> (during boot) somehow? and if the latter, how pls??
They have hardcoded defaults, but some of them are adjusted under certain circumstances. For example, the TSC's default value of 800 is reduced on an SMP-enabled or APM-enabled system.
You should be able to look it up in the source code easily yourself. Look for struct timecounter.

По сети не подходит потому, что линия и без того медленная - 155 Кбит/с. Безлимитка - много скачиваю Полоса узкая.

Ну так я потому и предложил ntpdate или ntpd с параметром -q. Первый синхронизирует время при загрузке, второй - синхронизирует его только один раз и после первой синхронизации останавливается.
Думаю, десяток udp пакетов за один uptime не забъют весь канал

[gaux]

>Настраивается, именно в sysctl.conf, как и многие другие параметры системы.

Об этом уже прочел.

>Опять же, как я понял из прочитанного, можно и более радикально настроить - переписать в исходниках ядра

Видать придеться туда таки лезть в ядро Может ACPI таймер и качественне, но на моей машине они не синхронизированы. И после загрузки время каждый раз отматывается назад. Фик его знает как этот таймер устаналивается и что отсчитывает, но так он работает.

>Ну так я потому и предложил ntpdate или ntpd с параметром -q. Первый синхронизирует время при загрузке, второй - синхронизирует его только один раз и после первой синхронизации останавливается.

Как этот демон работает не знал. Не посмотрел потому, что сеть не всегда доступна. Уж такой пров, у меня от него еще и телефон. Больно уж дорого менять - акция была, 30% от стоимости и модем в аренду. Поэтому иногда придется таки его подкручивать в ручную

[izen.fire]

Вот этого никак найти не могу. Вчера выключил комп примерно в 23.30. Включаю с утра в 8.05. На часах все те же четверг 23.30. Что за ерунда?

Вариант 1.
Может у вас на системной плате батарейка разрядилась и не работает таймер после выключения компа?

Вариант 2.
При установке FreeBSD в Sysinstall задаётся вопрос о том, работают ли ваши часы на компьютере по Всемирному времени "UTC" или же на них местное время (лично я отвечаю, что на часах компьютера не UTC — нажимаю кнопку по умолчанию). Может вы ошиблись и подтвердили отсчёт времени по международному стандарту GMT UTC без учёта поясного времени?

[gaux]

>Вариант 1.
>Вариант 2.

Нет. Даже несколько раз проверил - не едет ли у меня крыша%)

Единственно сборка DesktopBSD на FreeBSD 6.3 RC2. Или все таки лучше перейти на FreeBSD 7.0 RC1 - пока еще скачивается. Потому и не спешил с обновлением.

Не думаю, что в этом может быть дело.

Мне кажется, что в любом счете оно должно отсчитываться. Даже, когда задействовано UTC. Пусть не корректно, но не отматываться каждый раз при включении назад. Перезагрузка: отмоталось, еще одна перезагрузка: еще отмоталось.