[ntp:questions] Odd (mis)behavior when reference clock fails

Kevin Oberman oberman at es.net
Wed Sep 24 16:56:03 UTC 2008


> 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?

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: 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 mailing list