August 28th, 2007
Thoughts on Mark Russinovich's response to Vista network slowdown
Several ZDNet readers have asked for my thoughts on Mark Russinovich’s response to Vista network slowdown issue.
Overall, I feel that Mark’s response is both thorough, clear and accurate. However, his blog post on the matter raises some interesting questions about the Windows Vista development process and how Microsoft approached the project. I’ll quote a few interesting passages from the blog and add my own commentary:
The MMCSS service runs in the generic service hosting process Svchost.exe, where it automatically prioritizes the playback of video and audio in order to prevent other tasks from interfering with the CPU usage of the playback software: [emphasis added]
From this we can assume that Vista has been developed with media playback in mind, in other words, it’s broadly aimed at the consumer since there’s no sensible way to disable to override this feature.
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 8ms of every 10ms 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. [emphasis added]
Again, an indication that pretty much everything is put on the back burner for multimedia, and for quite an extended period of time. Remember, every system sound that plays will be interfering with performance. This doesn’t sound right to me.
Tests of MMCSS during Vista development showed that, even with thread-priority boosting, heavy network traffic can cause enough long-running DPCs to prevent playback threads from keeping up with their media streaming requirements, resulting in glitching. MMCSS’ glitch-resistant mechanisms were therefore extended to include throttling of network activity. [emphasis added]
This is interesting because I find it hard to accept that the only way to solve the playback problem was to throttle network traffic. If this is the case, Windows needs a significant and widespread overhaul to improve performance. Microsoft is clearly willing to apply temporary patches to some pretty deep and serious issues.
Further, there’s an unfortunate bug in the NDIS throttling code that magnifies throttling if you have multiple NICs. [emphasis added]
OK, so there’s a bug too.
The throttling rate Vista uses was derived from experiments that reliably achieved glitch-resistant playback on systems with one CPU on 100Mb networks with high packet receive rates. [emphasis added]
So, not only is this a patch, it’s a patch intended for low-end PCs running Vista. A slap in the face for anyone who has spent money on decent hardware.
The hard-coded limit was short-sighted with respect to today’s systems that have faster CPUs, multiple cores and Gigabit networks, 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. [emphasis added]
OK, I have more trouble accepting this “with respect to today’s systems” bit than any other. Wasn’t Vista designed with “today’s systems” in mind rather than yesterday’s systems?
Temporary Solutions
So far, I’ve found two possible “temporary fixes” to this problem.
The first was proposed by my ZDNet blogging colleague George Ou, and that is to switch over to gigabit network gear that supports jumbo frames. It means spending some money, but not a lot.
Second, you can remove MMCSS from the Vista audio equation. To do this you’ll have to do a bit of registry editing.
Friendly Warning: If you trash your system messing with your registry, well, you’ll probably be too busy rebuilding your system to complain at me! Seriously, take care …
Fire up Registry Editor and navigate your way down to:
HKEY_LOCAL_MACHINE\SYSTEM\
CurrentControlSet\Services\Audiosrv
Once there find STRING called DependOnService. Right-click on this entry and choose Modify … and then from the Value data remove MMCSS. Click OK, close the Registry Editor and reboot your PC. Next, go into Services (the quickest way to get to this is to type services into the Start Search box and click on the entry that appears) and then find the Multimedia Class Scheduler service. Once found, right-click on it and Properties and change the Startup type from Automatic to Disabled. Click OK and then reboot.
Adrian is a technology journalist and author who has devoted over a decade to helping users get the most from technology. He also runs a popular blog called The PC Doctor. See his full profile and disclosure of his industry affiliations
Want to get in touch? Got a tip? Feel free to drop me a note! I ALWAYS respect anonymity. I'm also on Twitter (@the_pc_doc)
Right to Reply: Should any industry representatives wish to comment on any posts on Hardware 2.0, I will be happy to publish their reply verbatim on this blog.
Subscribe to Hardware 2.0 via Email alerts or RSS.
