[ntp:questions] Monitoring NTP - nptq -p

Keith E. Brandt, M.D. wd9get at amsat.org
Wed Mar 21 00:33:17 UTC 2007


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    130.126.24.44    3 u   47   64  377   62.065    4.289   2.750
+boudicca.tux.or 65.212.71.102    2 u   12   64  377   63.289   -5.525   2.273
-dake.desynched. 132.163.4.103    2 u   18   64  377   55.516    4.039   2.726
-veritas.imagepi 67.128.71.76     2 u   60   64  377   51.816   -8.385   2.495
-hudson.yutanigl 128.252.19.1     2 u   20   64  377   50.768   -5.847  14.944
+ferocious.dairi 140.142.16.34    2 u   18   64  377  119.579   -0.465  11.587

The first several columns are pretty straight forward. 'Remote' - 
what peer ntp is getting info from; 'refid' - what source the peer is 
using for its reference; 'st' - the stratum of that peer; and 't'the 
type of peer - l being a local reference and the u by the remote 
peers meaning unicast.
'When' is how long ago that a packet was received from that peer.

'Poll' is the polling interval in seconds, which seems to vary quite 
a bit on my system, so here's the first real question - how does ntp 
pick the polling interval (a pointer to the docs is fine, I just 
haven't been able to uncover it yet).

'Reach' is explained very nicely in the ntp faq at 
http://www.ntp.org/ntpfaq/NTP-s-trouble.htm#Q-MON-REACH.

'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?

'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?

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. 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? This 
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?

I know these are rather basic questions and I thank you in advance 
for helping me round out my knowledge of how this all works.

Keith

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
LtCol Keith E. Brandt, MD, MPH
USAF-NASA Aerospace Medicine Liaison Officer
Johnson Space Center, Houston, Texas
wd9get at amsat.org

Goodbye cruel world that was my home-
   there's cleaner space out here to roam
Put my feet up on the moons of Mars-
   sit back, relax, and count the stars

*This message transmitted with 100% recycled electrons  




More information about the questions mailing list