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 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 > <snip? > '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. >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? 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. <snip> _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
