Linked by Thom Holwerda on Mon 27th Aug 2007 22:21 UTC
Windows A curious network performance reduction noticed by many Windows Vista users of the 2CPU forum that became the talk of Slashdot last week has been identified as having been caused not by DRM, as Slashdot users expected, but by a curious prioritization 'feature' of Vista that's intentionally biased toward Media Player at the expense of network and system resources.
Thread beginning with comment 266153
To read all comments associated with this story, please click here.
Article in short
by Almafeta on Mon 27th Aug 2007 22:30 UTC
Member since:

The article in short: Processes that declare themselves to be multimedia processes -- like Windows Media Player does -- are given the lion's share of processing time. These tasks are considered to be 'user-critical,' that is, tasks that the typical end user wants to be done without any slowdown or hiccups (movies that don't hang, music that doesn't skip, etc.), in favor of less critical tasks (background defragging, while a handy preventative measure, is not critical to the operation of Windows).

The article in short-short: Stop playing DVDs on company servers.

Reply Score: 14

RE: Article in short
by dylansmrjones on Mon 27th Aug 2007 23:46 in reply to "Article in short"
dylansmrjones Member since:

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.

Reply Parent Score: 15

RE[2]: Article in short
by Marcellus on Tue 28th Aug 2007 06:29 in reply to "RE: Article in short"
Marcellus Member since:

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.

Reply Parent Score: 3

RE[2]: Article in short
by Almafeta on Tue 28th Aug 2007 14:08 in reply to "RE: Article in short"
Almafeta Member since:

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...

Reply Parent Score: 1

RE[2]: Article in short
by Kancept on Wed 29th Aug 2007 21:42 in reply to "RE: Article in short"
Kancept Member since:

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.

Reply Parent Score: 2

RE: Article in short
by butters on Tue 28th Aug 2007 02:44 in reply to "Article in short"
butters Member since:

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

Reply Parent Score: 11

v RE[2]: Article in short
by casuto on Tue 28th Aug 2007 19:06 in reply to "RE: Article in short"
RE: Article in short
by stestagg on Tue 28th Aug 2007 09:28 in reply to "Article in short"
stestagg Member since:

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.

Reply Parent Score: 7

RE[2]: Article in short
by MollyC on Tue 28th Aug 2007 10:57 in reply to "RE: Article in short"
MollyC Member since:

"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

Reply Parent Score: 2