Есть ли существующий механизм, который синхронизирует систему Linux с NTP в режиме онлайн и с предсказуемо дрейфующим RTC в автономном режиме?
Мы работаем с удаленными «сборщиками»: встроенными системами Linux, которые собирают данные датчиков и ставят им отметки времени. Нам нужно, чтобы их погрешности часов оставались достаточно небольшими, скажем, менее 5 секунд. Обычно мы используем NTP для синхронизации их часов, и это отлично работает - пока система подключена к сети.
Проблема в том, что у некоторых коллекционеров очень плохие исходящие каналы, которые могут отключаться на часы, дни или даже недели. Это не останавливает локальный сбор данных, но без NTP системные часы Linux дрейфуют плохо и совершенно непредсказуемо.
OTOH, RTC оборудования тоже сильно дрейфует, но с постоянной скоростью. Скорость дрейфа RTC варьируется от платы к плате, но постоянна для каждой платы и может быть измерена.
Думаю, нам нужен механизм, который выполняет следующие действия:
Под «механизмом» я подразумеваю некоторую хорошо поддерживаемую, документированную часть программного обеспечения и / или конфигурации, которая может обрабатывать два состояния «онлайн» и «офлайн», обеспечивая синхронизацию системных часов с правильным источником времени (ntp vs. rtc), обнаружить изменение состояния и скорректировать дрейф RTC. Не имеет большого значения, реализован ли он как специальная конфигурация / плагин ntpd, как отдельный демон, как задание cron или иначе.
Я смотрел на Хрони, но согласно его документация он пытается предсказать смещение системные часы, который в нашем случае дрейфует гораздо более непредсказуемо, чем RTC. Похоже, что Chrony использует RTC только для того, чтобы отслеживать время перезагрузки.
(1) Обратите внимание, что ntpd активирует 11-минутный режим ядра (обновлять rtc по системным часам каждые 11 минут). Кажется, что с текущими ядрами и ntpd нет способов предотвратить 11-минутный режим. Следовательно, любая информация о дрейфе rtc теряется во время работы ntpd (thx @billthor).
Обновления / правки:
ntpdate(8), hwclock(8), date(1)и т. д. См. добавленный раздел в курсив о том, что я имею в виду под «механизмом».Ваша ситуация необычна, и я был бы удивлен, если бы кто-нибудь придумал стандартную 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.conf
server 127.127.1.1 iburst
fudge 127.127.1.1 stratum 8
сервер 127.127.1.1 - это псевдочасы, также известные как локальный RTC. iburst для быстрой синхронизации с ним (или нет). fudge stratum 8 изменяет его со значения по умолчанию 3 на более высокое число. Должен быть выше, чем у других ваших серверов.
Это заставит ntpd использовать локальные часы в качестве источника синхронизации при потере связи с серверами нижнего уровня и вернуться к ним при восстановлении связи.
У NTP уже есть механизмы, чтобы узнать, находится ли он в сети или в автономном режиме, и при необходимости он переключится на источники с более низким приоритетом. Очень легко проверить значение охвата для запуска альтернативного источника, но я бы предпочел NTP. Как обсуждается ниже, мониторинг и корректировка дрейфа RTC, вероятно, будут трудными.
В те времена, когда еще не было Интернета, я использовал программу, которая звонила на источник данных и синхронизировала часы. По-прежнему могут быть доступны службы, которые предоставляют источник времени через модем. Для этого потребуется доступ к телефонной линии.
Существуют известные проблемы с местными часами, которые не относятся к RTC. Некоторые проблемы задокументированы в списке Известные проблемы с ОС NTP. Это может объяснить отклонение часов. Их решение может решить вашу проблему. Я обнаружил, что при отсутствии пропущенных тиков локальный (системный) источник времени может быть очень стабильным.
Вы можете использовать драйвер Dumb clock (33) с программой, которая записывает соответствующее время RTC на устройство / dev / dumbclockX.
Существует ряд других драйверов, основанных на часах Radio. Некоторые из них используют коротковолновые службы, такие как WWV и CHU, которые могут работать в средах, где недоступны сигналы GPS. Для Европы этот список будет включать BBC, TDF, RBU и RMW.
Павел Крейчи также написал драйвер RTC, но, похоже, он не включен в официальные драйверы. Это может работать с синхронизацией типа PPS.
Перед развертыванием должна быть возможность измерить смещение RTC. Однако вам необходимо убедиться, что RTC не обновляется автоматически. Когда системные часы обновляются с помощью функции adjtimex, часы реального времени могут обновляться каждые 11 минут.
NTP обновит часы при подключении. Обычно NTP отказывается вносить большие изменения в системные часы. Есть варианты, чтобы отрегулировать, насколько можно отрегулировать часы.
Варианты использования RTC я предложил выше. Радиочасы могут быть более подходящими, чем часы GPS.
Измерение дрейфа при отсутствии надежного источника времени для его сравнения, вероятно, бесполезно. Если местное время нестабильно, вы не можете использовать его для отслеживания RTC, и наоборот. Измерение дрейфа при подключенном NTP не будет работать, если ядро обновляет RTC каждые 11 минут. Используемые мной часы реального времени имеют разрешение в одну секунду, поэтому для надежного измерения им придется значительно дрейфовать.