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@reactos.org [mailto:ros-dev-bounces@reactos.org] 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?