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