[ntp:questions] Troubleshooting who's at fault
usenet at umbral.org.uk
Fri Jun 26 11:34:11 UTC 2009
David Woolley <david at ex.djwhome.demon.co.uk.invalid> wrote:
> Harlan Stenn wrote:
> > If you are using LOCAL as a fallback on your client, and your upstream
> > server is using LOCAL ias the name for its PTS-sync'd refid, then the client
> > just sees that the 2 sources it knows about are using the same refid and
> > will flag that as a loop.
> That doesn't sound sensible. It implies you cannot peer two machines
> that have the same reference clock technology. Is the problem that
> reference clocks, as a special case, use the same reference ID as the
> stratum 1 server that uses them, and, by the time the check is done, the
> distinction between a reference clock and a server has been lost?
The loop test (ntp_proto.c/peer_unfit) only applies if the peer stratum
is greater than 1, so not to similar refclocks.
In 4.2.0 (ntp_proto.c/peer_unfit) the test starts
(peer->stratum > 1 && peer->refid == peer->dstadr->addr_refid)
In 4.2.2 this is adjusted to
(peer->stratum > 1 && peer->refid != htonl(LOOPBACKADR) &&
(peer->refid == peer->dstadr->addr_refid || peer->refid == sys_refid))
which implies that the OP's RHEL server is running 4.2.0 as it sees
127.0.0.1 as a loop.
The question remains why the Brandywine PTS device is claiming synch
to LOCAL(O) with stratum 2.
Ronan Flood <usenet at umbral.org.uk>
More information about the questions