[ntp:questions] On jittery clocks and precision PPS signals

[David L. Mills]

Folks,

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.

Dave