[ntp:questions] Re: ntpd+TRIMTSIP+PPS keeps clockhopping

Kevin MacLeod kevin-usenet at horizon.com
Thu Feb 10 03:00:14 UTC 2005


In article <cuebeo$3k9$1 at dewey.udel.edu>,
David L. Mills <mills at udel.edu> wrote:
> Apparently your radio has a very large jitter and a moderate systematic 
> error between the serial timecode and the PPS edge. The intersection 
> algorithm, which is a component of the selection algorithm, occasionally 
> tosses out either the serial timecode or PPS edge.
>
> The problem is to make sure the correctness intervals of the serial code 
> and PPS always overlap. You might have to bias (fudge) the serial code 
> to be closer to the PPS edge. Other fixes might be necessary, but too 
> complicated to list here.

Well, I averaged the peerstats for a "good" day (no spikes) and got an
5228 samples with average of -0.00226848 with a sample standard
deviation of 0.00365921.

So the jitter is as large as the offset.

In any case, I have added

fudge 127.127.22.0 time1 0.0025 stratum 1

The 2.5 ms offset is a slightly expanded average, and hopefully the fudged
stratum will discourage hopping to the serial timecode unless necessary.
(When I put "fudge time1 1", the ntpq offset goes to +1000 (ms), so it
appears that the fudge time should he signed opposite to the offset to
be corrected.)

Unfortunately, I keep getting billboards like
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
x127.127.8.0     GENERIC(0)       1 l    8   16  377    0.000  -13.271   9.239
x127.127.22.0    .PPS.            0 l    4    8  125    0.000   25.048   5.290
x216.53.131.66   129.6.15.29      2 u   99  128   17    9.691   15.938   4.764
x216.53.197.121  66.90.1.128      4 u   99  128   17    9.433  -9369.1  27.209
 144.228.85.50   140.142.16.34    2 u  227  256    3   61.528   22.673   3.559
 198.72.72.10    65.212.71.103    2 u  228  256    3   30.385   17.088   3.660

Which isn't helping much.  The PPS reachability keeps alternating
between 252 (and the serial timecode is selected) and 125,
at which point the falseticker flags change as above.

I.e. it keeps declaring the serial timecode a falseticker, followed by which
the PPS gets disabled, and everything falls apart.  Ick...

So I tried leaving the stratum alone, instead...


Damn... no matter what offset I try, the system evolves from
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+127.127.8.0     .GPS.            0 l   12   16  377    0.000    1.399   8.344
o127.127.22.0    .PPS.            0 l    8    8  353    0.000    0.148   1.388

to
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
x127.127.8.0     .GPS.            0 l    -   16  377    0.000    5.829   5.508
*127.127.22.0    .PPS.            0 l    1    8  327    0.000    0.133   0.703

to
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*127.127.8.0     .GPS.            0 l   10   16  377    0.000    5.829   5.508
 127.127.22.0    .PPS.            0 l   11    8  256    0.000    0.133   0.703

Which is exactly where I don't want to be.  Tha above was with +0.015, which
is better than I've been doing. although still the GPS info is jumping
all over the place:
filtdelay=     0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00,
filtoffset=    7.20   -9.79   -9.18   -1.61   -2.31    9.58   11.97    8.78,
filtdisp=      2.01    2.87    2.26    2.45    2.39    2.90    3.84    3.10

Is there a way to widen the confidence interval to keep the clock from
being delcared a falseticker?

The problem appears to be that without a delay measure, ntpd has a hard time
declaring funny timestamps wrong:
filtdelay=     0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00,
filtoffset=    6.36    0.88    0.01    6.85   -6.52   -5.99   -3.20   -5.40,
filtdisp=      2.93    2.75    2.30    5.16    2.74    3.78    3.28    3.50

Just for example, I just got a billboard of
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*127.127.8.0     .GPS.            0 l   11   16  377    0.000   -7.079  13.564
-127.127.22.0    .PPS.            0 l    8    8  377    0.000   -1.799   0.746

corresponding to a .GPS. filter of
filtdelay=     0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00,
filtoffset=   -7.08    8.15   10.46   -5.27    9.14    8.49    6.22    0.84,
filtdisp=      2.40    1.76    2.35    2.92    3.09    3.17    3.57    3.42

All over the map, sigh.  I just checked and low_latency is set on
the serial port.  This is really annoying...

The pps timestamps are all nice and steady:
filtdelay=     0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00,
filtoffset=   -0.84   -0.87   -0.91   -0.95   -0.99   -1.02   -1.07   -1.11,
filtdisp=      0.00    0.15    0.30    0.44    0.57    0.71    0.84    0.98

Anyway, any other ideas?  One thing that I noticed was that ntpd was running
at nice 0.  I bumped it to -15, which may improve things.

I'm running with a fudge time1 0.015, which seems high to me, but is sort of
working right now... let me let it run for a day or two.


Thanks for your help!



More information about the questions mailing list