Message-ID: <34D5052C.B22DD910@clear.net.nz> Date: Mon, 02 Feb 1998 12:28:44 +1200 From: Kris Heidenstrom MIME-Version: 1.0 To: Eli Zaretskii CC: djgpp AT delorie DOT com Subject: Re: High speed timing References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Eli Zaretskii wrote: > On Sun, 1 Feb 1998, Kris Heidenstrom wrote: > >> The BIOS int 8 >> handler doesn't do too much, but TSRs often hook the interrupt or >> int 1Ch which is called by the BIOS int 8 handler, and TSRs are >> often poorly written. The nett effect is a gap in execution every >> time a timer tick occurs. > > 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. Take a TSR screen saver for example, which uses int 8 or int 1Ch to get execution. When it activates, it might stretch that interrupt out to hundreds or thousands of microseconds. In the application we are talking about (measuring time between transmitted and received audio in sonar), this could be very significant, because the CPU is not able to watch for the event during that time. This is made worse by the fact that the extended interrupt time could occur only occasionally, or cylically, causing apparent glitches or 'motion' of the time being measured. If the event triggers an interrupt (e.g. through the -ACK input of the parallel port) this is still an issue because interrupts may not be enabled during the time the TSR is doing its thing. The point I made is that anything that is outside your control is a possible problem when you are doing accurate timing. TSRs are especially dangerous because they are often written by amateurs who don't appreciate the issues involved. DOS systems are mostly not used in real-time applications so no one notices how badly behaved some software is. If you are using an int 8 handler in DJGPP then yes the protected mode handler gets control first, but for accurate timing it is not normal to use an int 8 handler because it is unusual to operate int 8 at faster than about 10 kHz, and 100 microsecond resolution may not be good enough. For accurate timing it is best to avoid int 8 (or even disable it altogether) and use the timer registers to read the time when the event occurs. Even using int 8, the issues of variable latency still apply. >> With DJGPP (or any protected mode program), there is also the >> overhead of one or more mode switches. The normal handlers for >> hardware interrupts like the timer tick, keyboard, mouse etc >> are real-mode ones, so if the CPU is in protected mode when the >> interrupt occurs, two mode switches are required. If you use >> interrupts yourself, more mode switches could be needed. > > Once again, this is mostly irrelevant, unless the foreground program > is dwelling a lot in real mode (like if it calls DOS or BIOS > services). If the foreground code runs mostly in protected mode, > there is no overhead due to mode switches, since your protected-mode > handler is called directly from protected mode. The mode switch > happens only after the protected-mode handler chains to the previous > one. Anything that extends the amount of time the CPU spends doing things other than waiting for the event, is relevant. Also, when an interrupt is used to signal the event to the CPU, any time when the CPU cannot service interrupts is relevant. It is all latency of one sort or another. 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. For the best performance using this technique it would be best to avoid mode switches altogether, by either keeping the CPU in protected mode and using a protected mode handler, or keeping the CPU in real mode and using a real mode handler (presumably, without EMM386 installed). >> Depending on what other requirements you have for your program, >> you could consider disabling all interrupt sources during the >> timing process. > > Some environments, such as Windows, don't really let you do that, so > beware. Running any sort of real-time software under Windows of any kind is asking for trouble. You can't even read the timer count in progress in a VDM under Windows 95 - the timer hardware is emulated and I've heard that there is a bug in the emulation :-) Kris