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

Unruh unruh-spam at physics.ubc.ca
Wed Sep 24 22:15:50 UTC 2008

oberman at es.net (Kevin Oberman) writes:

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

Ah, ok. I now understand. Unfortunately the PPS in ntp is a separate
hardware clock from the others.

There is no necessary link between harware clocks-- ie ntp assumes that
different hardware clocks are independent sources of time. Whether there is
any way of tying them together (Ie, A is a good source of time if and only
if B is a good source of time) I do not know. It could be done I suppose. 

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

the PPS_SYNC flag is AFAIK an indication as to whether ntp regards the
internal clock as synchronised to the PPS, not whether it thinks the PPS is
a good source of time. ntp has no way of knowing if a hardware time source
is a good source of time or not, especially if there are only two of them.
It has no idependent measures. 

Especially with a hardware time source, it must assume that that source is

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

But how does ntp know that? It has no idea that the PPS signal has anything
to do with the cdma time. You PPS could be from a GPS sattelite, and thus
be a better source of time than the cdma signal. It cannot know that. 
I have a pps on my system which I drive via a parallel port module. I could
have another device attached to my serial port-- perhaps oneof your cdma
clock sources. If the pps stops and no more signals come, then the pps will
fail. If the pps keeps sending signals approx once per second, ntp HAS to
assume that they are good. 

More information about the questions mailing list