Re: [ros-dev] MSVC

[Jose Catena]

As intended in my last post, better work and proof than discussion. Do you
agree?
You made too many assumptions, forget for a while that you already know
everything if you want to learn something.
What an audio workstation needs is that the audio events don't delay beyond
a predictable maximum. The processing of such events will be always a
fraction of the delay. So if the maximum latency is for example 1ms, lower
priority rt tasks won't be delayed more than a fraction of a millisecond for
this cause. This does not necessarily affect throughput of anything, and
anyway never without a good reason. An audio workstation will configure the
audio driver to have higher priority DPCs than disk, and disk higher than
network, USB, video... A network server will give priority to NIC then to
disk then whatever. Is the current scheme better, when all NIC, audio
driver, disk will suffer because the mouse DPCs? Proper RT scheduling
without anything violating it (like DPCs) can only help in every scenario,
how couldn't it? How could the current scheme be more efficient in latency,
throughput or anything than this one? Are you joking or what?
The rt priorities don't have much to do with throughput, the tasks demanding
lowest latency are the ones that will also do its job very quickly. If a rt
task does not finish in a very limited time, it does not comply and its
priority will be changed to time sharing range, this is one of the keys in
my scheme. The useful statistics are very easy to gather efficiently.
The threaded DPCs are not a solution when it depends on all drivers
employing it (which is not a reality and will not be), and does not address
the need of configuration of the priorities scheme by the user. Nor Win7
solves the risks of user configurable real time priorities.
MMCSS is not that thing, it is just a try to provide a reserved high
priority class to user mode, but it is anyway below *any* and *all* DPCs.
What happened with WaveRT in Vista is a demonstration of the absolute lack
of knowledge of what realtime scheduling is and the effects of latency, and
being separate of the scheduler itself, is a proof of the lack of
understanding in the very same regard. And very related to the scheduler
too. If it was so hard to learn for them after endless discussions, I
wouldn't expect you would a more complex timings relationship, much less
knowing your "I know it all" attitude.
You make me laugh, so if my scheduler performs better than the one in Win7
(not only better than the ones in ReactOS) you will support its inclusion?
LOL.
My aim is well beyond Win7 performance anyway. I'll work on it, and if I
success as I expect, you will support its inclusion or not as you wish. But
please don't ask me to discuss in that tone and attitude, we all know you're
the smartest guy with the biggest dick and I won't waste time challenging
you, ok?
I don't know Arun Kishan, who is he? MS is so huge... Most ppl I treated is
in the wdm area. Also as a team of audio developers leaded by Ron Kuper
(Cakewalk) we have been working with them at all levels. After a decade or
so the improvements are valuable, we got the KS interfaces published, the
nasty priority inversion algorithm removed, an so much more. And still, so
far from the right thing. If I did alone a scheduler that solved elegantly
and efficiently the same problems (and mine is not as large as yours by
far), how a company with the resources of MS doesn't? It is not that they
don't have great people, it is not that they don't get well founded and
documented requests, it is not a black hand... is the very nature of
marketing, every user will find some icons nicer than others, but hardly
understands what low latency means. If not, look how you saw at it: if MS
didn't how you...? If a developer skilled in windows internals doesn't know
about real time concepts...
Shields down. It is fun but I don't want to waste time in useless
discussions. I'll keep working as I said, and you all will know how it goes.
The only big obstacle in the way is the very limited time I have for it, not
any of arguments. Not that changing the DPC handling and sync will be easy,
but the model I'm trying to implement works great, I have already used it in
very different projects. This is not a fool idea of the latest frickie.
Back to msvc build fixing...
Cheers,

Jose Catena
DIGIWAVES S.L.


-----Original Message-----
From: ros-dev-bounces(a)reactos.org [mailto:[e-mail]] On
Behalf Of Alex Ionescu
Sent: Tuesday, 22 December, 2009 06:36
To: ReactOS Development List
Subject: Re: [ros-dev] MSVC

Sounds like you want make Threaded DPCs (which exist to fill the niche you
talked about) the default model. Are you aware of Threaded DPCs? Why not
just go down that route?

Your idea of targeting DPC-heavy drivers to lower their throughput is what
MMCSS attempted (and still does) to do back in Vista -- it partly lead to a
catastrophe as suddenly network card traffic on heavy audio I/O machines
dropped to a mere fraction of full network bandwidth on a GigE network. What
techniques have you developed to address these issues?

Other DPC throttling on I/O leads to priority inversion and inheritance
problems, due to the heavy inter-dependency of Windows services and drivers.
How do you plan on solving these challenges?

Most scalability bottlenecks in the 2003 scheduler are related to the
dispatcher lock -- multiple highly threaded real time applications would
encounter increased latency on many-core systems. How do you intend to solve
this issue without removing the lock as well (which would cause multiple
layer/version violations in ReactOS and take nearly as much time as removing
it in Win7 took)?

How do you intend to balance real-time thread usage with multiple user/TS
scenarios?

Also, I'm not sure what WaveRT/scheduler mode you are talking about. WaveRT
was mostly changed to properly support Event-Mode in Win7, which is an issue
entirely separate to scheduler changes.

Which "key" people have you spoken with? Have you spoken with Arun Kishan?