Kernel PPS processing

Gary E. Miller gem at rellim.com
Wed Jun 29 20:25:58 UTC 2016


Yo Hal!

> > > Did you look at the graph?
> > >   http://users.megapathdsl.net/~hmurray/ntpsec/glypnod-pps-kernel.png  
> 
> Yeah, your 'No kernel' was aweful. If that is your baseline then you
> got something really, really, wrong.  The scale on the 'kernel PLL'
> was too small to really tell, but I think I get the same on my
> RasPi's.

I took another look, and realized I misunderstood the y axis.  And that
you are plotting loopstats and I'm looking at offsets.  So not the bad
I thought.

To get apples and apples, can you send me your gnuplot formula?  I'll
add it to my chrony graph.

The noise around the main signal on your two graphed lines is not that
different.  And your 'no kernel' shows the sidereal day oscillation that
I expect. From that point of view your 'Kernel PPS' looks wrong.
Unless you have a very expensive time-keeping saw-tooth corrected GPS
you should see the sideral day osccillation.

Maybe what is going on is that the damping in the 'Kernel PPS' is a lot
less than in the 'no kernel' case.  We know that ntpd takes a longtime
to adjust the system clock.  From that point of view I prefer your 'no
kernel' data.

Also, what gpsd and ntpsec versions are you on?  Are you even using
gpsd?  

gpsd is making some compromises on noise rejecction.  And has changed
the compromise in different versions.  For fast slewing, gpsd allows any
PPS from +/- 100 milliSec from expected.  That is because chronyd can be
slewing the clock almost 90 milliSec a Sec and we do not want to lose
PPS during slewing.  Most of the time the system clock is stable, and
some people patch their gpsd to a 1 milliSec window.  That removes
the noise spikes from the PPS offset I see on RasPi.

Until the startup glitch in NTPsec is fixed, and maybe even after, I feel
gpsd should pass on most of the data it gets and let ntpd deal with it.

At some point a dynamic error gate may be in order.

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/20160629/8d9af163/attachment.bin>


More information about the devel mailing list