Как я могу исправить временный высокий джиттер 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.
РЕДАКТИРОВАТЬ Это определенно проблема. Джиттер, который мы видим, примерно коррелирует с высокими значениями смещения.
Основываясь на моем опыте работы над проектом Mars 2003 в JPL, где я отвечал за программный контур фазовой автоподстройки частоты, который синхронизировал моделирование наземного космического корабля с нисходящим тактовым сигналом космического корабля, наложение спектров - единственное явление, о котором я могу думать. из-за этого может возникнуть временное дрожание. Псевдоним происходит, когда теряется связь между тем, что, по мнению клиента временного сигнала, представляет сигнал «тик», и тем, чем он является на самом деле. Если ваши клиенты («мои серверы» в вашем вопросе) используют алгоритм сглаживания, чтобы попытаться восстановить синхронизацию после потери связи, им может потребоваться некоторое время для повторной синхронизации.
Тактовый сигнал Mars'03 составлял 8 Гц, что означает 8 сигналов в секунду. Если клиент отстает в выборке более чем на 1/8 секунды, он пропустит один из сигналов и запутается. Чтобы бороться с этим, я сделал контур фазовой автоподстройки частоты как можно более надежным и эластичным, так что в нормальных условиях практически невозможно было потерять синхронизацию с входящим сигналом. Если он действительно потерял синхронизацию (чего я никогда не видел, если только я не принудительно использовал его с помощью осциллографа), ему пришлось бы начинать все сначала, ожидая появления хорошо известного шаблона синхронизации, после чего он мог бы сбросить контур фазовой автоподстройки частоты, просто как это происходит при запуске.
Я предполагаю, основываясь на этом опыте, что ваш временный джиттер является результатом временных потерь связи в сети синхронизации времени, которые могут усугубляться пакетными штормами, если ваш протокол времени гарантирует доставку, как и TCP / IP. Если протокол гарантированной доставки отстает от тактового сигнала, возникает псевдоним. Затем клиенты должны делать все, что они делают, для повторной синхронизации, и попытка гарантировать доставку в этих обстоятельствах может вызвать бурю пакетов, которая усугубит ситуацию до того, как они поправятся. Если логика сглаживания достаточно надежна, вы можете проверить, использует ли ваш протокол времени TCP / IP (который гарантирует доставку) или UDP (что не делает, но намного проще) и использовать UDP для устранения штормов пакетов.