[ntp:questions] Re: how to read and understand ntpq -pcrv output - pre-wiki
david at djwhome.demon.co.uk
Tue May 16 06:23:44 UTC 2006
In article <pan.2006.05.16.02.49.34.680360 at derobert.net>,
Anthony DeRobertis <netnews at derobert.net> wrote:
> On Mon, 15 May 2006 18:42:29 +0000, Jim Cromie wrote:
> > ? refid - Ive seen other listings with different stuff here,
At the moment, you really need to be prepared to read the source code if
you want to accurately document this sort of thing for version 4 and you
need to spend a lot of time understanding RFC 1305, for version 3.
> > PGOA ?
> > PPS - pulse per second - usually off an atomic source, maybe GPS they
All NTP times should be off an atomic source, in this respect, and
not just any atomic source, but rather one that is traceable to UTC.
GPS is just another secondary source (and normal GPS receiver do not use
atomic clocks in themselves, so are secondary to atomic sources, as well
as to UTC), in the same way as an upstream server is a secondary source.
(Obviously people who use .LCL. as a source and don't lock it to UTC by
other means, violate this principle.)
> > mostly look like IPs,
> > are they some kind of hierarchy id, ie hash on path of clock-refs /
> > system peers?
Other than the special ones used for non-NTP protocol sources, this is an
opaque number that is used for loop prevention. For IPv4 upstream servers,
it happens to be the IP address, but this is no longer true for IPv6
> Your system's primary peer (forget the right term), the one marked with a
> * in the peers output, is what other people will see in the refid field.
> The refid is "where did that machine get its time from?"
Although the actual time is influenced by the sources marked with +, as well.
> The maximum amount your clock can be off (assuming the peer's clock is
> right) is 1/2 of the delay.
At best, that is only true at the instant (noting that the process
isn't really instantaneous) that the poll was made. In practice, the
protocol conveys additional information to allow an estimate of the
error in the upstream source to be made.
> Offset how much your clock is off, according to the most recent response
> from that peer.
How much it differed from that peer at the time of the poll.
> Jitter is, I think, how much offset is jumping around from packet to
It also includes the uncertainty due to the limited precison with which
the local clock can be read.
> [Sorry for ignoring the rest of the questions. I'm not quite sure what
> rootdispersion, etc. is. I think you're right about frequency, though]
rootdispersion is, for version 3, the estimate of the total worst case
accumulated error since the stratum 0 clock reading that was used, and
includes an allowance for a drift rate error and other factors. It
is quite complex in version 4 and, whilst I've traced it through in the past,
I don't remember enough details to try to reliably document it here.
rootdelay is the cumulative delay value. All of these exclude the most
You almost certainly ought to use the Wikipedia rules here and only
include information that you can trace to primary sources, which means
basically: the source code, RFC 1305 and papers by Dr Mills. (I know that
much of Wikipedia violates this principle.) As such, all of the above
is only to help you in the reading of the primary sources and you should
not rely on it.
More information about the questions