Incorrect CLOCK_TICK_RATE in 2.6 kernel

Incorrect CLOCK_TICK_RATE in 2.6 kernel

[George Anzinger]

CLOCK_TICK_RATE	is used by the kernel to compute LATCH, TICK_NSEC and 
tick_nsec.  This latter is used to update xtime each tick.  TICK_NSEC is 
then used to compute (at compile time) the conversion constants needed 
to convert to/from jiffies from/to timespec and timeval (and others).

The problem is that, if the timer being used is either Cyclone or HPET, 
the wrong CLOCK_TICK_RATE is used.  This means that systems using these 
interrupt sources will be doing a) incorrect update of xtime and b) 
incorrect conversion of jiffies.  Since these two values will track each 
other this will not be seen by simple gettimeofday(); 
sleep();gettimeofday() tests, but will be seen as a system clock drift 
(without NTP) or with NTP, a somewhat high drift rate (to the point of 
loosing sync at HZ=1000).

The fact that the user/ system chooses the clock to use at boot time and 
can change the clock after boot means that it is not possible to pin 
down CLOCK_TICK_RATE at compile time.  However, since the computation of 
TICK_NSEC and the conversion constants is rather involved it is clear 
that we REALLY do want to compute these at compile time.

The suggested solution is to a) set up a structure with the default 
(clock of choice at config time) conversion constants in it at compile 
time.  Then b) at clock init time, populate the structure with the 
proper constants for the given clock.  These can be computed at compile 
time, but from the correct  CLOCK_TICK_RATE for the given clock. 
Switching to a fall back clock would also require an update of this 
structure.

Commits?
-- 
George Anzinger   george@mvista.com
HRT (High-res-timers):  http://sourceforge.net/projects/high-res-timers/

Re: Incorrect CLOCK_TICK_RATE in 2.6 kernel

[john stultz]

On Wed, 2005-08-24 at 17:24 -0700, George Anzinger wrote:
> CLOCK_TICK_RATE	is used by the kernel to compute LATCH, TICK_NSEC and 
> tick_nsec.  This latter is used to update xtime each tick.  TICK_NSEC is 
> then used to compute (at compile time) the conversion constants needed 
> to convert to/from jiffies from/to timespec and timeval (and others).
> 
> The problem is that, if the timer being used is either Cyclone or HPET, 
> the wrong CLOCK_TICK_RATE is used.

Err, the Cyclone does not generate interrupts. So this issue does not
affect those systems.

As for the HPET, it sets its own interrupt frequency based off of
KERNEL_TICK_USEC (which you're right, isn't quite what is used in the
jiffies conversions).  Would it be easier to just adjust that value to
use ACTHZ or CLOCK_TICK_RATE?

thanks
-john

Re: Incorrect CLOCK_TICK_RATE in 2.6 kernel

[George Anzinger]

john stultz wrote:
> On Wed, 2005-08-24 at 17:24 -0700, George Anzinger wrote:
> 
>>CLOCK_TICK_RATE	is used by the kernel to compute LATCH, TICK_NSEC and 
>>tick_nsec.  This latter is used to update xtime each tick.  TICK_NSEC is 
>>then used to compute (at compile time) the conversion constants needed 
>>to convert to/from jiffies from/to timespec and timeval (and others).
>>
>>The problem is that, if the timer being used is either Cyclone or HPET, 
>>the wrong CLOCK_TICK_RATE is used.
> 
> 
> Err, the Cyclone does not generate interrupts. So this issue does not
> affect those systems.
> 
> As for the HPET, it sets its own interrupt frequency based off of
> KERNEL_TICK_USEC (which you're right, isn't quite what is used in the
> jiffies conversions).  Would it be easier to just adjust that value to
> use ACTHZ or CLOCK_TICK_RATE?

If you want to take that approach you would want the HPET to interrupt 
every TICK_NSEC nanoseconds, that being what xtime is pushed by each tick.

-- 
George Anzinger   george@mvista.com
HRT (High-res-timers):  http://sourceforge.net/projects/high-res-timers/