5

I can query a local NTP daemon using ntpq to get the system variables. For example:

$ ntpq -c rv          
associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync,
version="ntpd 4.2.6p5@1.2349 Fri Nov  7 20:40:06 UTC 2014 (1)",
processor="armv7l", system="Linux/4.5.0-00348-g4c53e80", leap=00,
stratum=3, precision=-19, rootdelay=12.456, rootdisp=63.660,
refid=195.219.205.9,
reftime=dd9b0a27.3e1d46de  Wed, Oct 25 2017 13:03:35.242,
clock=dd9b0da9.5274cdfc  Wed, Oct 25 2017 13:18:33.322, peer=14326,
tc=10, mintc=3, offset=6.178, frequency=29.679, sys_jitter=0.409,
clk_jitter=1.189, clk_wander=0.154

I would like to determine how accurate the system time is (relative to the root clock(s)). That is, what is the error window? For example is it given by the offset = 6.178 => accuracy +/-6.178 ms, or does offset mean something else?

There are many other NTP questions that appear to touch on this subject but none seem to tackle exactly this question.

UPDATE

In the absence of any answers, and having read a variety of commentaries including that referenced by user3788685, I am no nearer the truth.

One possible interpretation is that the root dispersion is the best measure, suggesting in the example above an accuracy of ±63.7 ms. Another suggests the offset (+6.2 ms). It is clear from external observations that the actual accuracy is certainly much better than 64 ms but I do not have the tools to hand to test it more accurately.

awy
  • 5,271
  • 5
  • 23
  • 28

2 Answers2

1

The NTP Glossary is useful.

By accuracy, I would assume you're asking, "At any given moment, how far off the correct time is my clock". This will change minute to minute as your clock frequency changes - where metrics like jitter and stability apply. You're probably more interested in what differences ntp is finding between your clock and that of the root - metrics like offset for the instantaneous time difference, and skew and drift for how different the frequencies are.

Personally I ignore these and use ntpstat.

ntpstat will report the synchronisation state of the NTP daemon running on the local machine. If the local system is found to be synchronised to a reference time source, ntpstat will report the approximate time accuracy.

It gives output

synchronised to NTP server (14.202.204.182) at stratum 2 
   time correct to within 26 ms
   polling server every 128 s

which makes my head hurt less than trying to fully understand NTP.

flash
  • 61
  • 4
  • 1
    So, I think what is being said here is that `offset` represents the NTP server's estimate of the difference between the local clock and the root clock and that `rootdisp` provides the error bounds on that estimate. From my observations, those error bounds are actually _very_ pessimistic and the true error is actually very close to that reported by `offset`. I do not understand why ntpstat adds half the rootdelay value to that of the rootdisp to come up with an accuracy estimate. – awy Nov 22 '17 at 15:12
1

To determine NTP-regulated system clock accuracy

you need a reference clock.

and then you need to decide how precise it needs to be.

https://gpsd.gitlab.io/gpsd/gpsd-time-service-howto.html may be a nice reference.

you also might want to use the -p switch for ntpq.

my personal most used command to overview how ntp is working is:

watch "ntpq -crv -pn; ntpstat; ntptime; tac /var/log/ntp.log"

Spacerat
  • 11
  • 3