Непредсказуемый высокий джиттер ntp от единственного локального источника часов GPS
Вопрос
Как я могу исправить кратковременный джиттер с высоким NTP?
Исходная информация
У меня есть NTP-сервер в моей частной сети. Мои серверы синхронизируются с этих часов, и обычно все хорошо. Пример набора выходных данных:
ntpq> pe
remote refid st t when poll reach delay offset jitter
==============================================================================
*10.10.10.249 10.10.100.20 3 u 367 1024 377 0.096 0.145 0.142
ntpq> as
ind assid status conf reach auth condition last_event cnt
===========================================================
1 2378 962a yes yes none sys.peer sys_peer 2
ntpq> rv 2378
associd=2378 status=962a conf, reach, sel_sys.peer, 2 events, sys_peer,
srcadr=10.10.10.249, srcport=123, dstadr=10.10.200.1, dstport=123,
leap=00, stratum=3, precision=-18, rootdelay=1.190, rootdisp=37.155,
refid=10.10.100.20,
reftime=df134714.c026b762 Mon, Aug 6 2018 22:15:48.750,
rec=df134a04.507b5ad6 Mon, Aug 6 2018 22:28:20.314, reach=377,
unreach=0, hmode=3, pmode=4, hpoll=10, ppoll=10, headway=0, flash=00 ok,
keyid=0, offset=0.145, delay=0.096, dispersion=15.187, jitter=0.142,
xleave=0.052,
filtdelay= 0.10 0.10 0.05 0.08 0.09 0.11 0.11 0.11,
filtoffset= 0.14 0.16 0.19 0.12 0.02 -0.02 -0.04 -0.10,
filtdisp= 0.00 15.57 31.37 47.42 63.65 79.41 95.27 110.72
Однако время от времени мы наблюдаем увеличение системы до гораздо большего джиттера. Копаясь в этом, когда это происходит, мы видим один скачок в значениях задержки и смещения. Пример:
filtdelay= 0.06 0.11 250.20 0.07 0.04 0.10 0.07 0.09,
filtoffset= 0.05 -0.01 124.95 -0.05 -0.05 -0.07 -0.05 -0.03,
Обратите внимание, что в этом случае offset (обычно, но всегда) остается в пределах 0,5/-0,5:
# ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
*10.10.10.249 10.10.100.20 3 u 711 1024 377 0.112 -0.006 47.230
Иногда высокое значение джиттера может сохраняться, в основном неизменным, в течение нескольких часов. Большое количество джиттера варьируется от 1 до более 100. В конце концов, оно падает ниже 1.
Приложение Мы видим корреляцию между загрузкой системы и джиттером NTP. На первый взгляд, NTP-пакеты могут конфликтовать с NFS-трафиком.
РЕДАКТИРОВАТЬ Это не источник часов GPS.
РЕДАКТИРОВАТЬ Это определенно проблема. Дрожание, которое мы видим, примерно соответствует значению высокого смещения.
1 ответ
Основываясь на моем опыте в проекте Mars 2003 в JPL, где я отвечал за программную петлю фазовой синхронизации, которая синхронизировала наземное моделирование космического корабля с нисходящим тактовым сигналом от космического корабля, наложение сигналов - единственное явление, которое я могу себе представить это может вызвать переходный джиттер. Псевдоним происходит, когда потеряна связь между тем, что клиент временного сигнала считает сигнальным "тик", и тем, чем он является на самом деле. Если ваши клиенты ("мои серверы" в вашем вопросе) используют алгоритм сглаживания, чтобы попытаться вернуться в синхронизацию после потери соединения, им может потребоваться некоторое время для повторной синхронизации.
Тактовый сигнал Mars'03 составлял 8 Гц, что означало, что было 8 сигналов в секунду. Если клиент отстает в своей выборке более чем на 1/8 секунды, то он пропустит один из сигналов и запутается. Чтобы бороться с этим, я сделал петлю фазовой синхронизации максимально прочной и эластичной, чтобы в нормальных условиях было практически невозможно потерять синхронизацию с входящим сигналом. Если бы он потерял синхронизацию (чего я никогда не видел, если бы я не использовал его с помощью осциллографа), ему пришлось бы начинать сначала, ожидая появления хорошо известного шаблона синхронизации, после чего он мог бы сбросить контур фазовой синхронизации, просто как это происходит при запуске.
Исходя из этого опыта, я предполагаю, что ваше временное дрожание является следствием временных потерь соединения в сети с временной синхронизацией, которые могут усугубляться штормовыми пакетами, если ваш протокол времени гарантирует доставку, как это делает TCP/IP. Если протокол гарантированной доставки отстает от тактового сигнала, это приводит к появлению псевдонимов. Затем клиенты должны делать все, что они делают, чтобы выполнить повторную синхронизацию, и попытка гарантировать доставку в этих обстоятельствах может вызвать бурю пакетов, которая ухудшает ситуацию, прежде чем они станут лучше. Если логика сглаживания достаточно надежна, вы можете проверить, использует ли ваш протокол времени TCP/IP (который гарантирует доставку) или UDP (что не намного, но намного проще), и использовать UDP для устранения пакетов-штормов.