[ntp:questions] Stick to PPS, even if the prefer server fails
John Ackermann N8UR
jra at febo.com
Sat Mar 28 11:34:18 UTC 2009
Harlan Stenn said the following on 03/28/2009 04:48 AM:
> Bill> Not sure what the health info would be. The health of PPS is either
> Bill> great, (if the seconds is good) or attrocious (if the second is bad),
> Bill> and the driver presumably does not know this or it would have
> Bill> corrected the seconds (remember that this is like the date being a
> Bill> month out, if your accuracy was a second).
> There are at least two issues here.
> In one case, there can be a GPS device that may deliver a PPS second but
> that PPS is not really sync'd. The GPS device in this case will usually
> have this information ([do not] believe the PPS signal) in there.
> In another case, the Stanford Research PRS10 rubidium frequency standard has
> an RS-232 output port that has diagnostic info, including letting you know
> if the device is in its "warming up" state, which means during those 6 or 7
> minutes the pulse is not yet as accurate as it should be.
I'm not sure if the PRS10 health info is really that helpful, for NTP
purposes. Even when the Rb is warming up, or out of lock, it will still
be far more stable and accurate than any mobo rock. e.g., in the first
minute after power-up it might be parts in 10e6 off, and that error will
close very rapidly as it warms. That's a huge error for the time-nuts
crowd, but still not bad in the NTP world.
The real problem is determining whether a PPS source is accurately
synced to UTC. For example, when the PRS10 is warm and locked, it will
generate a very high quality PPS signal, but by itself that signal will
have a random offset of up to 0.5 second with respect to UTC. It needs
to be sync'd against a UTC source before the PPS is useful for timekeeping.
It seems to me that should be pretty easy to do a sanity check against
external servers -- if the PPS is more than some fairly large number of
milliseconds (ideally, that number should be configurable) off of some
known sane external servers, we can assume it is not sync'd and ignore
it. Within that window, assume that it's the most accurate clock in the
More information about the questions