David Woolley <da...@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 <use...@umbral.org.uk> _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
