Raspberry Pi NTP config with fudge factors

Gary E. Miller gem at rellim.com
Fri May 6 20:32:24 UTC 2016


Yo Hal!

On Fri, 06 May 2016 13:15:08 -0700
Hal Murray <hmurray at megapathdsl.net> wrote:

> esr at thyrsus.com said:
> > It sounds like this has implications for how I should write the
> > HOWTO recipe.  Are you saying that with refclock 20 the source can
> > get marked as a falseticker if it loses PPS for a while?  
> 
> You are missing a critical idea.
> 
> The NMEA and JSON drivers can be setup to use the PPS too.  Both have
> a mode bit to turn that on/off.

Which now requires an ntpd restart, preventing side-by-side comparison
and perturbing the PLLs.  So you then need to wait 12 hours to get a stable
PPS again...

> You can run them in either of two ways.  One way is so that they grab
> the PPS.  If you look at things with ntpq -p, it should look like a
> PPS slot with typical PPS numbers.  You can't see how well the serial
> port is working.  If the PPS stops working, the driver stops using it
> and ntpq -p will show serial port info.

And that mungs the jitter, so when PPS comes back on it will not be used
for a long time.

> Plan B is to turn on/off the mode/fudge bit so they don't use the
> PPS.  You have to add another driver for the PPS.  That driver needs
> a way to label the seconds so you have to "prefer" some other
> driver.  (Yes, it's a krock.)  If your serial port is sane, you can
> use that.  (Many aren't sane.)

And gpsd knows best how to sort the sane and tne insane serial ports
apart.

> If you want to use the serial port to label the seconds, you have to
> get it reasonably close.  That usually requires fudging the time and
> probably also adjusting mindist (the measure of "sane" above).

Yeah, fudging time2, which you can't easily see.

So there is a potential temporary fix for #20 if the NMEA and PPS can
be split and exposed.

> That's a quick hack, not the results of careful tuning.

Probably good enough.  Just not obvious to the casual user.

> The fudge time2 is needed to get the serial port close enough.  The
> mindist is needed to make the window for "close enough" big enough to
> work.  100 may not be big enough.

Yup, thus the visibility thing.  The eassiest way to set the time2 is
to see the NMEA and the PPS at the same time.  Like in #28, and $48 if
not set to defaults.

Here is a #28 and a $48, side-by-side, on the same gpsd source:

catbert:~# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
-clepsydra.hpl.h .GPS.            1 u   36   64  377   26.297   -0.420   0.133
-204.152.184.72  .GPS.            1 u   34   64  377   29.243   -2.724   0.357
 nist.netservice .ACTS.           1 u  853 1024    0   59.516   -0.373   0.000
+spidey.rellim.c .GPS1.           1 s   58   64  376    0.189   -0.248   0.025
 SHM(0)          .GPS.            0 l   15   16  377    0.000   11.468   2.281
+SHM(1)          .GPS1.           0 l   15   16  377    0.000    0.203   0.404
*SHM(2)          .SHM.            0 l   13   16  377    0.000   -0.225   0.023
 GPSD_JSON(0)    .GPSD.           0 l 133m   64    0    0.000  -123.69   0.000
 GPSD_JSON(128)  .GPSD.           0 l 134m   64    0    0.000    0.895   0.000

OBTW, noteice the #48 reflock dies, while the #28 is still working!

SHM(0) is NMEA time
SHM(1) is PPS time
GPSD_JSON(0) is NMEA time from the same gpsd as SHM(0)
GPSD_JSON(128)  is GPS time from the same gpsd as SHM(1)

So, assuming that is stable, I nneed to add 11 millSec to my SHM(0) fudge
and -123 milliSec to my SHM(1) fudge.

Wild card: SHM(2) is PTP from another local server!

Killing and restarting ntpd fixed the GPSD_JSON() crash.  Yet another bug in
#48.  #48 is not ready for pime time.

Here is my mtpq -p after the ntpd restart:

catbert:~#  ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
-clepsydra.labs. .GPS.            1 u   27   64    3   26.393   -0.422   0.719
-204.152.184.72  .GPS.            1 u   28   64    3   29.191   -2.215   0.005
 nist.netservice .ACTS.           1 u   24   64    0    0.000    0.000   0.000
+spidey.rellim.c .GPS1.           1 s    6   64    3    0.266   -0.249   0.005
 SHM(0)          .GPS.            0 l    9   16   77    0.000   12.037   0.821
-SHM(1)          .GPS1.           0 l    8   16   77    0.000    0.638   0.351
*SHM(2)          .SHM.            0 l    6   16   77    0.000   -0.248   0.033
-GPSD_JSON(0)    .GPSD.           0 l   22   64    3    0.000  -130.39   0.104
+GPSD_JSON(128)  .GPSD.           0 l   21   64    3    0.000    0.134   0.817

I feel another bug report coming on....

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160506/dc463a3f/attachment.bin>


More information about the devel mailing list