Mail Archives: djgpp/1998/02/03/01:08:26
Eli Zaretskii wrote:
> On Mon, 2 Feb 1998, Kris Heidenstrom wrote:
>
>> 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.
That's right! That's why I am pointing out these factors!
I'm not saying that he won't be able to do what he wants to
do - I am just pointing out the things he will have to bear
in mind if he wants to get good performance!
Also, I'm not criticising DJGPP, or protected mode, or DOS,
or anything. These considerations of interrupt latency
apply to any architecture that uses interrupts. I'm not
saying that they are weaknesses, but they are (or may be)
significant when doing accurate timing in software.
BTW, just avoiding chaining causes its own problems - the DOS
time and date stop updating, and any TSRs, drivers, disk cache
software etc can have problems. Also, it isn't the full answer,
because other interrupt sources are still active - keyboard,
mouse, and serial (if used) etc, and they cause gaps in execution
in the foreground code. You have to be aware of each of these
factors, including the question of whether to chain int 8, and
decide for each one, whether it will cause a problem or not, and
if so, do something about it.
>> 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.
That's correct, the mode switch is the overhead. The CPU can't
accept an interrupt during the mode switch. The more often you
switch modes, the more likely the interrupt is to be signalled
during one.
The original poster did not say what accuracy he needs. I am
assuming he wants as much accuracy as he can get, i.e. a few
microseconds. At this accuracy, the overhead of the mode switch
is a significant factor. It is up to him to decide whether this
will or will not be a problem, but he needs to be aware of it
to start with! :-)
>> 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.
Timing the interval between a transmitted and received burst of
audio in a SONAR system? Sounds like real-time to me. As I said
above, he didn't specify an accuracy. If he is only interested
in resolving to a few milliseconds, then he _probably_ doesn't
need to worry about _any_ of the points you've taken me up on.
But I feel it would be irresponsible to say "yes, you can do it"
without mentioning the possible pitfalls.
Kris
- Raw text -