[ntp:questions] Troubleshooting who's at fault

Ronan Flood 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 mailing list