[ntp:questions] Troubleshooting who's at fault

Dave Hart 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 */

Cheers,
Dave Hart



More information about the questions mailing list