[ntp:questions] Re: On jittery clocks and precision PPS signals
Ulrich.Windl at RZ.Uni-Regensburg.DE
Mon Mar 7 11:01:14 UTC 2005
"David L. Mills" <mills at udel.edu> writes:
> Three things to report. First, my Arbiter GPS receiver began showing
> intermittent stuck-counter symptoms today, which caused the daemon to
> exit. Surely, this is the preferred behavior; I didn't want the clock to be
Didn't you configure redundant time sources? If so the bad one should have
been ruled out, right?
> set to some time last September. However, the PPS is still good, so I simply
> marked another server prefer and lit it up again.
> Second, a couple comments on the performance of the Arbiter/PPS
> combination. Both the serial timecode and PPS signal routinely show 10-20
> microseconds jitter, which I consider quite good. The surprise is the low
> value for the serial timecode. Ordinarily, I would expect the raw jitter to be
> uniformly distributed over the range 0-1 ms. The trimmed-mean median filter is
> doing a fantastic job to reduce that jitter by two orders of magnitude. At
> least in this case, you don't have to use a PPS signal to get precision
I'm surprised about the high jitter of the PPS!
> Third, GPS radios and PPS signals are getting so good that the we are now
> close to cleaving the microsecond. Problem is, the selection and clustering
> algorithms get very picky when the jitter and wander cool down to this
> order. The result with some jittery radios is the confidence intervals
> sometimes don't overlap and the serial timecode and PPS begin to wander their
> separate ways. The problem gets worse if the timecode and PPS signals are not
> fudged to nearly the same value.
> There are two new options to deal with this problem. The "true" keyword on the
> server line in the configuration file forces that association to always be
> considered a truechimer no matter what. It always survives the selection and
> clustering algorithm and so will always be in the mix to set the clock. Evil;
> don't do that except for testing, as it could well be a falseticker in
> fact. Ergo, my stuck-counter described above.
Ah, you did test "true" then?
> The other option is the "mindist" argument for the tos command. Its value,
> which defaults to 1 ms, represents a pad at either end of every correctness
> interval, increasing the likelihood that the intervals overlap. The value
> should be set just above the sum of the expected difference between the serial
> timecode and PPS signal offsets plus the timecode jitter. A value near 10 ms
> solved some problems here.
Maximums, minimums, average, or 99% confidence interval? ;-)
> The new stuff spins on a distant spot and will probably be scarfed for a
> snapshort soon. The documentation on the web has already been updated.
More information about the questions