Date:	Mon, 2 Feb 1998 19:09:36 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	Kris Heidenstrom <kheidens AT clear DOT net DOT nz>
cc:	djgpp AT delorie DOT com
Subject:	Re: High speed timing
In-Reply-To:	<34D5052C.B22DD910@clear.net.nz>
Message-ID:	<Pine.SUN.3.91.980202190919.19322R-100000@is>
MIME-Version:	1.0

On Mon, 2 Feb 1998, Kris Heidenstrom wrote:

> > If these TSRs are real-mode programs (as they usually are), they are
> > mostly of no consequences to DJGPP programs which catch the timer
> > interrupt, because the protected-mode handler gets control *before*
> > the real-mode ones.
> 
> If you are timing an event by waiting for it to occur and then
> reading the timer, they are important.  Everything that takes
> execution away from the foreground task (and under DOS, this is
> just interrupts and wait states inserted by the hardware when
> the turbo button is switched off) is important.

You can always choose not to chain to the previous handler if that's
important enough, or use a system which was booted clean.

> If the program is calling DOS etc, then the CPU is alternating
> between real and protected mode, which firstly increases the
> likelihood of interrupt acceptance being delayed, and secondly
> makes the actual latency quite variable.

It is not quite clear to me why you think calling DOS will cause more
latency.  If you refer to the parts of DOS which disable interrupts,
they are not many.  Otherwise, DOS code can and will be interrupted by
the timer tick.  The mode switch is the only overhead in this case.

> Running any sort of real-time software under Windows of any kind is
> asking for trouble.

Who said something about real-time?  This thread was born out of a
question about timing events and parts of code, not about real-time
applications.

- Raw text -