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 _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions