[ntp:questions] Stick to PPS, even if the prefer server fails
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.
> >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