[ntp:questions] nptq -p slowness

Danny Mayer mayer at ntp.isc.org
Mon Jan 29 13:15:14 UTC 2007

Maarten Wiltink wrote:
> "Richard B. Gilbert" <rgilbert88 at comcast.net> wrote in message
> news:2LGdnbKXL8u5HyDYnZ2dnUVZ_u2mnZ2d at comcast.com...
>> Harlan Stenn wrote:
>>> In article <0eednfx366oTvCDYnZ2dnUVZ_u-unZ2d at comcast.com>, "Richard B.
> Gilbert" <rgilbert88 at comcast.net> writes:
>>>> The bug is that ntpq should not be interpreting the refid at all!
>>>> It's a text string, not an IP address and should not be treated as
>>>> one.  Yes, sometimes the refid IS an IP address but it still should
>>>> be treated as a simple text string!
>>> How can the code tell the difference between a refid that is a string
>>> and one that is an IP address?
>> ISTR reading something from Dave here to the effect that the REFID was
>> NOT an IP address even if it had the form of an IP address.
> IIRC, it's either a string (for reference clocks) or a hash (for ipv4/6).
> For ipv6, the original address can't be recovered. For ipv4, the hash is
> an identity transform and people forget it's not really an address.
> Only the upstream server knows how it got that refid. The local host can
> but guess. Perhaps tag bits are in order; certainly it's nice for humans
> to see hostnames (and refclock names) where applicable and possible.

It only makes sense for refclocks. Otherwise use dig to do lookups if
the refid is really an IPv4 address.


> Groetjes,
> Maarten Wiltink

More information about the questions mailing list