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


11

Существует ли существующий механизм, который синхронизирует систему 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 и hwclock уже позволяет вам делать все эти вещи.
Рой

@ Рой Конечно. Вопрос в том, как согласованно объединить ntp (d) и RTC (hwclock) для достижения максимальной точности?
Нильс Тёдтманн

Я понимаю, что системные часы дрейфуют больше, чем RTC. Мне любопытно, что вы сочли неприемлемым в отношении способа / эффективности хронического управления дрейфом системы? Как хроника потерпела неудачу для вас?
сентября

@dfc хроника не подвела нас. Мы еще не пробовали, потому что, кажется, он не использует RTC для сохранения времени в автономных периодах, что, я думаю, повысило бы точность в нашем случае использования. Мы проверим хронологию, если не будут предложены другие более перспективные методы.
Нильс Тёдтманн

Я думаю, что вы должны смотреть в хронику. С уважением кажется, что вы отказываетесь от хорошего варианта, основанного на догадке. На мой взгляд, расследовать хронику не стоит, если RTC-ntpd не найден. Кажется , что проще всего увидеть , если Chrony отвечает вашим потребностям , и если нет , то идти по этому кроличью нору
DFC

Ответы:


4

Ваша ситуация необычна, и я был бы удивлен, если бы кто-нибудь придумал стандартную 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 .


Вы прибили основную идею :-) Но это не считается ответом (пока), поскольку не учитывает (постоянный, но значительный) дрейф RTC. Можем ли мы улучшить это, например, используя /etc/adjtimeи hwclock --adjust?
Нильс Тёдтманн

Да; смотри выше.
MadHatter

Такое решение я имел в виду, когда писал свой предыдущий комментарий. Также, если системные часы в настоящее время синхронизируются через ntpd, вы можете использовать hwclock для измерения и установки довольно точной скорости дрейфа для RTC.
Рой

К сожалению, нет, см. Комментарии о ntpd & '11-минутном режиме '
Nils Toedtmann

-1

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, которые я использовал, имеют разрешение в одну секунду, поэтому они должны значительно отклоняться, чтобы быть надежно измеримыми.


Я не понимаю, как это связано с моим вопросом. Я не думаю, что моя проблема в нехватке драйверов ... или это?
Нильс Тёдтманн

@ NilsToedtmann Насколько я могу найти, нет официального драйвера для RTC. Я считаю, что localдрайвер просто использует часы сервера, которые вы сообщаете о дрейфах. Я обновлю свой ответ.
BillThor

Когда вы говорите «драйверы», вы имеете в виду драйверы ядра Linux (которых достаточно) или функции ntpd? Спасибо за ваши советы, некоторые из них интересны - хотя я думаю, что они должны были быть размещены скорее как комментарии. Спасибо за упоминание «11 минут больше», я забыл об этом. Я обновил свой вопрос.
Нильс Тёдтманн

@ NilsToedtmann Нет, я имею в виду драйверы часов NTP. По моему опыту, RTC обычно дрейфуют, но не с высокой скоростью, если тесто хорошее. Пропущенные галочки могут быть проблемой с системными часами.
BillThor
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.