[ntp:questions] nptq -p slowness

Danny Mayer mayer at ntp.isc.org
Wed Jan 31 05:43:45 UTC 2007

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

Guys, we need to stop this. You are all making wild assumptions about
what gets returned to ntpq and what it does with the data. None of them
are correct. It pays to look at both the data and what ntpq does with it
in the code.

Here for example is the data returned to ntpq with just the -p option
for pogo.udel.edu:

"srcadr=, srcport=123, dstadr=, dstport=123, leap=0,
stratum=0, precision=-13, rootdelay=0.000, rootdispersion=1.000,
refid=GPS2, reach=0xff, unreach=0, hmode=3, pmode=4, hpoll=6, ppoll=10,
flash=0x0, keyid=0, ttl=0, off"

What's the refid here? GPS2! What does ntpq -p display?
     remote           refid      st t when poll reach   delay   offset
+SPECTRACOM(1)   .GPS2.           0 l   69   64  377    0.000    0.065

Here's a different response data:

"srcadr=, srcport=123, dstadr=, dstport=123,
leap=0, stratum=2, precision=-17, rootdelay=1.511,
rootdispersion=24.109, refid=, reach=0xff, unreach=0,
hmode=3, pmode=4, hpoll=6, ppoll=6, flash=0x1000, keyi"

This time the refid looks like an IPv4 address. This time this is what
you get:

     remote           refid      st t when poll reach   delay   offset
 time1.chu.nrc.c    2 u   73   64  377   53.945   -0.432

So can someone tell me what problem they are trying to solve? It has
nothing to do with refid's which are completely clear.

What the code DOES do and should not do is the following:

a) try and convert the refid into an intenet name for the address, ie a
DNS lookup;
b) if that fails and the length of the refid data is <= 4 assume it's a
refclock code (like GPS) and surrounds it with dots.

It's a) which causes the problem and is completely unnecessary.

Does this make the issue clearer?


More information about the questions mailing list