[lkml]   [2003]   [Oct]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: gettimeofday resolution seriously degraded in test9
Peter Chubb wrote:
>>>>>>"Richard" == Richard B Johnson <> writes:
> Richard> There isn't any magic that can solve this problem. It turns
> Richard> out that with later Intel CPUs, one can get CPU-clock
> Richard> resolution from rdtsc. However, this is hardware-specific. If
> Richard> somebody modifies the gettimeofday() and the POSIX clock
> Richard> routines to use rdtsc when available, a lot of problems will
> Richard> go away.
> gettimofday() and the posix clock routines (which use gettimeofday())
> *do* use rdtsc if the processor has a reliable one --- do_gettimeofday() calls
> cur_timer->get_offset(), which is essentially a scaled rdtsc if you're
> using timers_tsc.c.
> But when you have power management turned on, TSC doesn't run at a
> constant rate. If it gets *too* slow, the timer switches to use the
> PIT instead, and one loses the cycle-resolution one would otherwise have.
IF (and that is a big IF) the cpu knows about the change, there is code in 2.6
to change the scaling of the TSC to match what the hardware is doing.

If you really want stability on the x86 grab the HRT patch (see sig below) and
set it up to use the pm-timer. This is rock solid, but does add time to the
gettimeofday() and friends as it requires an I/O cycle to read it.

George Anzinger
Preemption patch:

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:58    [W:0.077 / U:5.060 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site