Вопрос или проблема
(Это продвинутая тема)
У меня есть эталонные часы DCF-77, подключенные через последовательный кабель к ПК, на котором работает ntpd под Linux.
Один из пиров — это локальный сервер NTP с использованием локальных GPS-часов.
Кроме того, я настроил три внешних сервера уровня stratum-1.
Хотя локальный GPS-сервер, вероятно, является самым точным, я не уверен в его фактическом смещении, так как длина кабеля между GPS-приемником и антенной точно неизвестна (кабель устанавливался кем-то другим).
Поэтому, когда напрямую подключенные эталонные часы DCF-77 и локальный GPS-сервер расходятся во мнениях о смещении, трудно решить, какой из них более корректен, особенно с учетом сетевых задержек.
Поэтому я добавил три внешних сервера уровня stratum-1, но у них значительные (превышающие смещение) сетевые задержки.
Поэтому я задаюсь вопросом: если я хочу “моделировать” смещение эталонных часов DCF-77, как мне вычислить “правильное” значение?
Текущее состояние показано ниже:
# ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
*127.127.8.0 .DCFp. 0 l 14 64 377 0.000 -0.197 0.065
+172.20.2.25 .GPS. 1 u 17 64 377 1.487 +0.228 0.745
-192.53.103.108 .PTP0. 1 u 30 64 377 15.842 +1.387 0.105
-192.53.103.104 .PTP0. 1 u 10 64 377 15.720 +1.233 0.147
+192.53.103.103 .PTP0. 1 u 64 64 377 15.900 +1.077 0.987
Итак, у GPS и DCF-77 разные знаки, а внешние серверы ориентированы в направлении GPS.
Я бы хотел, чтобы было как можно меньше переключений часов, если какой-либо сервер уровня stratum-2 переключается между GPS и DCF-77.
Как вы видите, дрожание DCF-77 практически меньше, чем у GPS, поэтому клиенты уровня stratum-2 время от времени меняют источник.
В прошлом я внимательно откалибровал часы, используя другое оборудование и версию Linux, но после недавних изменений дрожание стало хуже, как видно на графике статистики:
Здесь дрожание и смещение являются комбинированными соответствующими значениями.
Начиная с мая, смещение стало хуже; возможно, был введен какой-то новый сетевой компонент, и после перебоев, вызванных заменой оборудования, смещение изменяется больше, чем раньше (программное обеспечение было обновлено с SLES12 SP5 до SLES15 SP6, также используется пакет ntp, который не является частью основной дистрибуции).
Тем не менее, проблема может быть связана с оборудованием, так как последовательные порты сейчас считаются несущественными.
Итак, как мне рассчитать значение подстройки для эталонных часов DCFp?
Ответ или решение
Калибровка локального эталонного часов в ntpd – это довольно сложная задача, требующая глубокого понимания работы сетевых протоколов времени и факторов, влияющих на точность синхронизации. В данном случае у вас имеется несколько источников времени: DCF-77 через последовательный кабель, локальный GPS-сервер и три внешних сервера stratum-1.
Теория
ntpd (Network Time Protocol daemon) – это сервис, работающий в операционной системе для синхронизации часов компьютера с внешними источниками времени. Каждый источник времени (peer) в ntpd имеет разные атрибуты, такие как задержка (delay), смещение (offset) и джиттер (jitter), которые показывают, насколько данный источник точно синхронизирован.
- Смещение (Offset): показывает разницу в миллисекундах между локальными часами и часами сервера.
- Задержка (Delay): время, необходимое для передачи пакета времени от сервера до клиента и обратно.
- Джиттер (Jitter): вариабельность в задержке, показывающая стабильность соединения.
Одним из важных элементов настройки ntpd является функция "фадж" (fudge), с помощью которой вы можете искусственно исправить показания локального часов источника времени.
Пример
Из выходных данных команды ntpq -pn видно, что:
- DCF-77 (127.127.8.0) показывает смещение -0.197 мс.
- Локальный GPS сервер показывает смещение +0.228 мс.
- Внешние stratum-1 серверы имеют положительное смещение и значительно большую задержку из-за сетевых факторов.
Хотелось бы минимизировать переключение источников времени (clock hopping) на вашем stratum-2 сервере, поскольку джиттер DCF-77 меньше, и по идее его логично сделать эталоном. Однако проблема в том, что сначала нужно решить, какой из источников более правдоподобен, так как GPS и внешний сервер сходятся больше, чем с DCF-77.
Применение
-
Анализ данных: Исходя из ваших данных, DCF-77 имеет наименьший джиттер. Это говорит о его стабильности, но не обязательно о точности. Вам нужно оценить верность данных от GPS и DCF-77 с помощью дополнительных измерений или аналитики.
-
Определение задержки кабеля для GPS: Поскольку длина кабеля между GPS-приемником и антенной неизвестна, это может добавлять неучтенную задержку. Физически измерьте или предоставьте информацию о задержке передача от антенны до вашего сервера.
-
Вычисление fudge-фактора: После определения возможной задержки используйте fudge-команду для коррекции DCF-77:
fudge 127.127.8.0 time1 <ваше скорректированное значение смещения>Значение
<ваше скорректированное значение смещения>будет разницей между измеренными (или доверительными) значениями GPS и DCF-77 с учетом сетевых задержек и задержки кабеля. -
Мониторинг изменений: После применения изменений необходимо вести статистическую оценку и графизацию данных для мониторинга, считая среднеквадратичные ошибки (root mean square error, RMSE) для устойчивости оценок.
-
Тестирование устойчивости: Переключайте источники с проводящей временной NTP-сети и следите за jitter и offset после калибровки.
Вывод
Подход нацелен на минимизацию ошибок и отклонений, путем тщательной калибровки эталонного часов через изучение показателей сети и индивидуальных характеристик оборудования. Убедитесь в точности введённых данных, проверяя другими источниками, например, радиочасы. Это сможет снизить переключение источников и повысит точность работы вашего ntpd. Если проблема сохраняется, возможна аппаратная неисправность, которую стоит вовремя диагностировать и устранять совместно с сетевыми и аппаратными инженерами.
Мониторинг и результативность должны стать ключевыми аспектами в вашем дальнейшем управлении конфигурацией ntpd.