Неделю назад синхронизировал контроллер WirenBoard 6 по ntp, затем командой hwclock --systohc --localtime задал аппаратное время по системному, все было синхронно. Контроллер включался/выключался и должен был брать системное время по rtc. Сейчас системное время отстает от сервера на 111сек.
Откуда такая погрешность? Возможно что-то нужно донастроить?
Добрый день, freemanon.
Хочется понять, какие команды синхронизации у вас выполняются и когда.
Запущен ли ntpd?
Можете показать вывод
hwclock --adjust --test --debug
root@wirenboard-A2A6LMHH:~# hwclock --adjust --test --debug
hwclock from util-linux 2.29.2
Using the /dev interface to the clock.
Last drift adjustment done at 1568870928 seconds after 1969
Last calibration done at 1568870928 seconds after 1969
Hardware clock is on local time
Assuming hardware clock is kept in local time.
Waiting for clock tick…
/dev/rtc does not have interrupt functions. Waiting in loop for time from /dev/r tc to change
…got clock tick
Time read from Hardware Clock: 2019/10/01 15:19:27
Hw clock time : 2019/10/01 15:19:27 = 1569932367 seconds since 1969
Time since last adjustment is 1061439 seconds
Calculated Hardware Clock drift is 0.000000 seconds
Needed adjustment is less than one second, so not setting clock.
root@wirenboard-A2A6LMHH:~#
ntpd запущен но у него нет доступа к серверам времени.
Точность RTC на контроллере похоже, действительно, не очень высокая и использовать RTC в качестве референтного источника времени не следует.
Если вы не используете ntpd, то лучше отключите этот сервис совсем.
Если доступ к сети есть, то можно периодически обновлять время с какого-то известного сервера.
Нашел статью про калибровку времени без ntpd, возможно, она вам поможет:
http://support.ntp.org/bin/view/Support/ManualCalibration
Ошибка аппаратных часов в контроллере (WB6 все, WB5 старше rev 5.9) - где-то 10 минут в год, как у обычных кварцевых часов. Если вы видите ошибку больше - это баг.
Ещё надо учитывать, что в WB6 два RTC: встроенный в процессор и внешний. Встроенный нужен, чтобы сохранять время при перезагрузках контроллера. Внешний имеет отдельную часовую батарейку и тикает даже в выключенном контроллере.
Посмотреть какой где можно в выводе dmesg | grep rtc например. Ну и по-умолчанию всё должно работать само: контроллер подтягивает системное время из аппаратного rtc при старте и сохраняет при программном выключении питания.
Ок, это баг, и что делать?
В любом случае 10мин в год это слишком много. Если нет выхода в интернет, то необходим GPS-модуль?
root@wirenboard-A2A6LMHH:~# dmesg | grep rtc
[ 0.133043] i2c-gpio i2c_rtc: using pins 48 (SDA) and 49 (SCL)
[ 1.355658] rtc rtc0: invalid alarm value: 2019-11-2 30:7:0
[ 1.361864] rtc-pcf8563 4-0051: rtc core: registered rtc-pcf8563 as rtc0
[ 1.378033] snvs_rtc 20cc000.snvs:snvs-rtc-lp: rtc core: registered 20cc000.s nvs:snvs-r as rtc1
[ 1.783124] rtc-pcf8563 4-0051: setting system clock to 2019-10-07 07:51:37 U TC (1570434697)
Строка “invalid alarm value” немного напрягает.
ну это реальность, такая точность часов почти во всём оборудовании. Меньше дают только термокомпенсированные RTC, но они существенно дороже и точность у них лучше всего в несколько раз.
Да, можно попробовать брать с время с GPS.
Сначала попробовать воспроизвести.
Через hwclock с указанием устройства (rtc0) записать время, подождать определённое время (сутки например), считать время с rtc0. Прислать результаты сюда.
Вчера:
root@wirenboard-A2A6LMHH:~# ntpdate 192.168.1.140
9 Oct 09:02:30 ntpdate[4744]: adjust time server 192.168.1.140 offset -0.000494 sec
root@wirenboard-A2A6LMHH:~# hwclock --systohc --localtime --rtc /dev/rtc0
root@wirenboard-A2A6LMHH:~# ntpdate -q 192.168.1.140
server 192.168.1.140, stratum 6, offset 0.000518, delay 0.04295
9 Oct 09:02:48 ntpdate[4747]: adjust time server 192.168.1.140 offset 0.000518 sec
Сегодня:
root@wirenboard-A2A6LMHH:~# ntpdate -q 192.168.1.140
server 192.168.1.140, stratum 6, offset 14.908030, delay 0.04265
10 Oct 08:48:02 ntpdate[8116]: step time server 192.168.1.140 offset 14.908030 sec
Итого время ушло за день на 14сек, это даже больше чем у меня получалось раньше.
root@wirenboard-A2A6LMHH:~# ntpdate -q 192.168.1.140
server 192.168.1.140, stratum 6, offset 291.316953, delay 0.04201
28 Oct 10:12:52 ntpdate[12643]: step time server 192.168.1.140 offset 291.316953 sec
Уже на 5 минут ушло за 20 дней. Есть решение?
Прошу прощения за задержку. Попробуйте пожалуйста сделать
systemctl disable wb-gsm-rtc
перезагрузиться, потом повторить эксперимент в течение 1 дня.
Эксперимент прошу сделать так:
-
выполнить
hwclock -f /dev/rtc0 -r && date --rfc-3339=ns && ntpdate -q 192.168.1.140 -
подождать сутки
-
выполнить то же самое
больше ничего не делать с временем, в т.ч. не записывать время в RTC и не трогать системное
Ещё: а вы на 100% уверены в том, что беда не в NTP сервере? Судя по stratum 6, это какой-то самодельный сервер. Может с ним что-то не так?
root@wirenboard-A2A6LMHH:~# ntpdate -q 88.147.254.227
server 88.147.254.227, stratum 1, offset 337.494589, delay 0.37976
31 Oct 08:31:07 ntpdate[7074]: step time server 88.147.254.227 offset 337.494589 sec
root@wirenboard-A2A6LMHH:~# ntpdate -q 192.168.1.140
server 192.168.1.140, stratum 6, offset 337.391669, delay 0.04285
31 Oct 08:31:53 ntpdate[7151]: step time server 192.168.1.140 offset 337.391669 sec
Все так. Но проведу эксперимент со stratum 1.
root@wirenboard-A2A6LMHH:~# systemctl disable wb-gsm-rtc
wb-gsm-rtc.service is not a native service, redirecting to systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install disable wb-gsm-rtc
root@wirenboard-A2A6LMHH:~# reboot
root@wirenboard-A2A6LMHH:~# hwclock -f /dev/rtc0 -r && date --rfc-3339=ns && ntpdate -q 88.147.254.227
2019-11-07 08:38:08.471492+0300
2019-11-07 08:38:08.905904098+03:00
server 88.147.254.227, stratum 1, offset 444.576259, delay 0.43254
7 Nov 08:38:17 ntpdate[4742]: step time server 88.147.254.227 offset 444.576259 sec
Спустя сутки:
root@wirenboard-A2A6LMHH:~# hwclock -f /dev/rtc0 -r && date --rfc-3339=ns && ntpdate -q 88.147.254.227
2019-11-08 07:47:49.444364+0300
2019-11-08 07:47:55.331329053+03:00
server 88.147.254.227, stratum 1, offset 454.532593, delay 0.37924
8 Nov 07:48:03 ntpdate[17991]: step time server 88.147.254.227 offset 454.532593 sec```какая-то ерунда. Получается, что системное время за сутки отстало на 10 секунд, а время внутри RTC - на шесть. Т.е. два независимых модуля часов с разными тактовыми генераторами и разными источниками питания одновремено отстают.
Это наводит меня на мысль о том, что дело тут в софте: что-то трогает время. gpsd, ntp, какие-то ваши скрипты или сторонние программы?
Идеально было бы провести эксперимент после полного сброса к заводской прошивке с потерей всех пользовательских данных.
Могу сбросить.
В инструкции Обновление прошивки#Сброс Wiren Board 6 к заводским настройкам указано “1. Файл на USB-накопителе нужно назвать wb6_update_FACTORYRESET.fit”, но не указано где взять исходный файл с прошивкой. Или нужно скачать последнюю версию и обновить как описано в предыдущем разделе?
Да, нужно скачать последнюю прошивку (файл .fit) , как написанно в предыдущем разделе и переименновать её.