>>> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Kevin Oberman) writes:
>> From: Martin Burnicki <[EMAIL PROTECTED]> >> 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 <[EMAIL PROTECTED]> http://ntpforum.isc.org - be a member! _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
