PTP сервер дома. Часть 4

Привет всем!

Конец года и штамм гонконгского гриппа дали о себе знать, поэтому эта заметка выходит с задержкой.

Сейчас у моего PoC (Proof of Concept) есть проблема: из‑за глушения GNSS‑сигнала я получаю неверное время. Для его корректировки решено было задействовать внешние RTC‑часы. Для этого я решил модифицировать код проекта chrony (современный вариант проекта ntpd).

Он удобен тем, что работает как клиент для синхронизации с NTP‑серверами, эталонными часами (например, GPS) или вручную, а также может выступать как NTP‑сервер для других компьютеров в сети. Кроме того, в отличие от традиционного ntpd, он быстрее стабилизируется и лучше справляется с прерывистыми сетями и виртуализированными средами, обеспечивая высокую точность синхронизации.

Рассмотрим chrony подробнее: https://github.com/mlichvar/chrony

Chrony — современная реализация NTP (Network Time Protocol) для Linux/Unix‑систем, спроектированная для высокой точности и гибкости в сложных условиях (прерывистое соединение, колебания температуры, виртуализация).

Архитектура chrony

Система состоит из двух ключевых компонентов:

• chronyd — демон, работающий в пользовательском пространстве. Синхронизирует системные часы с удалёнными NTP‑серверами или локальными эталонными источниками (GPS, PPS и т. п.). Управляет коррекцией времени (плавная подгонка или резкие шаги). Ведёт статистику дрейфа часов и задержек.
• chronyc — утилита командной строки для мониторинга и управления chronyd. Позволяет проверять статус синхронизации, добавлять/удалять серверы, выполнять диагностику. Работает в интерактивном или неинтерактивном режиме.

Как работает синхронизация?

Обнаружение источников

В конфигурационном файле /etc/chrony.conf задаются NTP‑серверы (через server/pool) или локальные референсные часы (через refclock). Chrony автоматически выбирает наилучший источник на основе стратума, задержки и дисперсии.

Измерение смещения времени

Демон отправляет NTP‑запросы к серверам и замеряет:

• задержку (round‑trip delay);
• смещение локальных часов относительно сервера.

Использует алгоритмы фильтрации для отсева аномальных ответов.

Коррекция времени

• Плавная подгонка (slewing) — изменение частоты системных часов для постепенного устранения смещения.
• Резкий шаг (step) — мгновенное изменение времени (используется при больших расхождениях, если разрешено в конфиге).

Режим выбирается на основе настроек (makestep, maxcorrection).

Учёт дрейфа

Chrony записывает историю отклонений в файл дрейфа (driftfile). При перезагрузке использует эту информацию для быстрой начальной коррекции.

Ключевые механизмы chrony

Стратум (stratum)

Иерархический уровень источника времени:

• Stratum 0: атомные часы, GPS‑приёмники.
• Stratum 1: серверы, напрямую подключённые к stratum 0.
• Stratum 2: серверы, синхронизирующиеся со stratum 1, и т. д.

Chrony предпочитает источники с меньшим stratum.

Обработка прерывистых соединений

Если сеть нестабильна, chrony:

• использует сохранённый дрейф для поддержания точности;
• автоматически возобновляет синхронизацию при восстановлении связи;
• поддерживает опцию offline для серверов, которые могут быть временно недоступны.

Поддержка аппаратных источников

• GPS (через NMEA или SHM);
• PPS (Pulse Per Second) для микросекундной точности;
• локальные генераторы (например, RTC).

Настройка через директивы refclock в конфиге.

Управление RTC (Real‑Time Clock) благодаря трём механизмам

• rtcsync: периодическая запись системного времени в RTC.
• rtcautotrim: корректировка RTC только при превышении порога отклонения.
• rtcfile: учёт ошибки RTC без его изменения (полезно для систем с нестабильным RTC).

Chrony поддерживает интеграцию со следующими типами устройств:

• refclock — основной интерфейс для аппаратных референсных часов;
• SHM (Shared Memory) — устройство пишет время в общий сегмент памяти, chrony его читает;
• SOCK — время передаётся через Unix‑сокет;
• NMEA — встроенный парсер для GPS‑устройств, выдающих строки NMEA.

Файлы:

• refclock_shm.c — работа с общей памятью;
• refclock_nmea.c — парсинг NMEA;
• refclock_pps.c — обработка PPS;
• refclock_local.c — эмуляция локального источника.

Для chrony и RTC подойдёт вариант как референсный источник времени (refclock). Chrony в первую очередь опирается на NTP‑серверы (интернет или локальные). RTC будет служить резервным источником при отсутствии сетевого соединения или для ускорения старта.

Два режима работы с RTC

• rtcsync — периодическая запись системного времени в RTC (каждые 11 минут по умолчанию).
• rtcautotrim — корректировка RTC, только если его отклонение превышает порог (например, 1 секунду).

Файл дрейфа (driftfile)

Chrony записывает в него оценку дрейфа системных часов. При перезагрузке использует эту информацию для предварительной коррекции, не полагаясь на RTC.

Напрямую сделать RTC приоритетным перед NTP в chrony нельзя — это противоречит самой логике работы NTP‑клиента. Но можно ограничить влияние NTP и максимально задействовать RTC в специфических сценариях.

Chrony спроектирован так:

• первичный источник — NTP‑серверы (интернет или локальные);
• резервный механизм — RTC + файл дрейфа (driftfile).

При наличии сети NTP всегда перевесит RTC, потому что:

• NTP даёт точность до миллисекунд;
• RTC обычно имеет погрешность в секунды/минуты.

Как видим, RTC не может быть приоритетным. Значит, нужен альтернативный способ. Он видится как модификация проекта с автокоррекцией при ошибке GNSS. Этим займусь на январских праздниках.

С наступающим!