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

Kevin Oberman oberman at es.net
Sun Mar 29 05:30:07 UTC 2009


> From: Unruh <unruh-spam at physics.ubc.ca>
> Date: Sun, 29 Mar 2009 04:16:23 GMT
> Sender: questions-bounces+oberman=es.net at lists.ntp.org
> 
> oberman at es.net (Kevin Oberman) writes:
> 
> >> From: Harlan Stenn <stenn at ntp.org>
> >> Date: Sat, 28 Mar 2009 08:48:35 +0000
> >> Sender: questions-bounces+oberman=es.net at lists.ntp.org
> >> 
> >> >>> In article <FOjzl.18914$Db2.8066 at edtnps83>, Bill Unruh <unruh at physics.ubc.ca> writes:
> >> 
> >> > Harlan Stenn <stenn at ntp.org> writes:
> >> >> From one POV, it seems to me that each "instance" of a PPS source should
> >> >> come with "health information" about that PPS instance.  This "health"
> >> >> information should include the current expected precision of the PPS
> >> >> signal.
> >> 
> >> 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 suspect there are other, similar situations with other devices.
> >> 
> >> >> Some PPS devices are "stand-alone" while others are "combined" with, say,
> >> >> a GPS signal.
> >> 
> >> >> For the former case, it makes sense to treat them as separate sources of
> >> >> time.
> >> 
> >> >> For the latter, it makes sense to treat the PPS signal as an "adjunct"
> >> >> device.
> >> 
> >> Bill> Well, I would say that the GPS is the adjunct device since the PPS is
> >> Bill> far far more accurate (4 orders of magnitude).
> >> 
> >> That may be, but the smarts for the driver are in the GPS side of things,
> >> not on the PPS side of things.  We'd probalby want the config file to say
> >> things like "I'm an XYZ refclock that has a PPS signal", instead of "I'm a
> >> PPS signal that comes from an XYZ device".
> >> 
> >> If the final code can handle this either way I don't care.  But I figure
> >> there is a good chance it will not be that way.
> >> 
> >> >> See http://support.ntp.org/bin/view/Dev/GettingNtpdItsConfiguration for
> >> >> more information.
> >> 
> >> >> The bottom line is we need to figure out what else needs to be done to
> >> >> make the "state of affairs" with PPS sources even more generally useful.
> >> 
> >> Bill> Clearly the PPS needs something auxilliary to determine the
> >> Bill> seconds. On the other hand, once that second lock is obtained it is
> >> Bill> hard to lose it. The system clock on most computers is not going to
> >> Bill> drift by 500,000 PPM (especially not most time servers).
> >> 
> >> For me, the issues for a PPS source is how much can we believe the PPS
> >> signal arrives at the instant of the stroke of the second.
> >> 
> >> That is a separate issue from "about what time is it".
> >> 
> >> Bill> Now maybe I am not imaginative enough to think of what could go wrong.
> >> 
> >> I know I'm not.
> >> -- 
> >> Harlan Stenn <stenn at ntp.org>
> >> http://ntpforum.isc.org  - be a member!
> >> 
> >> _______________________________________________
> >> questions mailing list
> >> questions at lists.ntp.org
> >> https://lists.ntp.org/mailman/listinfo/questions
> >> 
> 
> >This has been a real issue for us. We have about 26 ntp servers
> >scattered across our network using CDMA clocks. There are a few places
> >where the signal is poor and clock will lose sync. 
> 
> >When this happens, the PPS continues, but will slowly drift with respect
> 
> You mean the cdma clock will continue to deliver a PPS signal running it
> off an internal drifting clock? A PPS is simply a pulse every second. How
> does it deliver the information that it is bad? Or you know it is bad
> because it starts to drift with respect to other clocks you trust more?
> And why do you trust them more?

Yes. The clock free runs and continues to deliver PPS and time from it's
internal oscillator (which is quite a bit more accurate than most PC
oscillators, but still drifts over a period of days). It marks the time
as unsynchronized and ntpd treats it as such. It does not use it.

I know it is bad because I have 25 clocks to compare with. Of those, 20
are stratum 1, so it's pretty obvious when the others show time within a
few microseconds and this one is off by milliseconds after a couple of
weeks or so.

> 
> 
> >to actual time. Unfortunately, even though the time from the clock is
> >marked as unsynced and ntpd stops using that time, it continues train
> >the time with the drifting PPS signal, so the time slowly drifts away
> >from where it should be.
> 
> What refclock driver are you using?

TrueTime (5) and PPS (22). The clock is an Endrun Technologies Præcis Ct.
http://endruntechnologies.com/network-time-source.htm

> 
> >Ideally, if the source of the time being trained by the PPS is bad, the
> >PPS also should be considered bad and kernel PPS should be disabled.
> 
> And how does it know that the time being trained by the PPS is bad?

It is marked as unsynchronized by the clock.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751



More information about the questions mailing list