OSNews

The funny thing is that anything above 1 GhZ is perfectly capable of playback without hiccups even under heavy load - without affecting network bandwith. So one can wonder how come Microsoft felt compelled to make an unnecessary change with Vista.

I suppose you haven't really tried to play back much if that's your opinion.

My experience with Athlon 64 3700+ shows that playback isn't perfect if it's under load. And that's for normal 640x480 videos that are not even encoded with h264.

I don't see that as a flaw (maybe because I've never seen the behavior you describe).

What I worry about is the ability to declare yourself as a 'user-critical' process is essentially unrestricted, an on-your-honor thing. The abuses are just too powerful; I would think that there would have to be a whitelist to be allowed to use this priority, at least one controlled by Microsoft if not one controlled by the enduser.

We all remember back when popup ads first reared their ugly head how Microsoft declared that they would not be adding a popup blocker into IE4. They predicted that any site that maliciously used popups would be quickly abandoned by the Internet community, and that sites that used pop-ups as they were intended (to provide information for applets, f'rex) would be punished for other's sins by including a pop-up blocker in IE4. Before that, it was not including memory protection in Windows 95, as there were legitimate uses of it and any company whose products abused it would quickly kill themselves in the market and become dead weight on the shelves.

I think MS trusts third-party companies a little too much...

Can we say anything above a 233 MHz can? I honestly have not tested slower, but Z! in OS/2 plays great and doesn't slow my network down.

The scheduling framework is really simple, and has been well-known to the public since last summer. WMP runs as a real-time (high priority) task capped at 80% of each timeslice. In other words, it almost always runs while it has stuff to do. If WMP becomes CPU-bound, it is designed to run in 8ms chunks, leaving the rest of the system with low throughput and extremely high latency.

I disagree with this approach for several reasons. First, any task with an extremely high static priority and timeslice ratio will severely degrade overall system responsiveness. In most systems, even dating back to the 70s, priority and timeslice are manipulated incrementally and dynamically to provide balanced behavior as a task because more sleepy or more hoggish. This approach is a blank check rather than a structured settlement.

More importantly, though, it doesn't appear that the priority level or the timeslice cap are tunables. I realize that it's useful to be able to prioritize a single application over anything else. But if the bias is static, then it must be adjustable. Two sliders would be ideal, but in practice, a priority slider would have surprising behavior. This is because priorities are static in Windows, so moving one task's priority past another's could have a sudden and dramatic effect.

Why is WMP such a performance-killer in Vista? Just because it has a blank check doesn't mean it runs when it has nothing to do. Is it really consuming such an outrageous amount of CPU time? My guess is that latency is more of an issue than throughput. In other words, it isn't so much that WMP is using too much time, but rather that it's using it in big enough chunks that overall system responsiveness deteriorates.

So the first step toward fixing this problem would be to lower WMP's timeslice ratio until responsiveness becomes acceptable. WMP would still run (mostly) uninterrupted and early in each timeslice, but it would use the CPU in smaller chunks. It's possible that Microsoft will need to speed up the timeslice timer from 10ms to maybe 5ms in order to get small chunks without starvation.

What we learned from the Linux O(1) scheduler (and also FreeBSD's ULE) is that timeslice-based schedulers can get very fiddly and prone to edge cases as you tune and tweak. CFS doesn't have timeslices. The main tunable is granularity, which is essentially the problem with WMP in Vista: the granularity is too high.

Edited 2007-08-28 02:48

Between the lines. MS were worried that all their DRM related encryption/decryption of multimedia streams would take up too much CPU and people would notice dodgy playback.
So MS just upped the process priority until these side-effects disappeared.

"MS were worried that all their DRM related encryption/decryption of multimedia streams would take up too much CPU and people would notice dodgy playback.
So MS just upped the process priority until these side-effects disappeared."

If that's the case, then why are only Gigabit networks affected? Why does playing non-DRM multimedia manifest the problem even though such multimedia undergoes no encryption/decryption? Why is it that DRM'ed media on XP has no problems with "taking up too much CPU"?
There's no evidence that this screwup is due to DRM, but believe whatever you want.

Edited 2007-08-28 10:59