[ntp:questions] Monitoring NTP - nptq -p

Richard B. gilbert rgilbert88 at comcast.net
Wed Mar 21 01:43:29 UTC 2007

Keith E. Brandt, M.D. wrote:
> I just recently got a stratum 1 server set up on a FreeBSD box using 
> a Garmin 18lvc refclock (thanks Harlan!). Now that the system seems 
> to be working, my next step is to learn the monitoring tools. The 
> problem seems to be that different tools provide parameters with the 
> same labels, but different values making me thing I don't have a 
> complete understanding of the tools. I therefore want to ask this 
> group some basic questions to round out my understanding. I have read 
> the online documentation several time, but still feel I need some 
> holes filled. Hopefully this info will be good to have in the 
> archives to help future newcomers to ntp. Let me know if my thought 
> processes are good here and straighten me out where I need it.
> I want to start with probably the most basic of monitoring tools: ntpq -p.
> Here's the output from my system right now:
> /home/brandt 53> ntpq -p
>       remote           refid      st t when poll reach   delay   offset  jitter
> ==============================================================================
> *GPS_NMEA(0)     .GPS.            0 l    2   64  377    0.000    0.005   0.017
> -ntp.your.org    3 u   47   64  377   62.065    4.289   2.750
> +boudicca.tux.or    2 u   12   64  377   63.289   -5.525   2.273
> -dake.desynched.    2 u   18   64  377   55.516    4.039   2.726
> -veritas.imagepi     2 u   60   64  377   51.816   -8.385   2.495
> -hudson.yutanigl     2 u   20   64  377   50.768   -5.847  14.944
> +ferocious.dairi    2 u   18   64  377  119.579   -0.465  11.587
> 'Delay' - the ntp docs say this is the 'current estimated delay' in 
> milliseconds. Is this based on the last query or is it an average 
> over several packets or otherwise cooked value? I'm assuming it 
> assumes the upstream and downstream transfer speeds are symmetrical. 
> My local clock always shows zero delay - is this an assumption that 
> the refclock always has zero delay or is it measured and just too 
> small to display?

I believe delay is measured in all cases.  Low numbers are good, high 
are bad.  The maximum error in transmitting time from server to client 
is limited to one half the round trip delay.  Delay is the most 
significant part of a quantity called "Synchronization Distance" which 
is used to select the synchronization source.  Ntpd has no choice but to 
believe that the round trip delays are symmetrical. The asymmetry is 
usually small but in a few cases can become significant.

> 'Offset' - this one I really don't think I understand adequately. 
> Docs say 'offset of the peer' again in milliseconds. What is offset 
> from what? Is it the current clock setting on my computer is 5 ms 
> faster than the refclock? Is this an instantaneous value or averaged 
> over some time interval? I know ntp slowly slews the clock to 'real' 
> time, so it's not just going to step the clock by 'offset' ms, but 
> how much does this value contribute to the steering algorithm?
Offset is the difference between the server's clock and your clock.

> And finally, 'jitter' - again not an easy concept. I've found these 
> definitions:
>       Short-term variations in Frequency with components greater than
>       10 Hz. The estimated time error of the system clock measured as
>       an exponential average of RMS time differences.
> and
>       The estimated time error of the system clock measured as an
>       exponential average of RMS time differences.
> as well as just a measure of the random noise component.

If you sent packets over the internet from New York to Los Angeles at 
exact 1.000000 second intervals, they would not arrive at 1.000000 
second intervals!  Jitter effectively measures the variations in network 
delay.  The math is more difficult than the concept, especially if, like 
me, mathmatics is a foreign language to you.

> Are the 
> units here ms also? A high jitter value would indicate a lot of 
> random noise in the signal, but what can I do if jitter is high? 

Select a better server; e.g. one with a better network connection.

> reading is very low, but there are other times when I'm showing 
> several hundred us (assuming that the readout is in ms). How do you 
> track down and kill jitter or do you worry about it (and at what 
> level do you worry about it)?
> So, putting this all together, to find your best approximation of 
> UTC, do you take the clock time +delay +offset + jitter, or is that 
> all handled internally by ntp? ie., how far off is my reference 
> system from utc?

The PPS signal generated by your GPS receiver is probably within 50ns of 
the top of the second.  Some inaccuracy is introduced by the hardware in 
your computer; it takes time for the signal to reach the processor and 
for the processor to respond.  You can usually expect your computer to 
be within 1-10 microseconds of the correct time

Ntptime will show you the estimated error of your local clock.


More information about the questions mailing list