[ntp:questions] nptq -p slowness

Danny Mayer mayer at ntp.isc.org
Mon Jan 29 13:08:43 UTC 2007


Harlan Stenn wrote:
> Dave,
> I believe the desired goal is to display the refid field in 2 forms:
> 
> - the "string" form in the case of a refclock
> - a non-IPv4 format otherwise
> 

These are both string formats. There are no non-IPv4 formats.

> The last time I talked to you I recall you said you wanted to keep the IPv4
> format because it helped you understand exactly what machine was being
> referenced.

Nevertheless this is just a string. The only thing that the ntpq code
does is add periods to the beginning and end of a refclock type. We
should never be performing lookups since a refid just looks like an IPv4
address but should not be confused with one.

> 
> This topic is being discussed at:
> 
>  http://ntp.isc.org/bin/view/Dev/UpdatingTheRefidFormat
> 
> and I believe the issue is now more complicated because we can now specify
> an arbitrary stratum for a refclock, which means we can no longer use the
> stratum as the means to decide if a refid is the name of a refclock or not.
> 

The code doesn't do that anyway, it never looks at the stratum before it
tries to interpret the refid. In fact it attempts to do a DNS lookup
first before it tries to decide if it's a refclock, irrespective of the
contents of the refid. See doprintpeers() in ntpq/ntpq-sub.c.

> It should be pretty easy to stop doing DNS lookups on the refid.
> 
> It may be more Interesting to do more, as I am no longer sure we can
> cleanly decide when a refid refers to a refclock or not.
> 

You need to look at the code, but it's very straightforward to decide that.

Note that there's a second issue in that the remote names can also not
be IP addresses and that is what I think you are talking about rather
than the refid.

Danny



More information about the questions mailing list