[ntp:questions] nptq -p slowness
David L. Mills
mills at udel.edu
Tue Jan 30 19:02:09 UTC 2007
Correct your notes.
A KoD packet by definition has leap bits 11 (unsync) and stratum zero
(unspec) and shows refid a 4-character kiss code (which includes zero as
a no-op). Note we are talking about the packet on the wire; ntpd maps
zero on the wire to 16 in the code. In all other cases the packet
contains the system refid, however that is determined.
If the system peer is a refclock (stratum 0), the system refid is the
clock refid, which normally is a 4-character string. Some reference
clock drivers change this on-fly.
If operating in orphan mode and the host is the orphan parent (stratum
greater than 0), the system refid is the loopback address.
In all other cases the system refid is either the IP4 source address or
IPv6 source address hash for the system peer; that is, the source from
which the system variables are inherited.
Be truly advised the purpose of the refid is not for pretty display; the
purpose is to detect and reject timing loops. A timing loop is defined
where the other guy is synchronized to me or where both of us are
synchronized to the same server. Yes, there are some potentially ugly
consequences where a mixture of IPv4 and IPv6 addresses are in use.
For ntpq the choices are: If the peer shows leap 11 and stratum 0 show
the refid as kiss code. Otherwise, if stratum 1 show the refid as ASCII
string. Otherwise, show a dotted quad on the understanding that, if it
doesn't look like a IPv4 address, it probably isn't.
The most common misinterpretation might be the local clock driver
operating at elevated stratum. The present rules show an ugly
dotted-quad string. The local clock driver should change its refid to
the loopback address.
Harlan Stenn wrote:
> I think the "decode the refid" problem is just a bit more difficult than we
> have been discussing.
> My notes on this show that we *used* to be able to decode the refid based on
> - S0: the refid contains a KOD code
> - S1: the refid is the refclock type
> - S2+: the refid contains a "token" that IDs the server we are syncing with
> and for the S2+ case, if the remote server is giving us an IPv4 address then
> the refid is that IPv4 address.
> There are now 2 additional complicating matters
> - the address can be IPv4 or IPv6, and we do not seem to have a way to
> know which it is
> - A refclock can now advertise as being "worse" than S1
> We already sometimes have to follow the associd chain - I am wondering if we
> may need to do something similar here.
More information about the questions