Date: Mon, 2 Feb 1998 19:09:36 +0200 (IST) From: Eli Zaretskii To: Kris Heidenstrom cc: djgpp AT delorie DOT com Subject: Re: High speed timing In-Reply-To: <34D5052C.B22DD910@clear.net.nz> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk 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.