> From: Martin Burnicki <[EMAIL PROTECTED]> > Date: Wed, 24 Sep 2008 09:24:43 +0200 > Sender: [EMAIL PROTECTED] > > > Kevin, > > Kevin Oberman wrote: > [...] > > Another thought...could it be PPS that is causing it? After all, the pin > > on the bulkhead connector is still getting the PPS signal. I am using the > > kernel PPS implementation, so could that be training the kernel even > > though ntp is not using it? > > That's also what I've got in mind when I read you latest posts. > > Can you disconnect the PPS signal and see what's happening?
Martin, We have a winner! It is the PPS. If I take that out, it syncs correctly to all of the other systems. Looks like PPS will train whatever sync source is selected, not just the reference clock. So it was reference clock drifting off time with no input signal, marking the time as inaccurate so that ntpd was ignoring it, but still sending out the PPS such which the system was still listing to via the kernel NTP_SYNC, but was training the clock without paying any attention to the validity or presence of time from the reference clock. It looks like ntpd should be disabling PPS_SYNC when the reference clock is bad, but is not doing so. Note: I am referring ONLY to the kernel using PPS_SYNC. ntpd, itself seems to not pay attention to PPS unless the reference clock is selected for sync. If I get some time, I'm going to look at the PPS code in ntpd and see it this can be done easily. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
