[ntp:questions] Odd (mis)behavior when reference clock fails
stenn at ntp.org
Thu Sep 25 18:43:58 UTC 2008
>>> In article <20080924165603.4711445048 at ptavv.es.net>, oberman at es.net (Kevin Oberman) writes:
>> From: Martin Burnicki <martin.burnicki at meinberg.de>
>> Can you disconnect the PPS signal and see what's happening?
Kevin> We have a winner! It is the PPS. If I take that out, it syncs
Kevin> correctly to all of the other systems.
Kevin> Looks like PPS will train whatever sync source is selected, not just
Kevin> the reference clock. So it was reference clock drifting off time with
Kevin> no input signal, marking the time as inaccurate so that ntpd was
Kevin> ignoring it, but still sending out the PPS such which the system was
Kevin> still listing to via the kernel NTP_SYNC, but was training the clock
Kevin> without paying any attention to the validity or presence of time from
Kevin> the reference clock.
Please see http://support.ntp.org/bin/view/Dev/LoseThePerDriverPPSCode .
Dave, here is more evidence that the current behavior is insufficient and
even potentially wrong.
If you don't like the current proposal, do you have a suggestion for how we
can address the current situation?
Harlan Stenn <stenn at ntp.org>
http://ntpforum.isc.org - be a member!
More information about the questions