Синхронизировать часы с 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
2 ответа
Ваша ситуация необычна, и я бы удивился, если бы кто-нибудь придумал стандарт ntpdна основе конфигурации, чтобы делать то, что вы хотите. Тем не менее, мне нравится быть удивленным, и это случается довольно часто вокруг этих частей.
Но пока кто-то не придумает лучшей идеи crontab запись как это?
*/5 * * * * ntpdate 0.pool.ntp.org || ( hwclock --adjust; hwclock --hctosys )
То есть каждые пять минут пытаться синхронизировать часы через 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.
Есть ряд других драйверов, основанных на радиочасах. Некоторые из них используют коротковолновые сервисы, такие как WWV и CHU, которые могут работать в средах, где сигналы GPS недоступны. Для Европы этот список будет включать BBC, TDF, RBU и RMW.
Павел Крейци также написал драйвер RTC, но, похоже, он не включен в официальные драйверы. Это может работать с синхронизацией типа PPS.
Должна быть возможность измерять дрейф RTC до развертывания. Однако вам необходимо убедиться, что RTC не обновляется автоматически. Когда системные часы обновляются с помощью функции adjtimex, RTC может обновляться каждые 11 минут.
NTP обновит часы при подключении. Обычно NTP откажется от больших настроек системных часов. Существуют варианты настройки того, насколько далеко можно настроить часы.
Я предложил варианты использования RTC выше. Радиочасы могут быть более подходящими, чем часы GPS.
Измерение дрейфа при отсутствии надежного источника времени для его сравнения, вероятно, бесполезно. Если местное время нестабильно, вы не можете использовать его для мониторинга RTC и наоборот. Измерение дрейфа при подключенном NTP не будет работать, если ядро обновляет RTC каждые 11 минут. RTC, которые я использовал, имеют разрешение в одну секунду, поэтому они должны значительно отклоняться, чтобы быть надежно измеримыми.