Недавно на моем сервере наблюдались высокие значения задержки и смещения NTP.
$ ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*10.161.50.254 .SLK. 1 u 962 1024 377 23.942 -2.157 0.819
+10.147.50.253 .SLK. 1 u 1001 1024 377 26.628 2.991 0.245
Однако когда я запрашиваю детали синхронизации вручную, значения сильно отличаются.
$ ntpdate -q 10.161.50.254
server 10.161.50.254, stratum 1, offset -0.001250, delay 0.04601
5 Mar 11:14:37 ntpdate[29876]: adjust time server 10.161.50.254 offset -0.001250 sec
В первом случае задержка вывода составляет около 24 секунд, а во втором - менее 1 секунды. То же самое и для значения смещения. Я хочу знать, какой вывод действителен. Если второй вывод более точен, почему он не отображается в первом выводе. Может ли кто-нибудь объяснить, что вызывает такую разницу, какой из них действителен и на что я должен ссылаться?
(наш сервис очень чувствителен ко времени, и такое несоответствие приведет к аномальным отчетам, таким как отрицательное время использования сервиса)
Как указывали другие комментарии и ответы, смещение от ntpdate
в секундах, пока ntpq
отображает их в миллисекундах. Так что в ваших смещениях нет реальных расхождений (что важно). Ваше время довольно синхронизировано. Но все же есть несоответствия в сообщаемых задержках.
Я провел несколько тестов задержки на узлах моего сервера и получил следующее:
узел 1 (слой 1 BeagleBone Black в моей локальной сети): 0,02689 с через ntpdate
, 0,598 мс через ntpq
, в среднем 1,032 мс через ping
- разница между ntpdate
и ntpq
: 26,292 мс
узел 2 (общедоступный сервер уровня 1 на расстоянии около 1000 км): 0,04485 с через ntpdate
, 18,662 мс через ntpq
, в среднем 18,379 мс через ping
- разница между ntpdate
и ntpq
: 26,188 мс
узел 3 (общедоступный сервер уровня 1 через Тихий океан): 0,21938 с через ntpdate
, 193,844 мс через ntpq
, в среднем 207,875 мс через ping
- разница между ntpdate
и ntpq
: 25,536 мс
Мой вывод: ntpdate
несколько неэффективен и добавляет фиксированные накладные расходы в среднем около 25-26 мс (на моей машине), и это ntpd
и / или стек Linux UDP обычно немного более эффективен, чем ping
и / или стек Linux ICMP.
Я считаю, что задержка - это время в миллисекундах:
http://www.clock.org/ntp/debug.html
Эта ссылка немного подробно описывает, как читать вывод. Однако 24 мс кажется правильным в зависимости от скорости вашей сети. Вам необходимо учесть вывод в ntpdate
также:
https://superuser.com/questions/393426/how-inaccurate-is-my-system-clock-on-unix
Это детали, которые ntpdate -q
сообщает в секундах. 46 мс - это примерно то же время, что и задержка в ntpq -p
вывод.