From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S263002AbTJ3X1l (ORCPT ); Thu, 30 Oct 2003 18:27:41 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S263005AbTJ3X1l (ORCPT ); Thu, 30 Oct 2003 18:27:41 -0500 Received: from gateway-1237.mvista.com ([12.44.186.158]:764 "EHLO av.mvista.com") by vger.kernel.org with ESMTP id S263002AbTJ3X1f (ORCPT ); Thu, 30 Oct 2003 18:27:35 -0500 Message-ID: <3FA19E5D.7050305@mvista.com> Date: Thu, 30 Oct 2003 15:27:25 -0800 From: George Anzinger Organization: MontaVista Software User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021202 X-Accept-Language: en-us, en MIME-Version: 1.0 To: root@chaos.analogic.com CC: Peter Chubb , Stephen Hemminger , Gabriel Paubert , john stultz , Joe Korty , Linus Torvalds , lkml , Andrew Morton Subject: Re: gettimeofday resolution seriously degraded in test9 References: <20031027234447.GA7417@rudolph.ccur.com> <1067300966.1118.378.camel@cog.beaverton.ibm.com> <20031027171738.1f962565.shemminger@osdl.org> <20031028115558.GA20482@iram.es> <20031028102120.01987aa4.shemminger@osdl.org> <20031029100745.GA6674@iram.es> <20031029113850.047282c4.shemminger@osdl.org> <16288.17470.778408.883304@wombat.chubb.wattle.id.au> <3FA1838C.3060909@mvista.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Richard B. Johnson wrote: > On Thu, 30 Oct 2003, George Anzinger wrote: > > >>Peter Chubb wrote: >> >>>>>>>>"Stephen" == Stephen Hemminger writes: >>> >>> >>>Stephen> On Wed, 29 Oct 2003 11:07:45 +0100 Gabriel Paubert >>>Stephen> 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 >> >> 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