[ntp:questions] Troubleshooting who's at fault
davehart at gmail.com
Sat Jun 27 09:32:37 UTC 2009
Terje Mathisen wrote:
> David Woolley wrote:
>> Ronan Flood wrote:
>>> The question remains why the Brandywine PTS device is claiming synch
>>> to LOCAL(O) with stratum 2.
>> I suspect it is using the local clock driver for its original purpose,
>> i.e. to propagate the value of a disciplined local clock that is
>> disciplined by something other than ntpd.
> This is of course a perfectly valid configuration, except that in this
> case you should definitely use the fudge command to set the name of the
> clock to something that describes it somewhat better, i.e. something
> like "RB" or "PTS" in this case.
Good point. I'm still wondering about the stratum 2 part as well. As
quoted earlier by another, the code disagrees with Dr. Mills regarding
loop detection treating stratum 1 exceptionally, so if the device was
reporting stratum 1 as expected, the loop detection would not have
fired. Here's the relevant snippet from the current code (4.2.5p184 I
believe). TEST12 translates to the peer_loop flash code:
* A loop error occurs if the remote peer is synchronized to the
* local peer or if the remote peer is synchronized to the same
* server as the local peer but only if the remote peer is
* neither a reference clock nor an orphan.
if (peer->stratum > 1 && peer->refid != htonl(LOOPBACKADR) &&
(peer->refid == (peer->dstadr ? peer->dstadr->addr_refid :
0) || peer->refid == sys_refid))
rval |= TEST12; /* synchronization loop */
More information about the questions