Message-ID: <3B4F3D5B.C711C042@cyberoptics.com>
From: Eric Rudd <rudd AT cyberoptics DOT com>
Organization: CyberOptics
X-Mailer: Mozilla 4.72 [en] (Win95; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
Newsgroups: comp.os.msdos.djgpp
Subject: Re: uclock limitations
References: <3b4dba10 DOT 22636569 AT news DOT mbnet DOT fi> <2593-Fri13Jul2001202516+0300-eliz AT is DOT elta DOT co DOT il>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 26
Date: Fri, 13 Jul 2001 13:26:35 -0500
NNTP-Posting-Host: 38.196.93.9
X-Trace: client 995048801 38.196.93.9 (Fri, 13 Jul 2001 14:26:41 EDT)
NNTP-Posting-Date: Fri, 13 Jul 2001 14:26:41 EDT
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

Eli Zaretskii wrote:

> The problem is that `uclock' returns a value of the type uclock_t, which is
> defined as long long.  That's a 64-bit quantity, and since `uclock's
> resolution is 840 nanoseconds, the 64-bit type overflows in about 48 hours.

I haven't tried using uclock() to time long intervals, but overflow of the
64-bit quantity is not the problem, since 840ns * 2^64 = 1.5E+13 seconds =
50000 years.

Back when people were first having problems with uclock(), I switched over to
using an rdtsc-based timer.  It is not as portable as uclock(), so I haven't
proposed it to the DJGPP developers as a replacement, but it has performed
well for me.

rdtsc measures in processor clocks instead of seconds, but one can get around
that problem by timing the rdtsc timer against rawclock() for a couple of
ticks on the first call to the timer, which enables one to estimate the CPU
clock rate.

If there is interest in this style of timing, I would consider submitting the
code.

-Eric