[ntp:questions] Stick to PPS, even if the prefer server fails

Unruh unruh-spam at physics.ubc.ca
Thu Mar 26 15:52:05 UTC 2009


"alkopedia at googlemail.com" <alkopedia at googlemail.com> writes:

>On Mar 26, 5:46=A0am, Unruh <unruh-s... at physics.ubc.ca> wrote:
>> So, I have PPS running the shm refclock, with the seconds supplied by the
>> local clock (ie the reading from the system clock) and the usec from the
>> PPS signal. =A0Since I do not expect the local clock to suddenly shift by=
> a
>> second, its usec discipline should be fine. I mark it as the preferred
>> server. (The PPS shm is run only once the local clock is disciplined to
>> within .1 sec by the other sources).

I have now looked at the refclock_atom source and indeed, it demands that a
prefer clocksource is available, and ignores the PPS if it is not. This I
believe is a bug, or at least a design infelicity. You could either hack
the source ( put in a flag so that if once the PPS was accepted, it would
continue to be accepted even if the prefer source disappeared. One could
perhaps set it up to timeout after some time so that if the prefer source
never came back up in say 3 days, ntp would finally start to disregard the
PPS.) Alternatively you could use a different input route for the PPS--
like the shm refclock with shmpps or gpsd to feed the shm refclock. That
does not have the logic that the refclock_atom does or disregarding the
input if another input is not there. 
Note that if one does set up the atom driver with the flag, the tolerance
of .4 sec should probably be decreased to say .1 sec to make sure that the
ntpd discipline routine did not drift off out of .5 sec bounds before
settling down to properly disciplining the clock. Although that should not
happen. 

 

>This could be a good idea in my opinion, but someone with better
>knowledge should comment that.
>I'm trying this right now. As soon as the GPS/DCF gets dark, the LOCAL
>clock is used as prefer peer and PPS is still used to sync. Only thing
>that comes to my mind are leap seconds: As the RTC is only synced by
>the kernel every 11 minutes, it could cause troubles when the LOCAL
>clock suddenly is 1 s off GPS/DCF. But I guess it will be marked as
>false ticker until the next kernelsync.

The local clock is not the rtc. The local clock is simply the system clock,
the same clock you are trying to discipline. It is not clear to me that
making thelocal the prefer clock does what you need for the atom driver,
because I have not disentangled the logic of the "Selection and mitigation
algorithm" whose description David Mills pointed me to. The local clock
appears to be treated specially within this algorithm.
So Yes, If the prefer clock went down for days before a leap second, then
your system would have no way of knowing a a leapsecond was coming and
would presumably coast on without the leapsecond. That might be a reason to
put in a limit on the length of the coasting for the PPS clock. 
Presumably if the leapsecond flag had been set on the leapsecond day
sometime, that leapsecond would actually get dealt with. Or if the
leapsecond file were installed. Even if the PPS were coasting.





More information about the questions mailing list