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/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/