У меня есть локальная сеть с микроконтроллером ARM в качестве сервера NTP, и у меня есть настольный компьютер, работающий с ubuntu 16.04 LTS в качестве клиента NTP.
Как только я начну ntpd -g -c /etc/ntp.conf со следующим конфигурационным файлом ntp
server 192.168.0.11 minpoll 4 maxpoll 4
Самое первое смещение после того, как ntpd установит время, показывает очень хороший результат, то есть что-то ниже 1 мс. Я получаю значения смещения ntpq -p.
Однако смещение медленно увеличивается до 55 мс после прибл. 1000 секунд. Такое высокое смещение неприемлемо для моего приложения. Но после того, как смещение достигнет 55 мс, ntpd кажется, снова устанавливает время, и смещение становится достаточно маленьким и стабильным (<1 мс). Кажется, что ntpd пусть часы дрейфуют на некоторое время, и после (слишком) длительного периода времени демон принимает меры против дрейфа часов между клиентом NTP и сервером NTP.
С помощью ntpd -g -c /etc/ntp.conf -f /etc/ntp.drift где ntp.drift был создан ntpd, смещение будет оставаться ниже 1 мс все время, т.е. не будет линейного увеличения смещения, вызванного дрейфом часов; желаемое поведение.
Теперь к моей проблеме: в моем приложении мы не можем позволить ntpd запустить некоторое время, чтобы вычислить дрейф часов после длительного периода времени, синхронизация должна произойти через несколько секунд после загрузки клиента NTP, и смещение должно оставаться стабильным.
Как получить стабильное и небольшое смещение с ntpd не зная точно, часы идут?
А driftfile записывает частоту местных часов, и это хорошо, если нужно ее точно контролировать. Ubuntu /etc/ntp.conf имеет driftfile по умолчанию.
Добавление iburst на серверную линию быстро отправляет несколько пакетов при начальной синхронизации. Рекомендуется, особенно если вы не хотите ждать несколько минут несколько первых пакетов.
Сценарии инициализации могут отложить запуск приложения до тех пор, пока NTP не будет синхронизирован. Сделайте это в зависимости от ntp-wait systemd unit. Или ntpwait сценарий напрямую.
Ваш отчет о смещении, увеличивающемся, а затем исправляющемся, звучит так, как будто ntpd пересекает свой порог шага, а затем устанавливает время, а не вращает его.
Отсутствие связи между временем вашего NTP-сервера и реальным временем в формате UTC может быть корнем вашей проблемы. Если у вашего NTP-сервера нет нескольких реальных источников (независимо от того, находятся ли они в Интернете, GPS, PPS или атомарный источник в вашей локальной сети), то он не сможет определить ошибку частоты своего собственные часы, и поэтому не сможет эффективно контролировать свои часы.
Вы можете выяснить, верна ли эта теория, включив регистрацию статистики как на сервере, так и на клиенте, например:
statsdir /var/log/ntpstats/
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
Затем разместите свои файлы статистики и свои конфигурации на сайте pastebin или аналогичном, и мы сможем проанализировать их в свете наблюдаемого вами поведения.
Попробовав несколько разных вариантов ntpd все еще слишком большая задержка, я переключился на хрония. Мой NTP-сервер остался без изменений. Использование chrony постоянно давало мне задержку <1 мс. Я увеличил время опроса, так как рекомендовано chrony имея следующий файл конфигурации
### chrony.conf
# Add server
server 192.168.0.11 iburst minpoll -6 maxpoll -6 filter 15 xleave
hwtimestamp eth0 minpoll -6
# Logging
logdir /var/log/chrony
log measurements statistics tracking
makestep 0.1 3
driftfile /etc/chrony.drift
И начал демон с ./chronyd -f /etc/chrony.conf