8

I have a Linux server which has its time synchronized to a GPS-based NTP appliance located close by. Ping times from the server to the appliance are circa 1ms, with very low jitter:

--- x.x.x.x ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 99001ms
rtt min/avg/max/mdev = 0.874/0.957/1.052/0.051 ms

However, the NTP client estimates the accuracy of time synchronization to be around 5-6ms, which seems very high given the setup:

synchronised to NTP server (x.x.x.x) at stratum 2
   time correct to within 5 ms
   polling server every 16 s

ntpq -p gives the following:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*x.x.x.x         .PPS.            1 u   10   16  377    0.964   -0.019   0.036

Two questions:

  1. What may be causing the NTP client to have such low confidence in the accuracy of the synchronization?
  2. Is there any way to measure the actual accuracy of the synchronization, say to the nearest millisecond?
5
  • Out of interest, has the "time correct to within 5 ms" changed since you last checked?
    – Imo
    Sep 24, 2010 at 9:42
  • @lmo guessing you're thinking it's taking its time to drift into sync? On another note - What's the model of GPS clock and the rated accuracy in its specs? Sep 24, 2010 at 10:15
  • @lmo I've been keeping an eye on it, and it drifts between 5 and 7ms.
    – NPE
    Sep 27, 2010 at 17:53
  • @Chris I've been trying to find this out from our network people (don't have physical access to the hardware.) Will get back as soon as I have more info.
    – NPE
    Sep 27, 2010 at 17:55
  • Since the 5ms reading is really an upper bound, I guess the real question is how to measure the actual accuracy of the synchronized clock (say to within 1ms.)
    – NPE
    Sep 27, 2010 at 18:04

3 Answers 3

8

The value that ntpstat displays after "time correct to within" is the root dispersion + root delay / 2. ntpq -p doesn't show the "root dispersion" run ntpq -c rl instead.

Notwithstanding, it is clear that the main source of the lack of accuracy is the dispersion rather than the delay (which is only 0.964).

The dispersion is the "nominal error relative to the primary reference source." I've briefly looked through the NTPv4 RFC and this is what it has to to say:

The dispersion (epsilon) represents the maximum error inherent in the measurement. It increases at a rate equal to the maximum disciplined system clock frequency tolerance (PHI), typically 15 PPM. 1 PPM is equal to 10^(-6) seconds/second.

To use rrdtool terminology dispersion isn't a gauge but rather a counter. Seeing a large value may not indicate anything is wrong.

Alas, I wasn't able to understand the ntp algorithm well enough to see how to make this number smaller. I've noticed this value is reset occasionally. I don't know why.

2
  • Thanks for this. I'm still trying to get my head round all this, but you're right in that it's rootdispersion (which is currently 6.898) that's causing the high readings.
    – NPE
    Sep 27, 2010 at 17:58
  • There is a really good discussion of this at blog.meinbergglobal.com/2021/02/25/…. There is a minimum Dispersion = DR * (t4 – t1) + timestamping errors where t4-t1 is the time it takes the client to make the ntp call, start to finish, and DR is the drift rate of client clocks time and is equal to the fractional frequency error. Feb 12 at 19:20
6

The reason I asked about the hardware above is because many GPS devices (stratum 0, the 'root' source) connect to the computer that then acts as the NTP server via a serial link.

Serial connections often have 1-5ms jitter on the line due to signalling overheads/interrupt waits. Hence, I'm guessing your NTP source is reading from a serial source.

There are some tweaks you may be able to perform on the serial connection to reduce jitter. Primaily, disabling FIFO may gain you decent results.

http://support.ntp.org/bin/view/Support/KnownHardwareIssues#Section_9.1.5. http://www.febo.com/time-freq/ntp/jitter/index.html

1
  • This is very insightful, thank you. I shall look into this further.
    – NPE
    Oct 1, 2010 at 16:26
3

Time correct within 5 ms IS GREAT!!! 5 ms is 5 / 1000 of a second. Anything under 100 ms is easily acceptable for anything other than a small handful of situations in that case you would not be using GPS but a local atomic clock and two external reference clocks. We get within 10 ms with the ntp pool.

2
  • 1
    Thanks, but in this application we need at least 1 millisecond accuracy (hence the local GPS hardware.)
    – NPE
    Sep 27, 2010 at 17:51
  • Is 158 ms bad? That's what I'm getting Jun 17, 2015 at 16:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .