> From: Unruh <[EMAIL PROTECTED]> > Date: Wed, 24 Sep 2008 18:10:24 GMT > Sender: [EMAIL PROTECTED] > > > [EMAIL PROTECTED] (Kevin Oberman) writes: > > >> 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. > > I at least am confused. What is generating the pps signal. I would have > thought it was the hardware clock that you say is misbehaving. If so it > should not send out a PPS signal at all. Or is it your computer itself that > is sending out a PPS based on its own clock? In that case you certainly > should NOT be using it as a source of time.
The clock, for better or worse, tags the time it supplies with an accuracy character which indicates accuracy, but the lack of accuracy does not cause the PPS to stop. This includes complete loss of accuracy. The clock keeps running and keeps time, but it is now limited to the accuracy of the internal clock in the reference clock. This is what was drifting, not the system clock. It was simply dragging the system clock along for the ride. > >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 > > If the reference clock is bad it should not be sending out a PPS. Why is it > doing so? Because it does. I can contact EndRun about it. I agree that it would be best if the clock stopped the PPS, but ntpd could do the same things and I see no reason that it should enable PPS_SYNC until the PPS is marked as ready and should be disabled when the PPS is no longer marked as valid. It marks the PPS validity in 'ntpq -p', so it knows whether it considers PPS valid. Why should it allow the PPS_SYNC when it has PPS no marked valid?. > >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. > > If that pps is really not a good pps source coming from an idependent > harware time source, it should not be enabled at all. If the clock is getting a good signal, the PPS is valid. If it is not getting a signal, it is only as accurate as the internal clock in the device. -- 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
