Microsoft Responds to Re-discovery of Vista Network Slowdowns

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 effects of this feature were first revealed last June, as BetaNews reported, by Microsoft security engineer Mark Russinovich.

In a blog post to SysInternals this afternoon, Russinovich once again provides a clear view of what some prominent bloggers have called a bug, but which Microsoft maintains is an intentional choice: favoring multimedia playback when the CPU is stressed, even if it means slowing down file and network transfers and even the mouse pointer.

The culprit, Russinovich writes, is the Multimedia Class Scheduler Service (MMCSS), one of the many services run within Vista's service host. When the CPU is under stress, Windows Media Player 11 places a call to MMCSS, which in turn boosts the player's own priority relative to other processes. Many Vista users found out about this through the use of Vista's Performance Monitor.

"When a multimedia application begins playback, the multimedia APIs it uses call the MMCSS service to boost the priority of the playback thread into the realtime range, which covers priorities 16-31, for up to 8 ms of every 10 ms interval of the time, depending on how much CPU the playback thread requires. Because other threads run at priorities in the dynamic priority range below 15, even very CPU intensive applications won't interfere with the playback."

At least, that's the intention. Internet traffic shouldn't be affected by this performance throttling, he continues, due to multiple connections that fragment Internet traffic even in the best conditions anyway. Conceivably, the lesser the bandwidth, the fewer the fragments.

But the amount of throttling Microsoft engineers intentionally chose to employ was based on their assessment of 100 Mbps networks, where fragmentation is great enough that packet receive rates are high. "The hard-coded limit was short-sighted with respect to today's systems that have faster CPUs, multiple cores and Gigabit networks," Russinovich went on, "and in addition to fixing the bug that affects throttling on multi-adapter systems, the networking team is actively working with the MMCSS team on a fix that allows for not so dramatically penalizing network traffic, while still delivering a glitch-resistant experience."

That's where Mark leaves us hanging for now. He did use the word "bug" to describe the behavior of this choice on multi-adaptor systems, and he did characterize Microsoft's forthcoming solution as a "fix." That flies in the face of an official Microsoft response to ZDNet blogger Adrian Kingsley-Hughes, who had written earlier that he was going to turn most Vista sounds off until Microsoft worked out a solution.

"Please note that some of what we are seeing is expected behavior," the spokesperson told Kingsley-Hughes, "and some of it is not. In certain circumstances, Windows Vista will trade off network performance in order to improve multimedia playback." Then reviving an old Microsoft phrase that was so often used in the 1990s to officially explain away behavior that couldn't otherwise be explained, Microsoft wrote, "This is by design."

Another citation from Microsoft's response says users typically hate having to hear sputters and clicks from their speakers when their network or CPU is stressed, and it's that hatred which provoked the company to make the trade-off in the first place.

Russinovich's characterization of the throttling trigger as "hard-coded" may be an indication that the company's fix may involve giving the user a choice of which services should be pared down when crunch time comes, system services or multimedia. But with the sheer number of system services Vista now runs, crunch time may be coming too often anyway.