[LinuxPPS] convergence patch

[Hal V. Engel]

On Thursday 07 May 2009 03:44:28 am Udo van den Heuvel wrote:
> Bernhard Schiffner wrote:
> > Simple changes take longer.
> > I asked the convergence behavior too and didn't get a real response.
> > (here and lkml)
>
> So we can saffly apply this patch as long as it's not in the main kernel?

This patch is for the kernel.  It is a very simple change to one constant in 
include/linux/timex.h in the kernel source tree.  It changes:

#define SHIFT_PLL	4

to

#define SHIFT_PLL	2

You should be able to safely make this change to any kernel starting with 
2.6.26 or later.  I am testing with 2.6.26 with the real time patches.

This makes the kernel more aggressive when making changes to the frequency 
correction of the clock.  This should result in the clock converging more 
quickly (presumably minutes instead of hours) and also should make the clock 
adjustments more responsive to things that affect the oscillator like 
temperature changes.  

Many LinuxPPS users have noticed that kernels before 2.6.20 would hold the 
offset between +-1 microsecond most of the time and that after 2.6.19 that 
this was no longer true (it was more like +-20 microseconds under the same 
conditions).  Making the above change is supposed to make newer kernels act 
more like those before 2.6.20.  This should result in the clock having lower 
offsets during times when the temperature of the oscillator is changing as 
well as faster convergence during startup. 

Since all it does is make the kernel more aggressive when it applies 
corrections to the clocks rate the change is "safe" to make at least as long 
as it does not make the kernel too aggressive (this does not appear to be the 
case).  Many of us believe that unmodified newer kernels are not aggressive 
enough at least for machines that do not have a ovenized or temperature 
compensated oscillator.  Since machines with ovenized or temperature 
compensated oscillators are very rare (most of these are that way because they 
were hand modified by their users) for most users this kernel change should 
result in better time keeping.  This should actually be something that is 
controlled from user space since it seems like this could have different 
optimum values depending on the hardware and perhaps environmental factors and 
even perhaps how long ntp has been running.

I applied this change to my kernel and I am testing it now.  My initial 
impression only a short time after restarting the patched kernel is that it 
definitely converges much faster during the initial startup of ntp.  Offsets 
were under 20 microseconds in about 3 minutes on my machine with the offset 
starting at about 1.2 milliseconds initially.  With out the kernel 
modification this same thing would have taken perhaps 1/2 hour.  

I have only run it long enough that the offset has crossed zero a few times 
(IE. the PPL is just now getting a good lock) and it looks like it will indeed 
do a better job of keeping the offsets near zero than with out the change.  
After the offset crossed zero the second time it has not gotten bigger than +- 
2 microseconds and most of the time the offsets have been below +-1 
microsecond.  This was during a time when ambient temperatures where fairly 
stable and under the same conditions I would have expected offsets to be 
between +-10 microseconds with an unmodified kernel.  It is definitely worth 
testing if you are having issues with either slow startup convergence or 
temperature induced clock offsets.  This is probably almost everyone on this 
list.

Hal