From:	<ams AT ludd DOT luth DOT se>
Message-Id:	<200303101750.h2AHo2K26489@speedy.ludd.luth.se>
Subject:	Re: Win2K/XP uclock() - using rdtsc
In-Reply-To:	<10303101646.AA24079@clio.rice.edu> "from Charles Sandmann at Mar
	10, 2003 10:46:24 am"
To:	djgpp-workers AT delorie DOT com
Date:	Mon, 10 Mar 2003 18:50:02 +0100 (CET)
X-Mailer:	ELM [version 2.4ME+ PL78 (25)]
MIME-Version:	1.0
X-MailScanner:	Found to be clean
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

According to Charles Sandmann:
> > 2) If I try uclock() over say a few hours is it still approx rounded up 2%
> > or is it less? I expect it to go to zero as the elapsed time between calls
> > increases.
> 
> It doesn't improve - the scaling is based on the initial calibration loop.
> If you are unlucky and get a 5% error on the calibration, then the long
> term times will be off 5% - which could make it less accurate for large
> times than the 18.2 tics/sec clock.  

Can't we use a hybrid. 

1. Use the tics in conjuction with rdtsc for large enough delays.

2. For suffciently large values, use the time to recalibrate.

2b. Possibly use a moving average for the new value.

> Essentially it's trying to figure out what
> your CPU frequency is.

Hmm... I'm not an expert on CPU and their frequencies, but happens on
those mobile CPUs which change frequency? Or Transmeta CPUs? Perhaps
1. above would help some with this?


Right,

						MartinS

- Raw text -