Date: Tue, 12 Mar 2002 10:12:12 -0500 (EST)
Message-Id: <20020312.101212.25466030.obatan@rpi.edu>
To: lk@tantalophile.demon.co.uk
Cc: greearb@candelatech.com, linux-kernel@vger.kernel.org
Subject: Re: a faster way to gettimeofday?
From: OBATA Noboru <noboru@ylug.org>
In-Reply-To: <20020312130635.C4281@kushida.apsleyroad.org>
In-Reply-To: <20020312130635.C4281@kushida.apsleyroad.org>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org

> If you run NTP (synchronisation with atomic clock standards over the
> network), you get really good real world clock times.  It continually
> adjust gettimeofday() but not the rdtsc clock.  That may highlight any
> drift due to thermal effects in the PC.
> 
> I would guess you're not running NTP?

You are right.  I'm not running NTP.  Actually, I was using
clockspeed (http://cr.yp.to/clockspeed.html) before, which
adjusts system clock using RDTSC, but I have stopped it to
observe pure system clock.

In the first version my userland gettimeofday, I'm more
interested in how RDTSC could be configured to synchronize with
the system clock, rather than the real world clock time.

To atapt the system clock change, userland gettimeofday should
issue real gettimeofday system call occasionally, as Terje
suggests early in this thread, and adjust calibration
parameters.  I'll call it "adaptive userland gettimeofday."

You may not need calibration any longer since it is adaptive.
However, it will be slower and less effective because much
adjusting code should be implemented.  So I'm hesitating to
implement adaptive userland gettimeofday :-).

-- 
OBATA Noboru (noboru@ylug.org)
-
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/