lkml.org 
[lkml]   [2003]   [Oct]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: gettimeofday resolution seriously degraded in test9
Richard B. Johnson wrote:
> On Thu, 30 Oct 2003, George Anzinger wrote:
>
>
>>Peter Chubb wrote:
>>
>>>>>>>>"Stephen" == Stephen Hemminger <shemminger@osdl.org> writes:
>>>
>>>
>>>Stephen> On Wed, 29 Oct 2003 11:07:45 +0100 Gabriel Paubert
>>>Stephen> <paubert@iram.es> wrote:
>>>
>>>
>>>>>for example.
>>>
>>>
>>>Stephen> The suggestion of using time interpolation (like ia64) would
>>>Stephen> make the discontinuities smaller, but still relying on fine
>>>Stephen> grain gettimeofday for controlling servo loops with NTP
>>>Stephen> running seems risky. Perhaps what you want to use is the
>>>Stephen> monotonic_clock which gives better resolution (nanoseconds)
>>>Stephen> and doesn't get hit by NTP.
>>>
>>>monotonic_clock:
>>> -- isn't implemented for most architectures
>>> -- even for X86 only works for some timing sources
>>> -- and for the most common case is variable rate because of
>>> power management functions changing the TSC clock rate.
>>>
>>>As far as I know, there isn't a constant-rate monotonic clock
>>>available at present for all architectures in the linux kernel. The
>>>nearest thing is scheduler_clock().
>>
>>What you want is the POSIX clocks and timers CLOCK_MONOTONIC which is available
>>on all archs (as of 2.6). The call is:
>>
>> cc [ flag ... ] file -lrt [ library ... ]
>>
>> #include <time.h>
>>
>> int clock_gettime(clockid_t which_clock, struct timespec *setting);
>>
>>where you want "which_clock" to be CLOCK_MONOTONIC.
>>
>
>
> But there is a more basic problem. Let's say I need time in microseconds,
> but the only hardware tick I have is in milliseconds. If I can call
> the routine in zero time, it takes 1000 calls before the microsecond
> value will change.
>
> There isn't any magic that can solve this problem. It turns out
> that with later Intel CPUs, one can get CPU-clock resolution
> from rdtsc. However, this is hardware-specific. If somebody
> modifies the gettimeofday() and the POSIX clock routines to
> use rdtsc when available, a lot of problems will go away.

THAT is exactly what both gettimeofday() AND the recommened interface do.
Resolution will be to the TSC tick on x86. Almost all archs provide at least 1
microsecond resolution for both these clocks.

Even the x86 archs without a TSC have and have had, for some time, code which
gives better than one microsecond resolution.

--
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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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