Kernel PLL graphs

[Matthew Selsky]

On Mon, Aug 01, 2016 at 02:40:11AM -0700, Hal Murray wrote:
> 
> There are two parts to PPS processing in the kernel.  RFC 2783 describes an 
> API for capturing time stamps.  RFC 1589 describes a PLL that lives in the 
> kernel.
> 
> Most Linux distros don't support RFC 1589.  The code is in the kernel, but it doesn't work with the shipped kernels.  It requires !NO_HZ, but most distros prefer NO_HZ.
> 
> I pulled over the sources and built my own kernel.
> 
> Here are the before and after graphs:
>   http://users.megapathdsl.net/~hmurray/ntpsec/PPS-kernel.png
> The data is from two separate days so this isn't a clean comparison.  I don't know what that machine was doing on either day.
> 
> Here is a zoom in on the Kernel PLL day.
>   http://users.megapathdsl.net/~hmurray/ntpsec/PPS-kernel2.png
> Note that the peak offset is less than a microsecond.
> 
> ------------
> 
> We should see if we can get similar results on a Raspberry Pi.  I haven't tried building an ARM kernel.
> 
> I think we should be able to run the PLL code outside the kernel.  The PPS time stamp is key.  The PLL calculations don't need to be run in the kernel.  They need to be run soon after the PPS, but not interrupt level immediately.  The API has an option to wakeup on PPS.  I don't know if it is implemented on Linux.
> 
> The no-PLL test was run at the default maxpoll of 6.  I should try faster.  I also need a standard test load.
> 
> I remember various FreeBSD-is-better type comments from many years ago.  I don't know if the PLL was working in Linux at the time.  I should setup a test case.

Hey Hal,

I'm using maxpoll of 1 on my stratum 1 servers.  And I have !NO_HZ set.  My offsets stay belong 1 microsecond as reported by ntpq.  If we switched the units to nanoseconds, that might be interesting.

I don't have !NO_HZ set on my stratum 2 servers, but I'm looking at the ramifications of that.

I'm curious what your results are.

Cheers,
-Matt