[ntp:questions] LOCL clock reachability not 377?

Martin Burnicki martin.burnicki at meinberg.de
Fri Aug 1 09:00:47 UTC 2014


Harlan Stenn wrote:
> 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.

Yes. the problem is where to get it from.

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

;-) or better :-(

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

Of course there's a large difference between cheap crystals and good 
oscillators, but even in case of a GPS disciplined oscillator the 
resulting drift may depend on how good the oscillator has been 
disciplined before.

I think the trust time concept is easy to be understood by normal users 
and allows to take also into account which accuracy is required by 
certain applications.

 From my experience many users are only interested in a "network" time 
which is accurate to the second, so that e.g. their outgoing emails have 
the "right" time. If they have a "good" refclock then these folks 
usually select a large trust time since the refclock is more stable than 
the PC's time, even when it is freewheeling.

On the other hand there are applications requiring highest possible 
accuracy, in which case the best value for a trust time can be 
determined if the characteristics of the refclock/PPS source are known.

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

The GTSAPI is probably good for applications, but IMO internally ntpd 
should take care of the time stamps and time differences by itself.


Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany



More information about the questions mailing list