Назад | Перейти на главную страницу

Несогласованные значения NTP в Red Hat Linux

Недавно на моем сервере наблюдались высокие значения задержки и смещения 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 вывод.