[ntp:questions] LOCL clock reachability not 377?

Miroslav Lichvar mlichvar at redhat.com
Fri Aug 1 09:34:35 UTC 2014


On Thu, Jul 31, 2014 at 04:31:08PM +0200, Martin Burnicki wrote:
> 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

To generalize it a bit more, there could be also a case of a PPS that
is not locked in phase and a case of a PPS that's not even locked in
frequency. When only a source with poor short-term stability is
available, I think it would be pretty cool if it could be combined
with a PPS derived from a cheap TCXO. Doing this in ntpd could be
tricky however.

> 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

This looks good, but shouldn't it be rather specified with a fudge
command?

-- 
Miroslav Lichvar


More information about the questions mailing list