[wdmaudiodev] Re: WaveRT model conceptual flaw
- From: "Jose Catena" <jc1@xxxxxxxxxxx>
- To: <wdmaudiodev@xxxxxxxxxxxxx>
- Date: Thu, 4 Jun 2009 00:59:31 +0200
Ø However, I would argue that the empirical evidence stands as a pretty good
counterargument
I was not objecting the WaveRT architecture as a whole. I clearly stated
where’s the performance gain: the audio buffer and playback position registers
mapped to user memory allows streaming without any driver intervention and
excellent control. This is perfect!. Kudos to who designed it. I agree WaveRT
performs as a whole much better than previous architectures. I also agree that
there are more benefits than just performance. I repeat, excluding the timer
issue, everything is as good as I could think.
About what I wrote, I do have both empirical and theoretical evidence (the
later already explained and expended below) and you are not offering anything
regarding it, but twisting my words to justify your desired conclusion, or
perhaps you answered before thinking about it.
Please focus: Timer Interrupt! I already said the rest is perfect! You are
being defensive where there is no attack. Are you related to Microsoft?
Ø Your essay assumes that only a timer interrupt will trigger scheduling, and
that an audio interrupt goes straight to audio and then back again. That's not
correct. The operating system goes through basic scheduling at every
interrupt, timer or not. It always has to evaluate which is the next
high-priority thread.
No, I did not assume that, nor was I writing an essay, much less about thread
scheduling, and that detail does not relate to the difference between timer and
audio interrupts (if any, the impact of this will favor the audio interrupt
anyway, see below). Of course that the scheduler must decide if a switch is
necessary after every interrupt and almost always it does. But I don’t see at
all how this might argue against anything I wrote. Being what’s equal for every
interrupt (the scheduler must decide which task will run next), obviously the
timer involves much more before that. Not to mention the multiplication of
interrupts whenever interrupt timer period < software timer period, and the
software timers list evaluation. There is no way the timer interrupt could be
better.
I can’t believe I’m explaining how interrupts are better than timer polling in
a driver development forum, really. Are you serious? You are very wrong,
please use your mind and not your heart, there is really no technical basis to
support your position regarding this.
But I’ll insist because I think it’s important to have this clear, and perhaps
in a future occasion someone will not think he’s smarter than anyone else
inventing the square wheel again in something that affects everyone else like
the OS.
See it this way (and this time please ignore any simplification irrelevant to
the difference between both, and see below for a little more detail):
A) Audio interrupt (or any other except timer): This is an event itself. It
wakes up any thread waiting for that event, and the one with highest rt
priority if any is selected to run immediately.
B) Timer interrupt: Increment main timer, process the list of software
timers. Each timer elapsed becomes an event equivalent to A (the audio
interrupt above, all the rest before and after specific to timer, and note this
is in a loop). Update current task execution timers, check for task timeout,
find next task to run. Note also that before a software timer elapses and
becomes an event like in A, several interrupts evaluated it repeatedly whenever
timer interrupt period < sw timer period.
The timer interrupt will always have more to do, and indeed a lot. Never less,
no way. And the worst, most probably several times instead of one.
And for what? For nothing. There’s no reason to do it.
A different story, now that you speak about scheduling: I don’t think it’s
totally unrelated since low latency audio streaming is critically affected by
the scheduler, but perhaps we should move to private mail since this is not
specific to WDM architecture. But let me just start here.
To try incite you to think a bit next time, not to be arrogant: RT scheduling
is really my expertise area. I developed a couple of RT OS, one being widely
used in mission critical applications, including spacecraft and mass
transportation. So, do you think you also know about rt scheduling? Excellent!
Tell me what do you think about this:
Eval_rt_event()
{
for each task waiting for this event {
Change Task status to “ready to run”
If (task priority is rt and > selected priority) selected_task = task
}
return selected task
}
Interrupt other than timer
{
selected = current;
Selected = Eval_rt_event()
If selected != current
Switch to (selected)
}
Timer interrupt
{
Selected = current
Increment main timer
For each software timer
If elapsed
Eval_rt_event()
If selected != current
Switch to (selected)
Return
update task execution counters
if current task timed out
if task is rt: change its
priority to regular time shared and mark it as non rt compliant
selected = find highest
priority task
switch to (selected)
}
Simplistic? Really? Well, it is not exhaustive, just a draft, but it works
perfectly. Tell me what’s the problem if you find one. What happens if joe’s
app sets highest rt priority for non rt processing? nothing: after its first
elapsed time slice will be marked as non rt compliant. Could be it faster,
simpler, or safer? Well, tell me how. Even if Windows has improved this in a
significant way, I can really help to make it much better. If you have any
chance of it being considered by the appropriate people at MS, and the
intention is to find possible improvements, I will be more than happy to share
my knowledge. On the other side, if you are simply trying to argue in defense
of what has been done regardless of technical rigor, as seems to be the case,
please don’t waste your and my time.
Ooops, too many lines here, sorry.
Jose Catena
DIGIWAVES S.L.
Other related posts:
