[ntp:questions] nptq -p slowness

David L. Mills mills at udel.edu
Tue Jan 30 19:02:09 UTC 2007


Harlan,

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.

Dave

Harlan Stenn wrote:
> Guys,
> 
> 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
> stratum:
> 
> - 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.
> 
> H




More information about the questions mailing list