On Thu, 30 Oct 2003, George Anzinger wrote:
Peter Chubb wrote:
"Stephen" == Stephen Hemminger <shemminger@xxxxxxxx> writes:
Stephen> On Wed, 29 Oct 2003 11:07:45 +0100 Gabriel Paubert
Stephen> <paubert@xxxxxxx> 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.