[LinuxPPS] Linux issues discussed earlier this year.

[Hal V. Engel]

On Wednesday 29 July 2009 10:09:25 am clemens at dwf.com wrote:
> Earlier this year at least two Linux issues were discussed that would
> contribute to better timekeeping.
>
> There was the definition of STA_NANO in timex.h
> and the calculation of nanoseconds in some glibc routines.
>
> This (and any other details) was discussed in a number of separate messages
> on this forum.
>
> Was it ever put together anywhere???
>     I dont see it on our wiki.
>
> My understanding of the situation is that the STA_NANO problem can be fixed
> by just copying the timex.h from a current kernel into /usr/include/linux.

No this is not correct the STA_NANO issue was with glibc.  This is mostly 
fixed in recent versions of glibc (see below).

>
> What about the glibc?  Does someone have an updated copy sitting out
> somewhere that we can copy (I really dont want to get involved with git if
> I can help it) 

Current versions of glibc are mostly fixed (at least starting with 2.10.1).  
They didn't get it totally correct as they missed two of the defines needed 
for this to be complete (MOD_NANO and MOD_TIA).  Here is a gentoo bug report 
with the details including a patch to ntp that creates the missing defines so 
that it will build:

http://bugs.gentoo.org/show_bug.cgi?id=270483

This might be totally fixed in newer versions of glibc but 2.10.1 is the 
newest that is available for Gentoo and they have a temporary fix for the two 
missing defines that works nicely.

> and what about the kernel itself?  

The only issue with the kernel was the one fixed by the convergence patch.   
This should be part of the kernel starting with 2.6.30 (or was it 2.6.31?) but 
I have not personally confirmed this.  This change is in <kernel source 
tree>/include/linux/timex.h where

#define SHIFT_PLL       4

is changed to

#define SHIFT_PLL       2

This causes a reduction in how "stiff" the time keeping is and lower values 
make it adjust more quickly to external conditions.  On my system I reduced 
this to 1 and my system now keeps the offsets remarkably low even under 
conditions of fluctuating temperatures and varying system load (almost never 
more than +-1 microsecond).  Having looked at the code the only place where 
SHIFT_PLL is used it is added to the other things that influence this and 
values as low as 0 should be OK.  

> Does it have bad code?  I
> seem to recall that for a while it calculated nanoseconds by multiplying
> microseconds by 1000.  sigh.

To quote Michael Meier

"You will also need to tell configure to use librt (./configure 
LIBS="-lrt") - without librt, ntpd will resort to using gettimeofday for 
getting time from the kernel, and that function only returns 
microseconds because it is defined that way."

The difference is not that the values returned are multiplied by 1000 but that 
when librt is used there are more significant digits in the returned value 
since the default call truncates the value at the microseconds level before 
returning to the caller.

>
> In any case, I would like to play with these changes, but would like to
> know that I have everything that was discussed.