Per Hedeland wrote:
If ntpq -p is showing the two servers listed
(there should always be more than two, BTW) then it's receiving packets
from those servers.
Hm? Yes, ntpq -p is showing two servers - from the original post:
[EMAIL PROTECTED] /]# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
ntp2.<mydomain> 0.0.0.0 16 u - 64 0 0.000 0.000 4000.00
ntp1.<mydomain> 0.0.0.0 16 u - 64 0 0.000 0.000 4000.00
How do you infer from this that it's receiving packets, to me it says
exactly the opposite? Are you saying that the current code will not show
servers that are configured but from which no packets have been
received? That would not be an improvement I think. At least as of
4.2.0, the refid in this case is shown as .INIT., but otherwise the
output is identical to the above (and present).
I've spent a lot of time debugging this stuff. The fact is that if a
server is not reachable in the first place it won't show up in the
scoreboard and there is no association created. A refid of 0.0.0.0
doesn't mean a lot since we don't know what kind of ntp is responding to
the requests. Other implementations may not even set the refid. We don't
know since that not a piece of information we've been given.
The fact that they are both showing stratum 16 on
the scoreboard indicates that neither are able to serve a valid time
because they themselves are not synchronized.
Or, at least "traditionally", that no packets have been received from
them.
No, because there's been no association mobilised.
Danny
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
