Re: gettimeofday resolution seriously degraded in test9

[George Anzinger <george@mvista.com>]

Peter Chubb wrote:
>>>>>>"Richard" == Richard B Johnson <root@chaos.analogic.com> 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   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml