Kernel PPS processing
Matthew.Selsky at twosigma.com
Wed Jun 29 20:38:40 UTC 2016
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:
> 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.
More information about the devel