Синхронізувати годинник з NTP під час роботи в Інтернеті та з RTC в режимі офлайн?

Чи існує механізм, який синхронізує систему Linux з NTP під час роботи в Інтернеті та з передбачуваним дрейфом RTC під час роботи в режимі офлайн?

Ми управляємо віддаленими "колекторами": вбудованими системами Linux, які збирають і датують датчики часових позначок. Нам потрібні помилки годинника, щоб вони залишалися досить маленькими, скажімо, нижче 5 секунд. Зазвичай ми використовуємо NTP для синхронізації їхніх годин, і це працює чудово - доки система не працює в Інтернеті.

Проблема полягає в тому, що деякі колектори мають дуже погані посилання, які можуть спускатися годинами, днями і навіть тижнями. Це не зупиняє локальний збір даних, але без NTP, системний годинник Linux рухається погано і зовсім непередбачувано.

Щодо іншого, RTC апаратних засобів також сильно рухається, але з постійною швидкістю. Швидкість дрейфу RTC змінюється від дошки до борту, але є постійною на борт і може бути виміряна.

Я думаю, що нам потрібен механізм, який робить наступне:

• Виміряйте швидкість дрейфу RTC плати до її розгортання
• Коли можливо, регулюйте системний час, що триває / регулярно через NTP
• Регулярно регулюйте системний час від RTC, коли НТП недоступний. Враховуйте відому швидкість руху RTC.
• Необов’язково: Виміряйте та запишіть швидкість руху RTC, що триває, під час роботи в Інтернеті (1)

Під "механізмом" я маю на увазі деякий доглянутий, задокументований фрагмент програмного забезпечення та / або конфігурацію, який може обробляти два стани "онлайн" проти "офлайн", переконайтесь, що системний годинник синхронізований з правильним джерелом часу (ntp vs. 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. Це означає, що годинник від 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 (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 мають роздільну здатність однієї секунди, тому вони повинні були б значно змінитись, щоб надійно виміряти.