From: George Anzinger <george@mvista.com>
To: root@chaos.analogic.com
Cc: Peter Chubb <peter@chubb.wattle.id.au>,
Stephen Hemminger <shemminger@osdl.org>,
Gabriel Paubert <paubert@iram.es>,
john stultz <johnstul@us.ibm.com>, Joe Korty <joe.korty@ccur.com>,
Linus Torvalds <torvalds@osdl.org>,
lkml <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@osdl.org>
Subject: Re: gettimeofday resolution seriously degraded in test9
Date: Thu, 30 Oct 2003 15:27:25 -0800 [thread overview]
Message-ID: <3FA19E5D.7050305@mvista.com> (raw)
In-Reply-To: <Pine.LNX.4.53.0310301645170.16005@chaos>
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
next prev parent reply other threads:[~2003-10-30 23:27 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-27 23:44 gettimeofday resolution seriously degraded in test9 Joe Korty
2003-10-28 0:15 ` Stephen Hemminger
2003-10-28 0:29 ` john stultz
2003-10-28 1:17 ` Stephen Hemminger
2003-10-28 11:55 ` Gabriel Paubert
2003-10-28 18:21 ` Stephen Hemminger
2003-10-29 10:07 ` Gabriel Paubert
2003-10-29 19:38 ` Stephen Hemminger
2003-10-29 22:50 ` Peter Chubb
2003-10-30 21:33 ` George Anzinger
2003-10-30 21:52 ` Richard B. Johnson
2003-10-30 22:50 ` Chris Friesen
2003-10-30 23:15 ` Peter Chubb
2003-10-30 23:47 ` George Anzinger
2003-11-25 16:42 ` [RFC] possible erronous use of tick_usec in do_gettimeofday Joe Korty
2003-11-25 17:13 ` Stephen Hemminger
2003-11-25 19:57 ` George Anzinger
2003-11-25 21:12 ` Joe Korty
2003-11-25 23:26 ` George Anzinger
2003-10-30 23:27 ` George Anzinger [this message]
2003-10-30 10:39 ` gettimeofday resolution seriously degraded in test9 Gabriel Paubert
[not found] <LphK.2Dl.15@gated-at.bofh.it>
[not found] ` <Lq47.3Go.11@gated-at.bofh.it>
[not found] ` <LqGL.4zF.11@gated-at.bofh.it>
[not found] ` <LAPN.1dU.11@gated-at.bofh.it>
[not found] ` <LGLz.1h2.5@gated-at.bofh.it>
2003-10-28 19:19 ` David Mosberger-Tang
2003-10-28 19:59 ` Stephen Hemminger
2003-10-29 0:19 ` David Mosberger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3FA19E5D.7050305@mvista.com \
--to=george@mvista.com \
--cc=akpm@osdl.org \
--cc=joe.korty@ccur.com \
--cc=johnstul@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paubert@iram.es \
--cc=peter@chubb.wattle.id.au \
--cc=root@chaos.analogic.com \
--cc=shemminger@osdl.org \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox