[ntp:questions] nptq -p slowness

Maarten Wiltink maarten at kittensandcats.net
Mon Jan 29 08:42:54 UTC 2007

"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.

Maarten Wiltink

More information about the questions mailing list