[ntp:questions] On jittery clocks and precision PPS signals
David L. Mills
mills at udel.edu
Mon Feb 14 02:38:06 UTC 2005
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 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 time.
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.
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.
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