[ntp:questions] Stick to PPS, even if the prefer server fails

Harlan Stenn stenn at ntp.org
Sat Mar 28 19:27:46 UTC 2009


>>> In article <49CE0B3A.9030707 at febo.com>, jra at febo.com (John Ackermann N8UR) writes:

> Harlan Stenn said the following on 03/28/2009 04:48 AM:
>> 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.

This first case is significant in that ntpd needs to know if the PPS should
be believed or not.

>> 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.

John> I'm not sure if the PRS10 health info is really that helpful, for NTP
John> purposes.  Even when the Rb is warming up, or out of lock, it will
John> still be far more stable and accurate than any mobo rock.  e.g., in
John> the first minute after power-up it might be parts in 10e6 off, and
John> that error will close very rapidly as it warms.  That's a huge error
John> for the time-nuts crowd, but still not bad in the NTP world.

These two worlds are getting closer and closer all the time, and I'd like to
make that "journey" as easy and useful as possible.

This also goes to "truth in advertising".

I believe there is benefit if I query an NTP server and it replies "here's
my timestamp and I'm 10e6" because its PRS10 is warming up, and a subsquent
queury says " ... and I'm 10e9" (or whatever).

Likewise, I think it would be swell if a GPS refclock could also have a
sense of its precision based on the number of satellites it sees and how
well it thinks it knows its position.

This information is a bit dynamic, and I think the better we can do at
"shaving the fuzz" (or even knowing exactly where different types of fuzz
are) the better ntp will be able to do its job.

John> The real problem is determining whether a PPS source is accurately
John> synced to UTC.  For example, when the PRS10 is warm and locked, it
John> will generate a very high quality PPS signal, but by itself that
John> signal will have a random offset of up to 0.5 second with respect to
John> UTC.  It needs to be sync'd against a UTC source before the PPS is
John> useful for timekeeping.

>From an audit perspective I wonder what it would take to track "how long has
it been since we had sync" for devices like this.

All I know about the units is what I have read from their website.  Since
they are not far from me when I'm in the Bay area, I figure some day I'll
call them and see if I can visit.

John> It seems to me that should be pretty easy to do a sanity check against
John> external servers -- if the PPS is more than some fairly large number
John> of milliseconds (ideally, that number should be configurable) off of
John> some known sane external servers, we can assume it is not sync'd and
John> ignore it.  Within that window, assume that it's the most accurate
John> clock in the house.

Yup, and then what can/should we do with information like that, as far as
"operational feedback".

-- 
Harlan Stenn <stenn at ntp.org>
http://ntpforum.isc.org  - be a member!




More information about the questions mailing list