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.

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.