[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 22.214.171.124 3 u 47 64 377 62.065 4.289 2.750
> +boudicca.tux.or 126.96.36.199 2 u 12 64 377 63.289 -5.525 2.273
> -dake.desynched. 188.8.131.52 2 u 18 64 377 55.516 4.039 2.726
> -veritas.imagepi 184.108.40.206 2 u 60 64 377 51.816 -8.385 2.495
> -hudson.yutanigl 220.127.116.11 2 u 20 64 377 50.768 -5.847 14.944
> +ferocious.dairi 18.104.22.168 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
> 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.
> 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