[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 mailing list