Синхронизировать часы с NTP в режиме онлайн и с RTC в автономном режиме?

Существует ли существующий механизм, который синхронизирует систему 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

Ваша ситуация необычна, и я был бы удивлен, если бы кто-нибудь придумал стандартную ntpdконфигурацию, чтобы делать то, что вы хотите. Тем не менее, мне нравится быть удивленным, и это случается довольно часто вокруг этих частей.

Но до тех пор, пока кто-то не придумает лучшую идею, вы рассматривали такую crontabзапись?

*/5 * * * *   ntpdate 0.pool.ntp.org || ( hwclock --adjust; hwclock --hctosys )

IE, каждые пять минут пытайтесь синхронизировать часы с помощью ntpdate, и если (и только если), что не удается, отрегулируйте аппаратные часы для дрейфа в соответствии с /etc/adjtimeфайлом (формат которого подробно описан man hwclock, и чью первую строку вы заполнили соответствующим образом, используя ваши знания этой конкретной RTC скорости), затем установите системные часы от RTC.

Обратите внимание, что если вы выбираете подобное решение и развертываете какое-то значительное количество этих систем, считается вежливым работать с пулом и возвращать серверы обратно пропорционально вашему использованию. Вы можете найти больше информации на http://www.pool.ntp.org/en/vendors.html .

NTP уже имеет механизмы, позволяющие узнать, подключен он или нет, и при необходимости переключится на источники с более низким приоритетом. Очень легко проверить значение досягаемости для запуска альтернативного источника, но я бы придерживался NTP. Как обсуждается ниже, мониторинг и исправление дрейфа RTC, вероятно, будет затруднено.

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

Есть известные проблемы с местными часами, которые не относятся к RTC. Некоторые из проблем описаны в списке известных проблем с ОС NTP . Это может объяснить ваш дрейф часов. Решение их может решить вашу проблему. В отсутствие пропущенных тиков я обнаружил, что местный (системный) источник времени может быть очень стабильным.

Вы можете использовать драйвер Dumb Clock (33) с программой, которая записывает соответствующее время RTC на устройство / dev / dumbclockX.

Есть ряд других драйверов, основанных на радиочасах. Некоторые из них используют коротковолновые сервисы, такие как WWV и CHU, которые могут работать в средах, где сигналы GPS недоступны. Для Европы этот список будет включать BBC, TDF, RBU и RMW.

Павел Крейци также написал драйвер RTC, но, похоже, он не включен в официальные драйверы. Это может работать с синхронизацией типа PPS.

Должна быть возможность измерять дрейф RTC до развертывания. Однако вам необходимо убедиться, что RTC не обновляется автоматически. Когда системные часы обновляются с помощью функции adjtimex, RTC может обновляться каждые 11 минут.

NTP обновит часы при подключении. Обычно NTP отказывается делать большие настройки системных часов. Существуют варианты настройки того, насколько далеко можно настроить часы.

Я предложил варианты использования RTC выше. Радиочасы могут быть более подходящими, чем часы GPS.

Измерение дрейфа при отсутствии надежного источника времени для его сравнения, вероятно, бесполезное усилие. Если местное время нестабильно, вы не можете использовать его для мониторинга RTC и наоборот. Измерение дрейфа при подключенном NTP не будет работать, если ядро ​​обновляет RTC каждые 11 минут. RTC, которые я использовал, имеют разрешение в одну секунду, поэтому они должны значительно отклоняться, чтобы быть надежно измеримыми.