1

Recently I am experiencing NTP high delay and offset values on my server.

$ 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

However, when I query sync details manually, values are way different.

$ 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

In the first output delay is about 24 seconds, while in the second one it's less than 1 sec. This is the same for offset value. I want to know which output is valid. If the second output is more precise, why is it not showing the same in the first output. Can anyone explain what causes such difference, which one is valid and should I refer to?

(our service is quite sensitive to time, and such a discrepancy would result in abnormal reports, such as negative service usage duration time)

Paul Gear
  • 3,938
  • 15
  • 36
aschkant
  • 35
  • 1
  • 6
  • 1
    They're really not that different. Could you be more precise about what you specifically think is a problem? – David Schwartz Mar 05 '19 at 09:04
  • In the first output delay is about 24 seconds, while in the second one it's less than 1 sec. This is the same for offset value. I want to know which output is valid. If the second output is more precise, why is it not showing the same in the first output. (our service is quite sensitive to time, and such a discrepancy would result in abnormal reports, such as negative service usage duration time) – aschkant Mar 05 '19 at 09:18
  • 1
    It's not 24 seconds, it's 23.942ms one way which is perfectly consistent with 46.01ms round trip. – David Schwartz Mar 05 '19 at 17:58

2 Answers2

1

I believe the delay is the time in milliseconds:

http://www.clock.org/ntp/debug.html

That link details a bit about how to read the output. However, 24ms seems about correct depending on how fast your network is. You need to account for the output in ntpdate as well:

https://superuser.com/questions/393426/how-inaccurate-is-my-system-clock-on-unix

This details that ntpdate -q is reporting in seconds. 46ms is about the same time as the delay in ntpq -p output.

Paul Gear
  • 3,938
  • 15
  • 36
David O.
  • 124
  • 3
1

As other comments and answers have pointed out, offset from ntpdate is in seconds, whilst ntpq displays them in milliseconds. So there's no real discrepancy in your offsets (which is the important thing). Your time is in fairly close sync. But there's still a discrepancy in the delays reported.

I did some tests of delay to my server's peers and got the following:

  • peer 1 (stratum 1 BeagleBone Black on my local LAN): 0.02689 s via ntpdate, 0.598 ms via ntpq, avg 1.032 ms via ping - difference between ntpdate and ntpq: 26.292 ms

  • peer 2 (public stratum 1 server about 1000 km away): 0.04485 s via ntpdate, 18.662 ms via ntpq, avg 18.379 ms via ping - difference between ntpdate and ntpq: 26.188 ms

  • peer 3 (public stratum 1 server across the Pacific Ocean): 0.21938 s via ntpdate, 193.844 ms via ntpq, avg 207.875 ms via ping - difference between ntpdate and ntpq: 25.536 ms

My conclusion: ntpdate is somewhat inefficient and adds a fixed overhead of about 25-26 ms on average (on my machine), and that ntpd and/or the Linux UDP stack is usually slightly more efficient than ping and/or the Linux ICMP stack.

Paul Gear
  • 3,938
  • 15
  • 36