Running ntpq -p to check how ntpd is working is one of the first things a sysadmin learns when trying to debug problems with ntpd. One of the first questions which arises is "how do delay, offset and jitter relate?", or even "what do delay, offset and jitter mean?". Well, today I stumbled across a graph that gives me the opportunity to explain this in practice.

Let's start with explaining these three terms as bare-bones as possible. Note that definitions given below are here just to give you an idea and are no way accurate; please go to the NTP documentation, NTP FAQ or community support sites to get the real ones.

• delay is an estimate of how many milliseconds an NTP packet takes to travel from a server to your client.
• offset is an estimate of how many milliseconds your computer's clock differs from UTC.
• jitter is an estimate of how these measurements are accurate, and it's non-negative: the smaller the jitter, the better accuracy.

Now look at this graph: …
It tracks delay, offset a jitter for a server that is up and running from more than one year (it contains just a month's worth of data though).

As you can see, the delay went down two times: the first one it went from about 60ms to 45, the second it went down from 45ms to about 20ms. Overall, delay was reduced by a stunning 67 percent. And look what happened in correspondence of the two steps: the offset oscillation was reduced, and the value of jitter went down, up to the point that after the last step you can't really see the offset line any more.

This should help to draw a conclusion: a smaller delay helps to have a better clock accuracy. However, remember that delay's absolute value is not the only thing to consider.

Take a look at the left side of the graph, find the spikes in jitter and go up to the delay line: you'll notice that jitter was higher when the delay was more unstable (you are looking at a month's worth of data coming from RRDtool, so a number of spikes has been suppressed): delay was always around 60ms, but with a lot of oscillations around that value.

So where am I taking you with this? I am trying to make you aware of a few facts:

• small delays improve clock accuracy;
• unstable delays impair accuracy, even when the value of delay is small; and
• remember: delay is not the only thing to consider: other factors (e.g.: load on the machine running ntpd) will influence your clock as much as the delay, or even more.

Enjoy!