[ntp:questions] LOCL clock reachability not 377?

Martin Burnicki martin.burnicki at meinberg.de
Thu Jul 31 14:31:08 UTC 2014


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.


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


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.


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. ;-)


In order to have some plausibility check, in case 1) the refclock 
(including PPS source) could me detected and marked as falseticker if 
the time-and-pps deviates more than a certain limit from other time sources.

For cases 2 it could be good to be at least able to specify that the 
absolute time (and leap second warning, etc.) shall be derived from some 
other source, e.g. the system peer determined by the usual algorithms.

Unlike otherwise stated in this thread I don't think it's a good idea to 
leave the 1 PPS signal alone disciplining the time of the NTP server. 
This can easily yield unforeseen problems, similarly as if you use an 
IRIG time reference which only provides day-of-year and time-of-day, but 
no year number. If you don't take care then such signal can be accepted 
and provide a "valid" time which is off by an integral number of years.

I don't think this would be acceptable for environments where an 
accurate precise time is most important.


Since the NTP daemon is unable to know the precision and stability of a 
PPS source just from the PPS slopes the concept of a trust time could 
help fine-tuning a configuration in which several PPS sources of 
different quality are available.


Beside the implementation of such a flexible concept in ntpd it would 
have to be discussed how this can easily be configured. With NTP's basic 
configuration syntax in mind a possible way could be something like this:

# a refclock with PPS signal but no good oscillator
server 127.127.8.0
server 127.127.22.0 ref 127.127.8.0

# a refclock with PPS signal and good oscillator
server 127.127.8.1
server 127.127.22.1 ref 127.127.8.1 trust 3600

# a PPS source relying on the usual system peer to
# provide absolute time
server 127.127.22.2 ref sys_peer

# a PPS source which should be trusted always
server 127.127.22.3 trust always


Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany



More information about the questions mailing list