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

Reply via email to