[ntp:questions] LOCL clock reachability not 377?

Harlan Stenn stenn at ntp.org
Thu Jul 31 19:08:53 UTC 2014

Martin Burnicki writes:
> Miroslav Lichvar wrote:
> > 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.
> This sounds good. I think we'd have to distinguish some basic cases a 
> few of which immediately come to my mind:
> 1) A refclock provides absolute time, status, and a PPS signal
> 1a) The refclock contains a good oscillator, so the PPS signal could be 
> accepted for some time after the refclock started freewheeling.
> 1b) The refclock only has a simply xtal which starts drifting 
> immediately when the refclock starts freewheeling.

In either of these cases we could have a parameter for the appropriate
value of PHI for that clock.

> 2) A good PPS signal is available, but no absolute time (e.g. in case of 
> a Rubidium)
> 2a) Some status information is available telling if the PPS signal is 
> "good" or not
> 2b) No information on the PPS quality is available

Agreed - I've been trying to "sell" DLM on this idea for years.

> Case 1a) or 1b) is usually true for most GPS receivers.
> 1a) is for example the case for Meinberg GPS receivers, which have a 
> good oscillator (TCXO or even OCXO) on board, but in contrast to the 
> GPSDO mentioned by Rob, which doesn't provide absolute time, the 
> Meinberg devices do.
> NTP's parse driver supports the concept of a "trust time" which means 
> that *if* the time source has been synchronized and then starts 
> freewheeling you can configure a time interval during which the parse 
> driver doesn't tell ntpd that the refclock has started freewheeling, and 
> thus the refclock plus associated PPS signal are still accepted for that 
> interval. So only after the trust time has been expired the PPS signal 
> is discarded.
> 1b) is the case for most cheap GPS receivers. If they loose the 
> satellite signal they often start drifting quite a lot, in which case it 
> could make sense to discard the PPS signal immediately.
> In terms of the trust time mentioned in 1a) this would mean the trust 
> time is very short, or even 0.

If the value of phi cannot be easily measured (or is not provided by the
manufacturer), this would be a better choice.

And the General Timestamp API (GTSAPI) project from NTF would nicely wrap this
information into a timestamp for you, directly.

> For cases 2a) and 2b) there is no absolute time available from the PPS 
> source. If a status is available this could be evaluated, eventually 
> with a trust time. If no status is available you simply could always 
> trust the PPS source (unlimited trust time), or you shouldn't use it as 
> reference time source. ;-)

If devices that do not have absolute clocks have a way to track relative
time the GTSAPI would provide the error bounds information usefully
there, too.
Harlan Stenn <stenn at ntp.org>
http://networktimefoundation.org - be a member!

More information about the questions mailing list