Kernel PPS processing

[Matthew Selsky]

On Wed, Jun 29, 2016 at 12:31:56PM -0700, Gary E. Miller wrote:
> Yo Matthew!
> 
> On Wed, 29 Jun 2016 14:55:23 -0400
> Matthew Selsky <Matthew.Selsky at twosigma.com> wrote:
> 
> > On Wed, Jun 29, 2016 at 11:48:08AM -0700, Hal Murray wrote:
> > > > Can you quantify the better?  I would have expected identical...  
> > > 
> > > 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.
> 
> Scroll down this:
> 
>     https://pi3.rellim.com/
> 
> Look at the 'offset of PPS'.  It shows usually better than +/- 15 microSec.
> Looks like PPS is usually close to a few microSec, but frequent 20 microSec
> dealsy.  I'm not sure what the daily spike is.
> 
> That is KPPS on git head of ntpsec and gpsd.
> 
> > We tested booting with "nohz=off intel_idle.max_cstate=0" and it made
> > a difference in our production clocks.
> 
> But not kernel PPS?  I can see why the max_cstate might help, but if
> the KPPS is interrupt driven I'm not sure why the nohz would help.
> 
> Can you quantify the individual effects?  And is that kernel PPS, KPPS
> in ntpsec, or just PPS in ntpsec?

We're using a GPS PCIe card with OCXO HQ with a daemon that writes to SHM and then ntpd reads from the SHM driver.

Measuring on this server via ntpq -p we were seeing offsets of +/- 3us without either of these two kernel parameters.  With nohz=off, the offsets were +/- 1us.  With both kernel parameters we see offsets too small for ntpq -p to measure.

This was all measured while running ntpd Classic.


Cheers,
-Matt