Существует ли существующий механизм, который синхронизирует систему Linux с NTP в режиме онлайн и с предсказуемо дрейфующим RTC в автономном режиме?
Мы работаем с удаленными «сборщиками»: встроенными системами Linux, которые собирают данные о датчиках и метки времени. Нам нужно, чтобы их ошибки часов оставались достаточно малыми, скажем, ниже 5 секунд. Обычно мы используем NTP для синхронизации их часов, и это прекрасно работает, пока система работает.
Проблема в том, что у некоторых коллекционеров очень плохие ссылки, которые могут отключаться часами, днями или даже неделями. Это не останавливает локальный сбор данных, но без NTP системные часы Linux плохо и совершенно непредсказуемо.
OTOH, аппаратный RTC тоже дрейфует сильно, но с постоянной скоростью. Скорость дрейфа RTC варьируется от платы к плате, но постоянна для каждой платы и может быть измерена.
Я думаю, что нам нужен механизм, который делает следующее:
- Измерьте скорость дрейфа RTC платы перед ее развертыванием
- Отрегулируйте системное время, продолжающееся / регулярно через NTP, когда это возможно
- Регулярно настраивайте системное время с RTC, когда NTP недоступен. Принять во внимание известную скорость дрейфа RTC.
- Необязательно: Измерьте и запишите скорость дрейфа RTC, находящуюся в режиме онлайн (1)
Под «механизмом» я подразумеваю некоторое хорошо поддерживаемое, документированное программное обеспечение и / или конфигурацию, которая может обрабатывать два состояния «онлайн» и «автономно», гарантируя, что системные часы синхронизированы с правильным источником времени (ntp против RTC), обнаружить изменение состояния и исправить дрейф RTC. Не имеет большого значения, реализован ли он как специальный конфигурационный / плагин ntpd, как отдельный демон, как задание cron или как-то еще.
Я взглянул на Chrony , но согласно его документации он пытается предсказать смещение системных часов , которое в нашем случае дрейфует гораздо более непредсказуемо, чем RTC. Похоже, что Chrony использует RTC только для того, чтобы время перезагружалось.
(1) Обратите внимание, что ntpd активирует «11-минутный режим» ядра (обновляйте rtc из системных часов каждые 11 минут). Похоже, с текущими ядрами и ntpd нет способов предотвратить 11-минутный режим. Поэтому любая информация о дрейфе RTC теряется во время работы ntpd (thx @billthor).
Обновления / изменения:
- Мы планируем добавить внешние радиочасы для сигнала MSF или DCF77 (мы находимся в Европе) через USB или последовательный порт. Но мы предпочитаем экономить аппаратное обеспечение.
- Наши коллекционеры находятся в помещении, часто в подвале. Поэтому добавление GPS-часов не поможет.
- Мы используем Debian 7. Это означает hwclock из util-linux-2.20.1, ntpdate-4.2.6p5, ntpd из ntp-4.2.6.p5, chrony-1.24 (потенциально 1.30).
- Обратите внимание , что наша проблема заключается не в том , что мы не знаем , как использовать
ntpdate(8)
,hwclock(8)
,date(1)
и т.д. Пожалуйста , смотрите раздел добавлены в курсиве о том, что я имею в виду с «механизмом». - Добавлена сноска о режиме «11 минут»
- Вот очень интересное обсуждение офлайн-синхронизации и дрейфа RTC