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.sel...@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 _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
