From: 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 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII 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 Precedence: bulk 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