[ntp:questions] Odd (mis)behavior when reference clock fails
oberman at es.net
Wed Sep 24 19:38:02 UTC 2008
> From: Unruh <unruh-spam at physics.ubc.ca>
> Date: Wed, 24 Sep 2008 18:10:24 GMT
> Sender: questions-bounces+oberman=es.net at lists.ntp.org
> oberman at es.net (Kevin Oberman) writes:
> >> From: Martin Burnicki <martin.burnicki at meinberg.de>
> >> Date: Wed, 24 Sep 2008 09:24:43 +0200
> >> Sender: questions-bounces+oberman=es.net at lists.ntp.org
> >> 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?
> >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
> >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
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at es.net Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
More information about the questions