[ntp:questions] LOCL clock reachability not 377?

Miroslav Lichvar mlichvar at redhat.com
Thu Jul 31 10:28:57 UTC 2014


On Thu, Jul 31, 2014 at 10:43:20AM +0200, Martin Burnicki wrote:
> Rob schrieb:
> >However, that is broken.  Not only do you probably not want to mark
> >that clock prefer (external references are often more accurate than the
> >serial NMEA time, for example), but also you may have two or more ATOM
> >PPS clocks, each with their own status, and there is no way to do that
> >with this method.
> 
> I've already proposed some times ago that another way of assigning PPS
> signal(s) to other time source(s) would be more versatile:
> http://lists.ntp.org/pipermail/questions/2009-April/022599.html
> http://lists.ntp.org/pipermail/questions/2009-April/022600.html
> 
> This would also provide a simple way to declare a PPS signal "reliable",
> e.g. if it is derived from a Rubidium or so, in which case it could continue
> to be accepted even though other time sources become unreachable.
> 
> On the other hand, if a PPS input signal is associated to a particular time
> source the PPS signal could be discarded if the associated time source
> becomes unreachable.

Agreed, it would be useful to have an option to specify the PPS->time
source association for each PPS refclock directly.

In chrony, this is done with the lock refclock option. It's typically
used like this:

refclock SHM 0 offset 0.5 refid SHM0 noselect
refclock PPS /dev/pps0 lock SHM0

The SHM refclock (e.g. GPS NMEA) is configured with the noselect
option so it's never selected and only used by the PPS refclock to
align the pulses to the SHM time. When SHM stops getting new samples
the PPS refclock will stop immediately too.

When the PPS refclock doesn't have the lock option and the local
stratum option is not used, the pulses will be accepted only when the
clock is synchronized, first to another refclock or NTP server and
then possibly the PPS refclock itself. If local stratum is enabled,
the PPS will work immediately without any other sources, but the clock
obviously needs to be already close to the correct time on start,
otherwise it will be off by a whole number of seconds.

-- 
Miroslav Lichvar


More information about the questions mailing list