PTP-сервер дома. Часть 2
Семён сохраняет полезное_)Сегодня продолжим разговор о самодельном PTP‑сервере дома. В прошлый раз я упомянул, что точность полученного решения была не лучшей после одного часа работы. Поэтому далее я решил улучшить точность.
Из‑за того что я живу неподалёку от стратегического объекта, точность часов периодами, когда «защитники отечества» включают «глушилку», скачет на 4–5 минут. Поэтому на машине, имитирующей клиента, я отключил Chrony, чтобы не было конфликта при измерении.
Для фиксации таких случаев я написал простой скрипт, который ходит на мой NTP‑сервер с GNSS‑модулем и на сервер NTP из пула, а затем отправляет данные в InfluxDB. В нём удобно смотреть графики.
Так, благодаря данным по Offset, можно увидеть, когда «глушилка» работает. Это ещё заметно по времени от NTP‑сервера: оно уходит на 4–5 минут (если уж точно — на 272–277 секунд). Ниже будет скриншот.
Также теперь все команды запуска строго выполняются с realtime priority:
sudo ts2phc -c enp6s0 -f /etc/ts2phc.conf & sudo chrt -f 98 ptp4l -i enp6s0 -f /etc/ptp4l.conf -m
Далее рассмотрим конфиг ts2phc.conf на мастер‑машине:
cat /etc/ts2phc.conf [enp6s0] ts2phc.channel 0 ts2phc.extts_polarity both ts2phc.pin_index 2 [global] logging_level 6 first_step_threshold 1
ts2phcэто утилита из пакета linuxptp (Precision Time Protocol для Linux), которая синхронизирует системное время с аппаратными часами (PHC — PTP Hardware Clock)
через сигналы таймстампов (timestamping) на сетевых интерфейсах.
Файл состоит из двух секций:
[enp6s0]— настройки для конкретного сетевого интерфейса;[global]— глобальные параметры утилиты.
Секция [enp6s0] (настройки интерфейса)
ts2phc.channel 0— указывает номер канала (индекс) для работы с таймстампами на интерфейсе.ts2phc.extts_polarity both— определяет полярность внешних сигналов таймстампа (EXTTS).both— учитывает оба фронта сигнала (подъём и спад).- Альтернативы:
rising(только подъём),falling(только спад). - Полезно для интерфейсов, поддерживающих двустороннюю синхронизацию.
ts2phc.pin_index 2— задаёт номер пина (вывода) на сетевой карте, к которому подключён внешний сигнал таймстампа.
Секция [global] (глобальные настройки)
logging_level 6— уровень детализации логов.6— максимально подробный вывод (отладка).first_step_threshold 1— пороговое значение (в секундах) для первого шага синхронизации.- Если разница между системными часами и PHC превышает 1 секунду,
ts2phcвыполнит коррекцию скачком (step). - При меньших расхождениях используется плавная подстройка (
slew). - Значение
1— компромисс между скоростью и плавностью синхронизации.
Эти параметры я взял из документации:
https://linuxptp.nwtime.org/documentation/configs/ts2phc-generic/
Единственное, я решил не ставить ts2phc.pulsewidth 100000000, ибо данная настройка некорректна. Лучше оставить значение, используемое по умолчанию (500 мс), и не описывать его.
Теперь рассмотрим конфиг для ptp4l:
cat /etc/ptp4l.conf [global] # Основные настройки gmCapable 1 # Устройство может быть Grandmaster (главным источником времени). 1 — включено; 0 — отключено. priority1 248 # Приоритет 1‑го уровня (0–255). Чем меньше значение, тем выше приоритет. priority2 248 # Приоритет 2‑го уровня (0–255). Чем меньше значение, тем выше приоритет. clockClass 248 # Класс часов (0–255). Определяет «качество» источника времени. clockAccuracy 0xFE # Точность часов (в шестнадцатеричном формате). offsetScaledLogVariance 0xFFFF # Масштабированная логарифмическая дисперсия смещения. assume_two_step 1 # Использовать двухшаговый режим PTP (обмен сообщениями Sync + Follow_Up). follow_up_info 1 # Отправлять дополнительную информацию в Follow_Up‑сообщениях. transportSpecific 0x1 # Поле Transport Specific (в заголовке PTP). 0x1 — зарезервировано для специфичных транспортных механизмов. network_transport L2 # Транспортный уровень: Ethernet (Layer 2). delay_mechanism E2E # Механизм измерения задержки: End‑to‑End (через сообщения Delay_Req/Delay_Resp). ptp_dst_mac 01:80:C2:00:00:0E # MAC‑адрес назначения для PTP‑фреймов (стандартный групповой адрес для PTP over Ethernet). # Фиксированный мастер BMCA noop # Отключает алгоритм BMCA (Best Master Clock Algorithm). Устройство не будет участвовать в выборе Grandmaster — оно либо мастер, либо ведомый. serverOnly 1 # Режим «только сервер» (мастер). inhibit_announce 1 # Запрещает отправку Announce‑сообщений. Используется, когда мастер не должен участвовать в BMCA. asCapable true # Устройство поддерживает AS (Announce Suppression) — подавление избыточных Announce‑сообщений. inhibit_delay_req 1 # Запрещает отправку Delay_Req‑сообщений. Актуально для мастера, который не измеряет задержки к ведомым. path_trace_enabled 1 # Включает отслеживание пути (Path Trace) — запись списка узлов в PTP‑сообщениях. logSyncInterval -3 # Логарифмический интервал отправки Sync‑сообщений (в секундах). -3 → 0,125 с (8 Sync‑сообщений в секунду). Чем меньше число, тем чаще отправляются Sync. syncReceiptTimeout 3 # Таймаут ожидания Sync‑сообщений от мастера (в кратных интервалах logSyncInterval). Если за 0,375 с не получено Sync, считается потеря связи. neighborPropDelayThresh 800 # Порог задержки (в наносекундах) для соседских узлов. Если задержка превышает 800 нс, могут активироваться механизмы коррекции. min_neighbor_prop_delay -20000000 # Минимальная задержка (в наносекундах). Отрицательное значение (-20 000 000 нс = -20 мс) может использоваться для компенсации системных задержек.
Конфиг тестовый и ещё будет исправлен со временем. Но уже с этим конфигом я получил за 90 часов следующий результат:
Master offset: среднее = −0,00 нс, мин = −22 нс, макс = +18 нс Freq: среднее = 50 279,55 ppb, мин = 49 937 ppb, макс = 50 614 ppb Path delay: среднее = −8,56 нс, мин = −13 нс, макс = −5 нс
1. Master offset (смещение относительно мастера)
- Среднее: −0,00 нс
- Мин.: −22 нс
- Макс.: +18 нс
Разброс ±22 нс — очень хороший результат для большинства применений:
- Для телекома/5G часто требуют < 100 нс; здесь — в 2 раза лучше.
Вывод: смещение стабильно мало — отлично.
2. Freq (частота коррекции, в ppb — частях на миллиард)
- Среднее: 50 279,55 ppb
- Мин.: 49 937 ppb
- Макс.: 50 614 ppb
Высокое среднее (50 тыс. ppb) говорит о значительном изначальном расхождении частот. Разброс ~677 ppb (50 614 − 49 937) — умеренная нестабильность. Для «обычного» железа — приемлемо.
3. Path delay (задержка пути)
Среднее: −8,56 нс
Мин.: −13 нс
Макс.: −5 нс
Оценка:
Разброс всего 8 нс (от −13 до −5) — очень стабильно.
Абсолютные значения малы (< 13 нс) — значит, сеть и оборудование работают предсказуемо. Задержка пути стабильна и мала — отлично.
Вывод и планы работ дальше
90 часов — неплохо, но для оценки дрейфа лучше смотреть 1–7 дней. Поэтому буду в основном тестировать на тесте 7 дней. Далее хочу добиться чтобы не нужно было отключать chrony и по сети шло точное время.