From: Richard Legner <rlegner AT whitehorse DOT net>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: uclock()
Date: Sun, 21 Feb 1999 13:10:16 -0600
Organization: Blackstone Janitorial Services
Lines: 47
Message-ID: <36D05A18.8940AC49@whitehorse.net>
References: <Pine DOT SUN DOT 3 DOT 91 DOT 990221133549 DOT 6539W-100000 AT is>
NNTP-Posting-Host: 199.247.227.235
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Trace: 919631122 VRL06/YYIE3EBC7F7C usenet53.supernews.com
X-Complaints-To: newsabuse AT remarQ DOT com
X-Mailer: Mozilla 4.07 [en] (Win95; U)
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

Eli Zaretskii wrote:
> 
> On Thu, 18 Feb 1999, Richard Legner wrote:
> 
> > while the values produced by uclock() follow a general ascending trend,
> > they are by no means in order.
> > What could be causing this?
> 
> Windows, of course.  You didn't say, but from the description I'm
> guessing that you are running it from Windows 9X.  If so, it's a known
> problem for which no real cure is known: `uclock' reprograms the
> system timer, but Windows resists this.

Yes, Windows 95.
> 
> One possible solution is to add this line in the [386Enh] section of
> your SYSTEM.INI file:
> 
>      TrapTimerPorts=OFF
> 
> After adding this line, reboot and see if it helps.  In any case,
> please tell here if this setting has any effect on the behavior of
> `uclock'.

It seems to have helped to a certain degree.  The first time uclock() is
called it defaults to zero (this works fine), the next few times (10 or
so) uclock() is called in the program, the values are randomly negative
(this happens consistently).  After that it seems to stabilize and
produce reasonable values.  The keyword here is _seems_, because when I
use uclock to time my routines, it still sometimes produces values the
are clearly unreasonable.

So in conclusion of my little experiment I cannot safely say that I
have  or have not fixed the problem, or even a part of it, as the
behaviour before this
attempted fix was not _consistently_ faulty.

I have also changed the ticks data type to ucloct_t (as some people
suggested) to avoid possible wrapping of values, but I don't think this
was ever an issue.

This does not mean that I have fixed the problem as the behaviour before
this attempted fix was not _consistently_ faulty.

Thanks for the help,
cheers
Richard