Linux – Seemingly poor quality of NTP time synchronization using a GPS clock

gpslinuxntp

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?

Best Answer

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.

Related Topic