From: mauch AT uni-duisburg DOT de (Michael Mauch)
Newsgroups: comp.os.msdos.djgpp
Subject: Re: testing uclock()
Date: Fri, 09 May 1997 17:43:56 +0200
Organization: Home, sweet home (via Gesamthochschule Duisburg)
Lines: 80
Distribution: world
Message-ID: <337b45ba.21833362@news.uni-duisburg.de>
NNTP-Posting-Host: ppp103.uni-duisburg.de
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Precedence: bulk

On Mon, 5 May 1997, Eli Zaretskii wrote (*):

> On Mon, 5 May 1997, Michael Mauch wrote:
 
> > Although it seems to work, I'm
> > not sure how accurate it is - as much as we can expect timing accuracy
> > in Windows. I looked at the output of a test program (with different
> > intervals, this time) using gnuplot, and it shows up that it is a lot
> > slower than uclock(), and there are a lot of peaks (some of them up to
> > 60000 tics, i.e. 50ms), but there a no negative values anymore.
> 
> I'm not sure I understand.  Is that performance good enough to live up to 
> the docs of `uclock' when it is called from Windows?

Yes, but calling puclock() from Win95 takes about 10 times longer than
from DOS.

> > Another question is, if there is a wrap-around anywhere (there's none at
> > midnight).
> 
> Can you leave it to run for a day and see if the Interrupt List is 
> right?  I don't see any other way to be sure.

I let it run for 36 hours now, Ralf Brown's Interrupt List is right. In
the article <4dgikc$krj AT tbsnames DOT turner DOT com> on DejaNews, I found an
explanation from Microsoft which confirms this. I computed the
theoretical wrap-around time for the 63 bit value: it's about 89e6 days,
which should be enough for most applications ;-)

However, there was a bug in the wuclock() function I posted. The line

 rv = ((uclock_t)regs.d.edx<<16) + regs.d.eax;

should be:

 rv = ((uclock_t)regs.d.edx<<32) + regs.d.eax;

or a bit quicker:

 *((long*)&rv+0) = regs.d.eax;
 *((long*)&rv+1) = regs.d.edx;
 

Thanks for your explanation of __bss_count. I guess this should be
changed in puclock, too. Shall I repost the whole thing? I will try to
not uuencode it this time (sorry for that).

In article <5k8101$11j$1 AT sdcc12 DOT ucsd DOT edu>, Brent Morgan asked for a
higher resolution timer than delay() and was suggested to use usleep().
The info file entry for usleep() says:

  This function pauses the program for USEC microseconds.

But the implementation of usleep() uses the clock() function with its
55ms resolution, so usleep() cannot even have millisecond resolution -
maybe this should be noted in the info file. I suggest the following
function:

unsigned int
pusleep(unsigned int _useconds)
{
  uclock_t stop_time = puclock() + _useconds * (uclock_t)UCLOCKS_PER_SEC
/ 1e6;

  while (puclock() < stop_time)
  {
    __dpmi_yield();
  }
  return 0;
}

In plain DOS, puclock() could be replaced by uclock(), of course.

Regards...
		Michael

*: Eli's article has not yet arrived at my news server, but he emailed
it to me as well as to djgpp AT delorie DOT com. I'm not sure how I'm supposed
to reply/follow-up now. Should I post a new article to the newsgroup or
should I simply hit the reply-button and Cc: it to the list?