Message-ID:	<36928BD8.8FED643D@cyberoptics.com>
From:	Eric Rudd <rudd AT cyberoptics DOT com>
Organization:	CyberOptics
X-Mailer:	Mozilla 4.05 [en] (Win95; U)
MIME-Version:	1.0
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: timing in u sec range
References:	<Pine DOT SUN DOT 3 DOT 91 DOT 990103103639 DOT 12860B-100000 AT is>
Lines:	21
Date:	Tue, 05 Jan 1999 16:02:00 -0600
NNTP-Posting-Host:	206.144.150.73
X-Trace:	news2.randori.com 915573720 206.144.150.73 (Tue, 05 Jan 1999 14:02:00 PDT)
NNTP-Posting-Date:	Tue, 05 Jan 1999 14:02:00 PDT
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

Eli Zaretskii wrote:

> DJGPP has a library function which does all that for you.  It is
> called `uclock'.  You get a result that has a 840 nsec granularity.

Under DOS, uclock() seems to work fine.  Unfortunately, under Win95 uclock()
exhibits errors on the 55-ms level, which I have been unable to completely
diagnose.  I sometimes even get *negative* times for events.  Since my own
timer routine failed similarly, I have concluded that Win95 (in its infinite
wisdom) is periodically tampering with the 8254, so I gave up on uclock(), and
use RDTSC for high-resolution timing.  With a little work, one can measure the
CPU clock speed by comparing RDTSC against the advancing 55-ms tick count from
rawclock(), so the RDTSC output can be converted to seconds.  Win95 appears to
leave the operation of RDTSC completely unmolested.

Unfortunately, RDTSC is an illegal instruction on some x86 clones (maybe all
of them?).

-Eric Rudd
rudd AT cyberoptics DOT com

- Raw text -