Vista Multimedia Playback and Network Throughput

A few weeks ago a poster with the handle dloneranger reported in the 2CPU forums that he experienced reduced network throughput on his Vista system when he played audio or video. Other posters chimed in with similar results, and in the last week attention has been drawn to the behavior by other sites, including Slashdot and Zdnet blogger Adrian Kingsley-Hughes.

Many people have correctly surmised that the degradation in network performance during multimedia playback is directly connected with mechanisms employed by the Multimedia Class Scheduler Service (MMCSS), a feature new to Windows Vista that I covered in my three-part TechNet Magazine article series on Windows Vista kernel changes. Multimedia playback requires a constant rate of media streaming, and playback will glitch or sputter if its requirements aren’t met. 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:

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.

You can see the boost by playing an audio or video clip in Windows Media Player (WMP), running the Reliability and Performance Monitor (Start->Run->Perfmon), selecting the Performance Monitor item, and adding the Priority Current value for all the Wmplayer threads in the Thread object. Set the graph scale to 31 (the highest priority value on Windows) and you’ll easily spot the boosted thread, shown here running at priority 21:

Besides activity by other threads, media playback can also be affected by network activity. When a network packet arrives at system, it triggers a CPU interrupt, which causes the device driver for the device at which the packet arrived to execute an Interrupt Service Routine (ISR). Other device interrupts are blocked while ISRs run, so ISRs typically do some device book-keeping and then perform the more lengthy transfer of data to or from their device in a Deferred Procedure Call (DPC) that runs with device interrupts enabled. While DPCs execute with interrupts enabled, they take precedence over all thread execution, regardless of priority, on the processor on which they run, and can therefore impede media playback threads.

Network DPC receive processing is among the most expensive, because it includes handing packets to the TCP/IP driver, which can result in lengthy computation. The TCP/IP driver verifies each packet, determines the packet’s protocol, updates the connection state, finds the receiving application, and copies the received data into the application’s buffers. This Process Explorer screenshot shows how CPU usage for DPCs rose dramatically when I copied a large file from another system:

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. It does so by issuing a command to the NDIS device driver, which is the driver that gives packets received by network adapter drivers to the TCP/IP driver, that causes NDIS to “indicate”, or pass along, at most 10 packets per millisecond (10,000 packets per second).

Because the standard Ethernet frame size is about 1500 bytes, a limit of 10,000 packets per second equals a maximum throughput of roughly 15MB/s. 100Mb networks can handle at most 12MB/s, so if your system is on a 100Mb network, you typically won’t see any slowdown. However, if you have a 1Gb network infrastructure and both the sending system and your Vista receiving system have 1Gb network adapters, you’ll see throughput drop to roughly 15%.

Further, there’s an unfortunate bug in the NDIS throttling code that magnifies throttling if you have multiple NICs. If you have a system with both wireless and wired adapters, for instance, NDIS will process at most 8000 packets per second, and with three adapters it will process a maximum of 6000 packets per second. 6000 packets per second equals 9MB/s, a limit that’s visible even on 100Mb networks.

I caused throttling to be visible on my laptop, which has three adapters, by copying a large file to it from another system and then starting WMP and playing a song. The Task Manager screenshot below shows how the copy achieves a throughput of about 20%, but drops to around 6% on my 1Gb network after I start playing a song:

You can monitor the number of receive packets NDIS processes by adding the “packets received per second” counter in the Network object to the Performance Monitor view. Below, you can see the packet receive rate change as I ran the experiment. The number of packets NDIS processed didn’t realize the theoretical throttling maximum of 6,000, probably due to handshaking with the remote system.

Despite even this level of throttling, Internet traffic, even on the best broadband connection, won’t be affected. That’s because the multiplicity of intermediate connections between your system and another one on the Internet fragments packets and slows down packet travel, and therefore reduces the rate at which systems transfer data.

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

Stay tuned to my blog for more information.

Comments

• Anonymous
  January 01, 2003
  The comment has been removed

• Anonymous
  January 01, 2003
  These links may provide some additional info on "Gigabit network suffering slow (relatively speaking) transfer rates"- http://web2.minasi.com/forum/topic.asp?whichpage=1&TOPIC_ID=25099#116458 which will point you to - http://blog.tmcnet.com/blog/tom-keating/microsoft/remote-desktop-slow-problem-solved.asp Also look into (with an elevated command prompt)- netsh interface tcp set global autotuninglevel=disabled This will set the TCP window size to what is normally used.  In Vista and Longhorn they use a larger window size which works great with  Vista and Longhorn. To reset it you would enter - netsh interface tcp set global autotuninglevel=normal

• Anonymous
  January 01, 2003
  Peter - yes, I've seen heart monitor goes beep. I've even seen a real expensive machine that goes "Bing!" in action :) And no, you don't need HD audio for beeps and more importantly those life-critical equipment usually runs on RTOS instead of Windows. AFAIK, windows has never been certified to run on life-supporting system. Non life-support system such as visualization systems(those hi-res video you're talking about) and management console, however, often times they DO deploy windows. Just so you know, if you do loss your life over machines, chances are it isn't windows.

• Anonymous
  January 01, 2003
  The comment has been removed

• Anonymous
  January 01, 2003
  The comment has been removed

• Anonymous
  January 01, 2003
  The more I read about this issue the stranger it becomes. There are so many problems it's even hard to know where to start.

1. Why does the audio system require the following: "For instance, in Vista, the audio engine runs with a periodicity of 10 milliseconds. That means that every 10 milliseconds, it MUST wake up and process the next set of audio samples, or the user will hear a "pop" or “stutter” in their audio playback. It doesn’t matter how fast your processor is, or how many CPU cores it has, the engine MUST wake up every 10 milliseconds, or you get a “glitch”." Audio is not a hard real time system, it should be a soft real time. You process enough ahead of time and send it to the audio card's buffer, that if you miss a period by say +/-5 ms it does not cause a problem. Unless the OS doesn't trust the audio card. The part with, "it doesn't matter how many CPUs you have" is also quite wrong. If I have more CPUs, then there's a better chance one of them should be free, or not have enough load to be able to process every 10ms. "So it doesn’t matter how much horsepower your machine has, it’s about how many interrupts have to be processed." But won't a machine with more horsepower handle interrupts faster? And this gets us into problem 2.
2. "Network DPC receive processing is among the most expensive, because it includes handing packets to the TCP/IP driver, which can result in lengthy computation. The TCP/IP driver verifies each packet, determines the packet’s protocol, updates the connection state, finds the receiving application, and copies the received data into the application’s buffers." Why does it need to verify each packet, one would think that can be done on the network card. Packet protocol, update of connection and receiving application should be figured quite fast for today's computers, and I do hope that it is not copying the whole data, and just updating pointers (I assume the data has already been copied from the network drive since it does checksum on it). And check this link out (from 2003 none the less): http://www.microsoft.com/whdc/device/network/NetAdapters-Drvs.mspx "TCP and IP Checksum Offload: For most common network traffic, offloading checksum calculation to the network adapter hardware offers a significant performance advantage by reducing the number of CPU cycles required per byte. Checksum calculation is the most expensive function in the networking stack" "In the Windows Performance Lab, we have measured TCP throughput improvements of 19% when checksum was offloaded during network-intensive workloads." And then there's 3, which is quite funny in itself - hard codding a throttling value in code. This is from the same article from 2003 from MS (different application, but same principle): "One reason to load the table from the registry is to avoid hard-coded values in the driver. This also allows for experimenting with the table entries to find the optimal values for several representative workloads."

• Anonymous
  August 27, 2007
  Great article Mark, thank you for giving a clear explanation of the problem.

• Anonymous
  August 27, 2007
  is it the reason that explain why my games are A LOT less performant with windows Vista? does playing audio in games and having Teamspeak (or ventrilo at the same time) reduce the graphic and procesor output for my games because audio is at higher priority (especially in MMORPG where the network is important)? is there a way to put this value back to normal? thanks

• Anonymous
  August 27, 2007
  Running XP I just tried playing an MP3 file, a video file and downloading several files from the internet all at the same time.  The audio and video files played perfectly and there was no slowdown in my network speed. "mechanisms employed by the Multimedia Class Scheduler Service (MMCSS), a feature new to Windows Vista" Seems to me Microsoft tried to "fix" something that wasn't broken.

• Anonymous
  August 27, 2007
  Very useful to know. I've spent a good bit of time trying to figure out why my file transfers were so slow. During all of that debugging, I probably had a music file running in the background... Serge: Games performance is probably more related to video driver issues. My understanding is that the new Vista video driver model is theoretically just as fast as the XP video driver model, but it requires a lot of stuff to be re-written by the driver developers for best performance. Until it all gets re-written, they're using pieces from the XP driver (changing Vista's input to what the XP driver expects, then changing the XP driver's output to what Vista expects), and the result is that some tasks are done less efficiently. On my laptop, I could hardly get any video files to play without glitching. CPU usage would go up to 100% and stay there, even though the media file played just fine with only 20% CPU usage on XP. Then by accident I was running another program that was incompatible with Aero and forced Vista to switch into the XP-style video mode. Suddenly my video started playing back smoothly at 20% video usage, just like XP.

• Anonymous
  August 27, 2007
  Serge, I don't own Vista yet, but the first thing I thought of when I started reading this post was "games".  Good question...

• Anonymous
  August 27, 2007
  Mark, A sincere thank you for explaining the issue in detail and not “suger coating” it—you might renew my faith in Microsoft.

• Anonymous
  August 27, 2007
  The comment has been removed

• Anonymous
  August 27, 2007
  my first thought was to disable the MMCS service, but the Windows Audio service is dependent on it. So I ran regedit, and changed the key HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesAudiosrvDependOnService Just remove MMCS from that key in the list, and set MMCS to disabled in services, then reboot. As soon as I rebooted I was able to copy files at 40mb/s+ while listening to audio -Courtney

• Anonymous
  August 27, 2007
  Why is XP not having this problem then? This seems like unnecessary feature of Vista. I've spent countless hours for couple months trying to figure out why copying files over network was going at 5MB/s

• Anonymous
  August 27, 2007
  The comment has been removed

• Anonymous
  August 27, 2007
  The comment has been removed

• Anonymous
  August 27, 2007
  The comment has been removed

• Anonymous
  August 28, 2007
  Great post Mark! Vinicius Canto MVP Windows Server - Admin Frameworks Brazil

• Anonymous
  August 28, 2007
  "I have noticed problems when running on an IPv4 network.  IPv6 drivers are enabled by default for every network adapter, meaning every time you try to connect to a remote computer/website, Vista tries using IPv6 first.  If your network doesn't support it, this only results in wasted time." Actually, the time wasted should be very little.  Unless the hostname has an AAAA record associated with it, the system shouldn't use IPv6 to try and communicate with the host. The only time it becomes a major delay, is when the remote host supports IPv6, and either the local or remote host isn't properly configured for IPv6.  Then, it has to time out, then switches to IPv4. IIRC, Teredo is on by default in Vista, which means (provided the teredo relay isn't down and firewall isn't blocking) you have functioning IPv6 on your end enough to be useful.

• Anonymous
  August 28, 2007
  Windows Vista does allow a fine grained control of priority boost, you just need to find where to look for it instead of disabling the service (MMCSS). http://msdn2.microsoft.com/en-us/library/ms684247.aspx

• Anonymous
  August 28, 2007
  The comment has been removed

• Anonymous
  August 28, 2007
  Why do Vista need seuch a system ? Ever an old Win2K, on un PIII 1Ghz, with 512Mb can play an audio file without glitchs during network transfert. Today, with have "big" CPU, and Vista cannot play audio file smoothly during network transfert ? Such a shame ...

• Anonymous
  August 28, 2007
  I wrote up the details on my fix on my blog http://courtneymalone.com/2007/08/28/a-note-on-vista-network-speed/

• Anonymous
  August 28, 2007
  Regarding multiple network cards. If I disable the other network cards will the performance go up (you said 3 cards 1/3 network performance?) also whats up with  this key? HKLMSoftwareMicrosoftWindows NTCurrentversionMultimediaSystemProfileSystemResponsiveness seems this is an easy registry edit to allocate less cpu time for MMCSS

• Anonymous
  August 28, 2007
  I developed lots of audio drivers for the older Microsoft OSes, and interestingly, had to use the DPC to process audio mixing and such so that it wouldn't glitch on systems with lots of thread activity.  The trick to avoid using all the CPU cycles for audio was to keep track of how much time was being spent in the DPC vs. the scheduled threads. In Vista, trying to "guess" how much of the CPU is being used for MM operations is unrealistic, since it spans the domain from 128kb MP3 playback to DRM'ed HD audio/video playback.   The MMCSS algorithm defaults to 8ms for MM threads and 2ms for the other threads, but the flaw in the algorithm is that the IRPT and DPC times are not subtracted from the wall-clock times. Suppose that a really busy network transfer used up 50% of the cpu in the DPC routines.  MMCSS should then see that only 4ms is available for mm out of the 8ms maximum.  The audio stack must do it's part, then, by letting the MMCSS know if that 4ms was enough to process 10ms of output.  For simple audio, it may need only 1ms to generate 10ms of audio output.  OTOH, it may need more than 4ms to insure no glitching, and THAT is the point that the network should be throttled back. I think Vista gives most of the info needed to do this right -- the new kernel thread time accounting now subtracts DPC (and probably IRPT) from the thread's scheduling quantum.  The audio stack "pulls" output from the hardware back through the various drivers, which should allow determination of how well the computational load is being handled. Looks like SP1 is needed now more than ever!  Tell Balmer to forget the market-timing issues and just get a Vista SP out in the field.  I'm even thinking seriously about ripping Vista off my new laptop and desktop if SP1 is not going to appear in the near future. Thanks for your as usual well-stated description of the problem!

• Anonymous
  August 28, 2007
  Mark, I've been following your insights for years. Once again, thank you for the excellent explanation. We have 2 users on the network who use Vista and have complained w/network issues. Once again Mark, thanks for the years and all the great utilities. PS: I use XP but have tried Vista. After spending over 15 hours of learning and tweaking, I finally gave up and uninstalled it. After 3 weeks of hard disk thrashing (I continually fought w/Vista services which "magically" reset to default thrash mode), it became futile. You may want to pass up the chain, it is for these reasons Vista will not be quickly adopted.

• Anonymous
  August 28, 2007
  All good and nice, but :

1.  It seems that people have this problem even AFTER they disabled MMCSS.
2.  The performance impact is way bigger (from 500..1000 mbps to sub-100mpbs or even lower. This is by no means a minor impact.
3. As other pointed out,it seems like a classic problem of "Shoot yourself in the foot"  because previous versions of windows do not have this issue nor audio playback smoothness problems.
4. If you really want to help maybe you should take a look on the original forum page (http://forums.2cpu.com/showthread.php?t=83112) and see that the impact reported by other users and what you explain here does not quite add up.
5. As a personal note : with today's computing power  this kind of problem on dual/quad core machines is ....well I don't know if I should say "funny" or "pathetic" :)

• Anonymous
  August 28, 2007
  "100Mb networks can handle at most 12MB/s, so if your system is on a 100Mb network, you typically won’t see any slowdown". I think you need to learn a bit about networking. Not every frame is full. At half full, the limited number of frames is reached at 7.5MB/s, well within a 100Mb networks ability.

• Anonymous
  August 28, 2007
  The comment has been removed

• Anonymous
  August 28, 2007
  sell out. you where all about discovering and fixing bugs/glitches, or even malware. now you are part of the MS propaganda. this kind of problem shows how flawed windows vista is. davinci would have torn the whole thing apart and started again.

• Anonymous
  August 28, 2007
  Does this take into account jumbo frames if you're using a gigabit network?  If your frame size is, say, 9000 bytes, at 10000 packets/sec and 8bits/packet, that's 720Mbit (theoretical) throughput.  That's still less than 100% but it's not horrible...

• Anonymous
  August 28, 2007
  This doesnt make any sense design wise. Why does every OS so far, even WinXP and every *NIX OS doesnt have any trouble handling multimedia + network ? Furthermore pc hardware get faster over time not slower - the thinking behind this design implies that hardware gets slower because previously in other OS it worked fine. Once again, braindead developers at M$ which doesnt surprise me at all

• Anonymous
  August 28, 2007
  So a non-privileged userland application is able to modify global kernel parameters? Sounds like a good idea to me. Any other bits of the kernel I can mess with from a non-priv account?

• Anonymous
  August 28, 2007
  Why have to guess a good value for max packets/sec while playing audio? Why not have some intelligent monitoring to find if audio playback thread is starving for cpu? Like check for empty buffers? Profile normal playback cpu needs, and make sure it receives that? vajk

• Anonymous
  August 28, 2007
  The comment has been removed

• Anonymous
  August 28, 2007
  To me, this seems like overly optimistic resource allocation... I agree 100% that it needed to happen, (and I'm greatful for Mark's detailed response/ explanation) however, it seems to be at so much overhead that it degrades other services... Given the multi-core CPU scenario we live in now, is this optimization even so necessary? I remember trying to set up MS ISA 2 years ago on a SMP server (in a hurry) and got very poor performance due to "CPU's fighting over controlling the NIC's" - (I realize that now that you can pin a NIC to a particular CPU)... Is this similar? Is there any way to pin or isolate these competing processes such that we are not stuck with such low limits to utilization? thanks again for a great explanation Mark.

• Anonymous
  August 28, 2007
  What I think a few posters are missing is the fact that this has nothing to do with overall CPU speed.  Overall, CPUs are fast and getting faster.  This has to do with priority over the course of milliseconds.   Both networking and media playback require instant results - because TCP/IP gets processed when it's received, and because most audio is sampled at over 40 kHZ.  On a 2 GHz machine, that means that it's playing something every 22 microseconds (about once every 45,350 processor cycles, and it takes a few cycles to play something).  If it delays too long, or drops a few samples, you hear skipping. As a result, the concern is that if both network functions and multimedia need the CPU right now then you have a collision.  That's why MS limited the networking so it only comes in on average once every 100 microseconds, to prevent that.

• Anonymous
  August 28, 2007
  One addition: Microsoft completely rewrote the TCP/IP stack for Vista, and doing so they surely made some... hm, mistakes. This might be another reason of strange behavior. See http://www.microsoft.com/technet/community/columns/cableguy/cg0905.mspx and lots of other pages.

• Anonymous
  August 28, 2007
  Actually, multimedia glitching is a pretty well-known problem to heavy audio and video users (i.e. multitrack work, editing, not just playback).  A whole alternate universe of drivers has sprung up to deal with this.  It's much less of a problem than it used to be, but under heavy loads, it's still an issue. Sounds like Microsoft tried to be over-proactive about it, and (as others have said) shot themselves in the foot.  I wonder if this isn't something that went into Vista back in 2001 as an obvious necessity, and then wasn't looked at toward the end of the release cycle...

• Anonymous
  August 28, 2007
  The comment has been removed

• Anonymous
  August 28, 2007
  Something as essential as music playback and file copying should not require days of investigation by users. Someone write better docs! PS - I have a phone running a 200 MHz ARM with a piddly little OS and am able to play streaming MP3's on a broadband wireless network with no hassles. And a dual-core, 2 GHz desktop uses 41% CPU to simply copy files???

• Anonymous
  August 28, 2007
  Something as essential as music playback and file copying should not require days of investigation by users. Someone write better docs! PS - I have a phone running a 200 MHz ARM with a piddly little OS and am able to play streaming MP3's on a broadband wireless network with no hassles. And a dual-core, 2 GHz desktop uses 41% CPU to simply copy files???

• Anonymous
  August 28, 2007
  The comment has been removed

• Anonymous
  August 28, 2007
  Hi, I am the IPv6 Program Manager at Microsoft.   Regarding the comment "Unless the hostname has an AAAA record associated with it, the system shouldn't use IPv6 to try and communicate with the host." Even if the destination has an A and an AAAA record, Vista will prefer IPv4 over Teredo.  The order of precedence is IPv6, IPv4, THEN Teredo.  So a destination host with an A and AAAA record will always be reached using IPv4, NOT TEREDO. The only time Teredo would be used is if the destination host ONLY had a AAAA record, and there are darn few of those out there.  In other words, leaving IPv6 (and Teredo) enabled on your home PC have absolutely no impact on your networking performance.

• Anonymous
  August 28, 2007
  Rob: ... <i>copying a file</i> takes 41% of the CPU.  What kind of networking stack has that kind of processor overhead? I regarded this kind of behavior when copying files using SMB. The same file copied from the same server using FTP was many times faster. Regards, Lothar

• Anonymous
  August 28, 2007
  @Chris   re: (I realize that now that you can pin a NIC to a particular CPU) can you elaborate?  I'm looking around and can't find any info - this could be helpful on one of my servers. Thanks

• Anonymous
  August 28, 2007
  I have had a ton of issues with media playback in Vista on both single core and dual core platforms, with and without Aero even when it could easily support it.  My solution has been to shutdown as many ancillary services as possible, and there are a lot.  Most, if not all of the security services are gone, and that was strictly for my sanity.  Many of the disk services and indexing are shutdown. I do actually know where my content is and don't need any help finding it.  And then I shutdown some more things that just seemed to be hanging out and not really providing any immediately useful service.  The result is a fairly smooth running system that runs aero, the sidebar, other applications, and my i-tunes videos full screen without glitches.  Prior to shutting all of these things down, i-tunes videos were unwatchable, streaming internet video (ie simple slideshows) were unwatchable, and the whole media experience was enough to make me beg for XP back, or even 2000 pro.  My disk access has gone from essentially constant to only when I'm actively doing something.  Now I have my LED for power that stays on, and my disk activity LED is no longer solid 24/7.  Things that ran fine on XP systems with less than half the performance of the current system now run like they should.  Moving large files across the Gigabit network also move like they should.  Vista still won't play wmv files that run fine on my other XP boxes.  Winamp will play them just fine on VISTA, but Media Player says there is a problem with my WHQL video card.   Why all of this?  There are many other issues with Vista playing media than the one network issue mentioned here and eliminating many of the ancillary services will go a long way, but not nearly all the way, to solving them.  There error codes that Windows Media Player provide are of course useless because there is no description for them.  I would have thought that all of the effort going into the driver certification process and application certification process would have resulted in a more stable and better performing system, but alas this has not been the case.

• Anonymous
  August 28, 2007
  > Despite even this level of throttling, Internet > traffic, even on the best broadband connection, won’t > be affected. This is only a valid analogy for someone downloading a single file off the Internet from a single source. Throw in P2P-anything and you get huge number of small packets which Vista will happily throttle for you [sigh], regardless of your actual bandwidth. One problem is you use packets/sec regardless of how 'full' those packets are.  Another is that Vista apparently has a horribly inefficient TCP stack... 40% CPU usage for a file copy?

• Anonymous
  August 28, 2007
  "Games are slower overall because of all the added functionality and features in Vista... even with many services, eyecandy, and programs disabled I still find programs run better in XP (and even better in Linux!).  For example, BioShock runs horribly on my computer in Vista with input and audio lag making it unplayable.  This didn't surprise me too much as my computer didn't meet the minimum specs in the CPU department.  But, in XP, it ran quite acceptably."

• Not to mention all the DRM throughout the audio and video stack.  Benefitting who exactly?  Not really the consumer, they're better off with XP arguably.  DX10 runs a fair bit quicker on XP and Linux (with the "backported" un-official release), that surely means something is very wrong.

• Anonymous
  August 28, 2007
  So this explains the problems with MCE's having stutter problems? As they push data over the network while doing 'media playback' at the same time? The Transcode360 forums are full of this problem too.

• Anonymous
  August 28, 2007
  Correction: "the standard Ethernet frame size is about 1500 bytes" should be "the MAXIMUM standard Ethernet frame size is about 1500 bytes." This is significant because it is a "well known fact" that most ethernet frames are a lot less than the maximum length.  It is only when pumping lots of data (e.g. file transfers) that maximum size frames are used heavily, and even then the acknowledgment frames going back to the data source are typically 64 bytes (minimum size). The minimum frame is 64 bytes, which works out to about 164,000 frames/second so throttling at 10,000 frames/second will throttle the network a whole lot worse than the calculation based on 1500 byte packets. Note that there is the same amount of overhead in a 1500 byte frame and a 64 byte frame, meaning the amount of useful data that gets passed in shorter frames is even worse.

• Anonymous
  August 28, 2007
  The comment has been removed

• Anonymous
  August 28, 2007
  The real questions, I suppose, have to do with the various virtualization scenarios - XP under Vista, or Vista under XP, and whether this resource allocation can be "fooled" under these circumstances.

• Anonymous
  August 28, 2007
  The comment has been removed

• Anonymous
  August 28, 2007
  And, yes, the same hardware running Linux can play back a glitch free mp3 while keeping the network link fully loaded with send and receive data. The answer to this particular problem - switch to Linux.

• Anonymous
  August 28, 2007
  "The minimum frame is 64 bytes, which works out to about 164,000 frames/second so throttling at 10,000 frames/second will throttle the network a whole lot worse than the calculation based on 1500 byte packets." True, but how often does one send out more than 10000 little frames per second?  Usually when you're transferring more than 10000 frames it's because they're part of, for example, a large TCP stream, and those frames are likely the maximum size, i.e. that of the MTU.

• Anonymous
  August 28, 2007
  The comment has been removed

• Anonymous
  August 28, 2007
  The comment has been removed

• Anonymous
  August 28, 2007
  The comment has been removed

• Anonymous
  August 28, 2007
  Leo Davidson said - "It seems to be a scheduling/throttling issue, rather than one caused by something using too much CPU. The problem is that fixed magic numbers were chosen, perhaps based on the worst-case hardware, and obviously without thinking about the requirements of gigabit networks." If I could do network I/O without taxing the CPU I would not land into trouble with scheduling and neither would I need to do any throttling. The problem is not magic numbers themselves - the problem lies int the fact that they were needed. There is no excuse to use more than tiny amount of CPU to do network I/O even at Gigabit speeds if the OS and networking stack are designed sanely. Read the blog post I linked to.

• Anonymous
  August 28, 2007
  The comment has been removed

• Anonymous
  August 28, 2007
  It's refreshing to hear a valid, lucid explanation of what the issue really is instead of the background "noise" created by the FUD mongers at Slashdot.  Thank you once again for leading the way to understanding core Windows technologies.

• Anonymous
  August 28, 2007
  "It's refreshing to hear a valid, lucid explanation of what the issue really is instead of the background "noise" created by the FUD mongers at Slashdot.  Thank you once again for leading the way to understanding core Windows technologies." This is a "lucid explanation" of a really BAD DESIGN. This is not FUD, its purely bad design... Do you know another OS in the world that needs more than 40% of the processor to handle a GigE traffic?

• Anonymous
  August 28, 2007
  Do you even know how to measure kernel time as a percentage of total processing time in any OS?  I'll give you a hint -- it doesn't show up in a typical CPU utilization chart.

• Anonymous
  August 28, 2007
  This is not only a Windows problem. You can find the same on many other OS.

• Anonymous
  August 28, 2007
  Lucio, nobody is claiming their isn't a problem here. MS (or at least two MS employees in their blogs) are being quite open about the fact there is a problem that needs fixing. The FUD that I believe FusionGuy was referring to was people jumping to baseless conclusions that this issue was caused by the evil multimedia DRM in Vista and other such nonsense. It's great that Mark and Larry (http://blogs.msdn.com/larryosterman/default.aspx) from Microsoft have been able to shed light on this new issue in such detail and I hope it puts an end to the FUD. The issue itself still needs to be solved but it's clear that it's being taken seriously, being worked on by the people that need to fix it, and not being hidden or excused.

• Anonymous
  August 28, 2007
  Mark - sorry, I know you're one of the most credible living authorities on Windows, but you have a lot to learn about IP networks. A "standard Ethernet frame" isn't 1500 bytes at all - as has been pointed out, the minimum is just 64 bytes, and a realistic average for a TCP stream would be somewhere between 600 and 900 bytes. If you're using (the increasingly popular) UDP or some other connectionless protocol, the average tends to get smaller.

• Anonymous
  August 28, 2007
  The comment has been removed

• Anonymous
  August 28, 2007
  Mark, I commend to your notice the eHome tool VPT - contact John Pennock for details. Using this tool, I generated an ~85Mbps outbound TCP stream (on a 100bT network), which immediately fell to ~42Mbps when a local media file was played. This seems a bit more intrusive than your analysis indicated. VPT allows you to drive configurable bit-rates, as well, both in TCP and UDP protocols, using your choice of packet lengths (or msg sizes for some tests). You might find it interesting that playing media on the sending side of this flood test results in a larger performance penalty than playing on the receiving side. (That's what's described above) Also, increasing the message size to ~10 MTU almost completely eliminates the effect, at least on the receiving side. Hope this tool helps shed some light on the matter, when used by more capable hands than mine.

• Anonymous
  August 28, 2007
  Sounds like MS still don't understand scheduling... Or just presume that no one watches a DVD while doing other things. I tend to agree with "I like sausages"... The people responsible for this should be fired, or at least demoted to a level where they don't touch code at all (janitor, marketing, graphical people, I don't care).

• Anonymous
  August 28, 2007
  "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."  I'm going to assume that it wasn't "normal" media streaming, but DRM-protected media.  And probably not music, but video.  However, the biggest question that I have is who designed the IP stack so that it handles packets for the TCP/IP driver.  Both TCP and UDP are designed to throttle back if the CPU can't keep up with the traffic.  The DPC should be moving the packet into a buffer and then returning, not calculating TCP checksums.  Let someone interrupible do that; if the buffer fills up in the meantime, let the retransmit algoithms deal with it.

• Anonymous
  August 28, 2007
  I wish the limit was lower yet. On my wireless network, transferring data at even moderate speeds (a few megabits per second) can cause glitching in audio playback. And this is with a fast dual-core processor.

• Anonymous
  August 29, 2007
  @Erik: We had several Dual Processor P4's with Hyperthreading, and we were trying to set up MS ISA 2004 on Windows 2003 SP1.  The servers had multiple NIC's, and we ran network throughput testing software between the servers either side of the ISA servers we were testing. I think it was the combination of using NIC bonding (aka Gigabit-etherchannel) as well as having multiple processors. It seemed like the nics were continually being handled by different CPU's with some sort of context switch penalty when this happened.  We could only manage something like 70Mbits through these servers when the theoretical maximum should have been 2 Gigabit. We ran out of time and so replaced the servers with linux which did not exhibit the problem, (could exceed at least 1 gigabit throughput) However afterwards I read somewhere that there is a setting somehow to enforce each nic to a particular cpu only, which may give better performance. http://support.microsoft.com/kb/252867 explains  how to set the processor affinity to a single nic, as per the ISA recommendation in KB293640.   My point to Zachary is that it's not about optimizing code specifically for Hyperthreading/SMP, but more that since it's very common now to have HT or SMP that something would need to be done to counteract this symptom.  Perhaps the TCP/IP stack was fixed past Windows 2003 SP1 or in Vista so this is no longer applicable...

• Anonymous
  August 29, 2007
  The whole trick is to enforce unfair rules in a way the user expects.  Prioritizing audio/video playback over network traffic is very reasonable indeed!  The throttling leaves somewhat to be desired though... DPCs in the TCP/IP stack being long-running and non-preemptible (except by other interrupts) seems a little problematic.  Once the critical sections of the interrupt handlers are finished, is there any reason not to queue up the remaining work so it can be scheduled fairly against other processes? The current approach essentially results in priority inversion on behalf of the processes that are doing all of the heavy I/O because the time spent in the kernel doing interrupt processing is not charged against them.  When that happens scheduler priority classes become largely irrelevant and the rest of the system starves.  It might also undermine rate management algorithms depending on how much buffering is going on. Is it possible to prevent this case through more accurate bookkeeping that takes into account the amount of time spent performing kernel services "on behalf of" a user-space process?  If the consuming process can be identified early enough in the processing chain, then subsequent processing could be deferred unless the process has enough available CPU cycles in its budget for it to proceed.  Thus a process that performed very heavy network I/O could only starve other processes if it resided in a sufficiently elevated priority class. Essentially, that would make "realtime" priority classes meaningful in the face of DPCs.  But it sounds like a whole lot of work. So... What happens when using multi-core CPUs?  Are ordinary processes allowed to run concurrently with DPCs?  If so, can this property be used as part of the algorithm to tune throttling?

• Anonymous
  August 29, 2007
  The comment has been removed

• Anonymous
  August 29, 2007
  At such a low speed this might be due to something else.

• Anonymous
  August 29, 2007
  Obviously, if network was not demanding so much CPU, you could give more to the audio subsystem. But Vista would not probably be Vista if it did.

• Anonymous
  August 29, 2007
  I very much disagree with "I like sausages". Someone tells a story (and I can't remember who) about a programmer who makes a mistake which costs his employer a huge sum of money (millions, maybe even 10s of millions). He gets called into see the boss, fully expecting to be fired, and gets a thorough roasting. At the end of the meeting he asks the boss about handing in his security badge, but the boss replies "I just spent x-million on your education. Why would I want to fire you?"

• Anonymous
  August 29, 2007
  The comment has been removed

• Anonymous
  August 29, 2007
  I am perplexed by the claim that Internet traffic is not affected by this, and even more perplexed by its reasoning. Is the writer perhaps unaware that people with beefy Internet connections get 9 gigabits per second of bandwidth in long distance benchmarks, and still much more than 1 gigabits in real world applications?

• Anonymous
  August 29, 2007
  The comment has been removed

• Anonymous
  August 29, 2007
  Yikes!!! Why is it that whenever someone from Microsoft gives some decent technical information on a recent problem, especially ones that haven't yet been fixed, everyone seems to pile-in with a "MS-have-catfood-for-brains" mentality? I have some ideas about these demographic groups, but no substantive evidence. However, I think the groups are:

1. Generally ignorant people
2. *nix advocates
3. People who maybe didn't pass an MS interview, and don't feel it fair... (and if you're in that category and have a fix, now's the time to let the channels know...) Of course, if you really hate a particular OS behaviour, you can always switch to an alternative, or roll your own. (And if you choose the last option, then scheduling network and MM code will be the least of your worries!!)

• Anonymous
  August 29, 2007
  Bogdan, Regarding your 1st point: As stated in Larry's blog and his further comments below it, MS are already getting stick for the latency of the sound system in Vista. Adding more latency like you suggest, so that the audio thread doesn't have to wake up as often, is not an option. Larry mentions voice communication as being one thing which is particularly sensitive to latency. (Playing musical instruments through your computer is another example.) (I don't know enough about the other two points to comment.) Not directed at Bogdan: A lot of people are still talking about this issue here and elsewhere as if it were one of CPU usage. It isn't. It's not about not being able to do enough on the CPU; it's about being able to schedule things often enough that they don't glitch. The audio thread wakes up once every 10ms and does a miniscule amount of work. It needs very little CPU to work but if it misses that 10ms wake-up call then everything falls apart. Larry also states that it is very easy to make XP's audio system glitch under load.

• Anonymous
  August 29, 2007
  "Why does it need to verify each packet, one would think that can be done on the network card." Wouldn't integrated network cards tend to use the CPU to do calculations like this? I know that with Integrated graphics, and audio cards they tend use the CPU for calculations. Perhaps the same thing happens with the integrated NICs?

• Anonymous
  August 29, 2007
  So...I've been poking at this for a few hours now -- when you say that it "causes NDIS to “indicate”, or pass along, at most 10 packets per millisecond" -- what exactly is it setting? That is, I want simulate the same thing by making a call to DeviceIoControl(), presumably passing in an "OID" code and a new value -- but what value? And can I call DeviceIoControl() with IOCTL_NDIS_QUERY_GLOBAL_STATS and an OID code to retrieve the value that's being set to 10 packets per millisecond?  There's an OID_GEN_LINK_SPEED, but that seems to be the maximum physical speed and not the throttled speed. And I can't find (anywhere!) any documentation where the verb "indicates" is used to mean "throttle".  Can you point to any (other) place where the word "indicate" is used this way? Inquiring minds want to know!

• Anonymous
  August 29, 2007
  The comment has been removed

• Anonymous
  August 29, 2007
  The comment has been removed

• Anonymous
  August 29, 2007
  The comment has been removed

• Anonymous
  August 30, 2007
  The comment has been removed

• Anonymous
  August 30, 2007
  The comment has been removed

• Anonymous
  August 30, 2007
  The comment has been removed

• Anonymous
  August 30, 2007
  The comment has been removed

• Anonymous
  August 30, 2007
  The comment has been removed

• Anonymous
  August 30, 2007
  The comment has been removed

• Anonymous
  August 31, 2007
  The comment has been removed

• Anonymous
  August 31, 2007
  "If anyone would chip in it would be greatly appreciated." Gladly. "What is the point of contention? So far it looks like the only contention is computing power. Then this problem should not happen on a multi core processor" The point of contention is NOT computing power. The point of contention is making sure that every 10ms the audio buffer gets refilled. The problem they noticed what that network packet arrival caused these DPCs to be created that were long running, and were at a higher priority then the audio thread, so the audio thread would be stalled. Remember not everyone has multiple core CPUs, and Vista was designed for everyone. Secondly, how can you come in with an attidude like that? It took then Tuesday-Friday to come up with the answer? That's incredibly fast. They had to reproduce the initial problem. Then there was probably several meetings over the course of the 4 days to catch up, discuss current findings and make sure everyone is on the same page. Then they have to verify exactly what is taking place, and decide how to approach it. And all of this as well as what they need to do for any other projects that might be going on. I can't recall where I heard this but I thought I had read somewhere that this wasn't supposed to be hard coded, and it was intended to be in the registry. That's not a design problem, that 's an implementation problem. And hard coding doesn't necessarily mean the value was written directly in the code right there. It could have been some constant in another realm somewhere, and there was a disconnect between the two sub systems for what was actually going on. As for the employee who wrote this, they might have been on vacation, transfered to another group, working on other projects, (Most likely it wasn't that everyone in the networking and MM group was trouble shooting this). Event then, they might not have made the link instantaneously. Should they be fired over this? Absolutely not. It was a mistake. Plain and simple. I'm sure you've made them before. If not, I've got a job for you. I want to pay you 100k a year to invest 200k and double it. What you don't want to? But you never make mistakes, SURELY you can do it.

• Anonymous
  August 31, 2007
  I experimented with the removal of the dependency of the MMCSS Service. I copied some stuff from one encrypted drive to another (CPU hog). I play some MP3 in the background. This always worked on XP without stuttering. Now, on Vista, the sound gets heavily distorted. I'm on Vista 64 and have all the latest drivers, BIOS and have not. It seems like a bad joke. Just read slashdot. People pump out data on really outdated machines at whatever speed the machine can handle and play MP3 or Video at the same time. On Linux. No stuttering.

• Anonymous
  August 31, 2007
  The comment has been removed

• Anonymous
  August 31, 2007
  It's me again. Larry Osterman's blog has more technical information - look around http://blogs.msdn.com/larryosterman/archive/2007/08/28/windows-vista-sound-causes-network-throughput-slowdowns.aspx#4615267. Here is the contention: in Vista interrupts run only on CPU0. Both networking and media systems are driven by interrupts so they have to share CPU0. And in Vista media trumps network. It seems that other OS'es are able to distribute interrupts across different cores - see comment in Lary Osterman's blog:http://blogs.msdn.com/larryosterman/archive/2007/08/28/windows-vista-sound-causes-network-throughput-slowdowns.aspx#4619393 Well, I guess Vista can't do everything. This was an interesting problem to look at. Good geeky start to the Labor Day weekend.

• Anonymous
  September 05, 2007
  @atglabs: "But what if that thread is swapped with a higher priority thread while IRPTs are disabled?  It's a really complicated problem to solve correctly." I fail to see how you could preempt a thread that has interrupts disabled. @everyone else: It has been mentioned that disabling MMCSS seems to solve this problem quite well, so if you are being effected by it I would suggest using that as a workaround. Also, experimentation leads me to believe that disabling every service except DHCP and DNSCache lead to the best system performance.

• Anonymous
  September 07, 2007
  The comment has been removed

• Anonymous
  September 07, 2007
  I can't even begin to understand how anyone could have thought this was a good idea... much less got enough buy in to the idea that it actually ended up as a (mis)feature in Microsoft's new flagship operating system. For instance, simply having an application that like Steam (a common gaming service that you would normally leave minimized in your system tray) that relies on multimedia functionality causes Vista's network throttling to kick in as well.  I spent hours trying to figure out why my gigabit nic was transferring at a whopping 7 MB/s while I wasn't playing audio.

• Anonymous
  September 16, 2007
  The comment has been removed

• Anonymous
  September 18, 2007
  So, what's the verdict? How do I fix this? Wait for SP1?

• Anonymous
  September 19, 2007
  I am having this Vista network slow down too. I have tried all of the fixes I have found on the net but had no success. I have a gigabit network adapter but it is only connected at 100mbps and I get a transfer speed of about 600KB/s. The thing is that I am not playing any music on my system, I have disabled Multimedia Scheduler Service and Windows Audio, and a load of other services but that did not help. Is there something which is using the audio service (without my knowledge) which causing my speed cap to be enabled?

• Anonymous
  September 21, 2007
  I know that this isn't related to the sound issue. But can I make a request for myself and others: Many many people, including me and many others (googling for "TrustedInstaller.exe" will show you!) are finding on Vista that this process totally hogs the CPU and disk for minutes at a time even when no activity is going on at Vista (typically at startup, rendering the desktop performance very poor for minutes after bootup). Could Mark investigate this? Cheers, Mike Diack mike_diack@hotmail.com

• Anonymous
  September 24, 2007
  > I am having this Vista network slow down too No, you're not. The symptoms don't match in the slightest.  If you aren't playing music, and you've disabled MMCSS then this issue can't possibly apply to you.  Also, the audio issue doesn't affect what speed you're connected at, just how many packets you can process. Also, the speeds you're getting are waaaaaaay lower than usual- or almost even worst-case scenarios for the audio throttling problem (unless all your packets are meant to be around 62 bytes, that is) There's something else going on in your system, I'm afraid.  Try netstat -s and looking for packet loss symptoms

• Anonymous
  September 27, 2007
  This issue can have a heavy influence on systems with 100MBit network connections too! My database application usually has a network throughput of 1800 packets/s. Starting Media Player will decrease this to 800 packets/s! Database is connected by ODBC via TCP/IP to SQL-Server. It's the same effect using Sybase/Anywhere database instead. Quicktime and MusicMatch player showing this effect on startup, on WMP you have to play something to get it. Copying files on the network is not effected by this issue on my 100MBit connection.

• Anonymous
  September 27, 2007
  So what if I use Winamp to play MP3s on my Vista machine. Will I get hit by the network throttle problem too?

• Anonymous
  September 28, 2007
  MS is a first class, leading edge software company. The real problem here is the extreme difficulty of designing highly complex software that works effectively. I am sure that MS will sort it. There were many difficulties with xp and it needed 2 service packs. Thank you Mark for the usual interesting and informative article.

• Anonymous
  October 27, 2007
  The comment has been removed

• Anonymous
  October 30, 2007
  what a disgraceful train wreck. While I appreciate the post and it not being covered up, I am really sick of post after post talking about these sorts of issues cast as feature related. It is absurd to the point of negligent. As an Ultimate owner I cannot even copy a file from my desktop hard drive over USB to the USB backup drive while listening to music! All while running 4GB of ram, dual core,great graphics card, and the list goes on. It is not acceptable to release what amounts to garbage and charge for it. These things should have been fixed immediately! Not nearly a year after release. Most users do not care what the reason is, new features, rewrites etc. what they care about is basic funtionality that has been working for multiple generations not working any longer. There is no excuse or reason that will make that acceptable. This is all coming from a long time Microsoft customer and one who understands it is a complex business. It is not complex, however, to understand that certain basic functionality should run without issue, especially when it has been generally available since 1995.

• Anonymous
  October 30, 2007
  Say again?  This affects network transfers, how on earth would it affect your USB transfer?

• Anonymous
  November 01, 2007
  I would think throttling should be dynamic, in the sense that the NDIS driver only needs to be notified if Windows Media notices that it gets close to getting into trouble. The amount of throttling should never be fixed even within the one system.

• Anonymous
  November 02, 2007
  If they can't fix the sound problems, Microsoft should give us a copy of XP since it "Just Works", unlike Vista that does nothing but waste our time.  

• Anonymous
  November 07, 2007
  Users expect multimedia applications, including music and video players, to offer a seamless playback experience. However, demand for the CPU by other concurrently running applications, like antivirus, content indexing, or even the mail client, can result in unpleasant hiccups. To provide a better playback experience, Windows Vista introduces MMCSS to manage the CPU priorities of multimedia threads.

• Anonymous
  November 16, 2007
  The comment has been removed

• Anonymous
  December 02, 2007
  The comment has been removed

• Anonymous
  December 02, 2007
  Has someone tested the behavior with SP1? Is it really solved?

• Anonymous
  December 03, 2007
  The comment has been removed

• Anonymous
  December 04, 2007
  i searched the whole web for others having the same problem since weeks, im so happy to find some people with the same issue I get some really good transferrates with a fresh booted vista: Packet size 32k bytes: 115145 KByte/s Tx, 113827 KByte/s Rx. Which is almost the best you can get on 1GBps .. but if im running winamp, windows media player or even QIP (a messenger) i get those results: Packet size 32k bytes: 17100 KByte/s Tx, 7267 KByte/s Rx. Which is only about 10% of the available bandwidth   I tried almost every parameter you can change... Auto-tuning off, Flow control enabled etc. i dont think its depending on your software setup, my second computer using Vista (completely different hardware) has the same issue. Anyone tried Windows Vista 64bit ? I only could try 32 My concerned Hardware: Gigabyte GA-965P-DS4 using onboard Realtek RTL8168B/8111B Family PCI-E Gigabit Ethernet NIC, intel Core2Duo 6600, 2 GIG DDR 800 RAM and a Creative X-Fi Extrememusic soundcard. the second pc: ASRock 939Dual-SATA2, AMD X2 4200, 2GIG DDR1 RAM, Intel Pro 1000 GT Ethernet NIC SWITCH: Netgear GS108, 8 Port, 10/100/1000Mbit

• Anonymous
  December 06, 2007
  The comment has been removed

• Anonymous
  December 15, 2007
  Hm bad for me: I have(in germany) a broadbandconnection with 50mbit/10mbit(down/up) and iptv which is streaming with multicasttechnologie. So playing musik or video i have only a 0.1/0.02mbit connection. That is not really funny. As long as im a Softwaredeveloper and the problem exists, the first Person, who is asked from the family and co by computerproblems, will get a alternative os or as backfall windows xp(from ebay oem version(german law :P)

• Anonymous
  December 20, 2007
  Vista SP1 RC1 does not fix the issue either :( I would expect at least a registry key to increase the 10000 packet limit to a value I can choose. And disabling MMCSS is not a viable option either, as the new user-mode audio mixer apparently uses very small buffer sizes, casing glitches even on a dual-core system without MMCSS enabled.

• Anonymous
  December 21, 2007
  The comment has been removed

• Anonymous
  January 10, 2008
  Hi, same problem there. If i dont play music, i got 100-110 MB/sec. over my gigabit network. if i play music, speed drops to 5-8 MB/sec. are a solution or a workaround available? i test SP1 RC but it hasn't fix this. so, im back on xp64 now. back on vista if the problem are fixed or a working workaround available. be stay tuned in this thread

• Anonymous
  January 11, 2008
  The comment has been removed

• Anonymous
  January 12, 2008
  The comment has been removed

• Anonymous
  January 17, 2008
  You can just about double your speed to 18 megs per second if you go to registry setting HKLMSOFTWAREMicrosoftWindows NOTCurrentVersionMultimediaSystemProfileTasksAudio Then set Clock Rate to be 5000 instead of 10000.  I don't have a clue why this works but it doubled my download speed from 9 megs to 18 megs.

• Anonymous
  January 31, 2008
  The comment has been removed

• Anonymous
  March 07, 2008
  Microsoft has a KB article that allows you to configure how much throttling happens on the network or just turn it off.  It only applies to Sp1 and I haven't tested it yet but will when I get back home.   http://support.microsoft.com/kb/948066

• Anonymous
  April 20, 2008
  multimedia playback is still broken in SP1. the idea that vista should play mp3s with 10ms latency, was really brilliant. Honestly anybody who approved this design should be fired. btw. are Steve Ball and Larry Olsterman still in MSFT?

• Anonymous
  April 29, 2008
  The comment has been removed

• Anonymous
  May 07, 2008
  The comment has been removed

• Anonymous
  May 16, 2008
  FWIW on the subject of media playback, video, audio etc. I was having problems with music tracks and video (audio) skipping in Vista Ult sp1, Core 2 duo, 2Gb ram. Music playback skipping in iTunes and WinAmp, Video (audio) skipping in Win Media Player and Quicktime. So I read through this thread (thxs Mark for the article and insight), tried a few things with no success, still audio playback skipping). Then, I disabled my 'wireless NIC' and the audio skipping problem disappeared, re-enabled it and the audio skipping came back, disabled it and the skipping went. So at the moment the audio playback skipping has ceased. Not looked into the network throughput issue yet. Does anyone else get similar behaviour to this? The audio playback skipping was driving me to distraction and after browsing for solutions, I couldn't find any that worked for me.

• Anonymous
  May 16, 2008
  Ahh, I think you solved my mystery below: I have a Vista Ultimate based HTPC (which used to run MCE 2005 prior to my doing a clean Vista install) and a Win XP Pro desktop on the network. Both machines have Gigabit ethernet, and are connected via Cat 6 cable across a D-Link DGL-4300 Gigabit router. Jumbo packets are disabled on both ends. Both have latest chipset drivers, NIC drivers, Vista patches, etc installed. Prior to clean-installing Vista, I was getting transfer speeds of 35 MBytes/sec between the HTPC and the WinXP Pro desktop. After clean-installing Vista, I noticed that this dropped to a measley 11 MBytes/sec! I've tried several solutions, including turning off Vista's firewall (transfer rates went 11 MB/s -> 16 MB/s). I also tried turning off autotuning (no difference) and turning off remote differential compression (minimal difference). Finally, I realized something important: If I had VMC running in the background (idling mind you, ie. not playing video, not accessing network, etc), then my transfer rates were limited to 16 MB/sec with Vista's firewall off. However, if I exited completely out of VMC, then my transfer speeds shot back up to 35 MB/sec to the WinXP Pro desktop! I think this is the reason why loading ISO files from within MyMovie's VMC interface (auto-mounted through Daemon Tools) takes FOREVER with Vista (45-60 secs), but was relatively fast in MCE 2005 (~10 secs). Anyone have any ideas why VMC running in the background would cause a > 50% drop in network speeds, even though VMC isn't doing anything with the network?

• Anonymous
  June 21, 2008
  Leo Davidson commented on August 28, 2007: "MS (or at least two MS employees in their blogs) are being quite open about the fact there is a problem that needs fixing." Yet here I am in late June 2008, with Vista SP1+Hotfixes and the problem is as bad as it has always been. Firing the guys who invented this would be too good for them. I'm not sure if "hanged, drawn and quartered" would be appropriate, but it would be a start - considering what they have done.

• Anonymous
  June 25, 2008
  The comment has been removed

• Anonymous
  August 08, 2008
  The comment has been removed

• Anonymous
  August 10, 2008
  The comment has been removed

• Anonymous
  August 11, 2008
  Exact same problem, after a clean reboot, my system can play vids and download 500kb/s easy, but after an hour or two, any network activity causes media to jump, and also my mouse to jump and basically my system becomes unusuable at around 500 kb/s activity.  Basically my system is unusable to download torrents or any file sharing. Pretty rediculous.

• Anonymous
  August 16, 2008
  Hi Mark, My Laptop have the similar problem: Most of MP3 or CDs play properly in XP or earlier windows PCs, but they always have some disruption problem with my new Vista PC, either "glitch, sputter or something else". It's very annoying as I always enjoy listening musics from my PC (and seldom care about network speeds). When the wireless network was switched off, music playback seems getting smoother. But if I chose to disable the MMSC, the laptop can not even play any musics. Can you or anyone help on this? Thanks in advance.

• Anonymous
  August 28, 2008
  The comment has been removed

• Anonymous
  October 25, 2008
  Hmmm, it's quite funny ... I have Vista SP1 with the same problem. I lost many hours with tuning stupid speaker fill with no success. Rear speakers just doesn't work anymore in Vista. Also I spend many hours with this stupid LAN problem ... and the solution is just f***ing easy! Disable MMCSS! It should be by the default in SP1 but it isn't. Then it should be at least on Microsoft homepage but it isn't. Vista is out about 2 years and nobody fixed this? Well I'm quite dissappointed ... Aero is cool, but it cannot be altered that suxx. Taskbar colors are absolutely flat and hard to distinguish active application window ... alttab is absolutely awkward, hopefully there is undocumented AltTabSettings which disables that "cool & stupid" thumbnails ... if I would decide now if I spend tens of hours solving Vista stupidity (like missing standard desktop themes which could cost 10kb or less on installation DVD?), I would stay on XP ... maybe with Windows 7 I will be so dissatisfied that I will finally "upgrade" to XP again ...

• Anonymous
  December 17, 2008
  I have tried this and every other tweak I could find. nothing has fixed this problem for me. I hate vista

• Anonymous
  January 10, 2009
  I have tried it on vista x64. I noticed that the network throughput tripled!! (from 12MB/s to 37MB/s) when media player was running. I have Intel Quad Penryn processor and video playback performance is not a problem at all. Whoever programed this stupid prioritizing in vista deserves the worst programmer of the year title. his manager too.

• Anonymous
  February 19, 2009
  The comment has been removed

• Anonymous
  March 24, 2009
  The comment has been removed

• Anonymous
  March 24, 2009
  I found how to tweak the Systemresponsiveness and NetworkThrottlingIndex, but that didn't work either. Nothing works! Sound still stutters terribly whenever I do some torrenting or something else involving networking activity. I have a quadcore(penryn) cpu, 4 gigs of ram, a (disabled for testing now) wireless network usb-adapter, two network cards ,one for wired internet via the router and one attached to a network printer(which i will attach to my router, but it has stayed directly attached for a while due to my laziness) And I don't use an integrated audio card, instead I use a professional sound card, the ESI Juli@. Strange thing is that it has worked flawlessly for half a year (since I started using vista 64) up until this week. strange......

• Anonymous
  April 07, 2009
  Thanks Mark for the explanation and the work the Vista and Win 7 teams are doing to make it possible to do Pro Audio on the Windows platform. It appears that the best approach would allow enough settings to be expert user adjustable so that a computer can be optimized for a particular use if needed. In my case I use Vista x64 to run Cakewalk Sonar 8.3.1 for music recording and mixing. Above average audio performance with gauranteed low latencies is needed for that type of application. When multiple tracks of audio are being processed and monitored to produce a glitch free music mix, I certainly don't care if the network slows down. I can also understand that a casual MP3 listener doesn't want their network to slow down in order to prevent an occaisonal audio click. These 2 instances of Windows audio usage are certainly on opposite ends of the low latency requirements spectrum. Please give expert Vista and Win 7 users the options needed to tune their own audio destiny to perfection. Thanks.

• Anonymous
  April 07, 2009
  I changed my NetworkThrottlingIndex to ffffffff (which disables throttling) and i now enjoy full network speeds on my gigbit network while playing audio and video. I haven't noticed any Problems with audio stutters. However I do have a dedicated Soundblaset XFI so that may account for it.

• Anonymous
  April 17, 2009
  Setting NetworkThrottlingIndex to 0xffffffff works fine with my Vista x64. :-) Thanks!

• Anonymous
  April 23, 2009
  I can't help but wondering why this registry entry "HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesAudioSrv Key: DependOnService" includes MMCSS. Why do you have a service required if it's not actually needed for the proper function of the services descending from it? I'm willing to do a quick disabling of this service in all my installs but why do I have to edit the registry before you'll let me stop a non-essential service without completely disabling my audio? Can we get this fixed in the next service pack so people who don't want this service (it interferes with running media from a network share @ 100mb speed and made my life miserable when I tried to provide some training videos from File Sharing) can disable it easily.

• Anonymous
  November 17, 2009
  Can anyone comment on whether this issue affects Windows 7 at all. Was the throttling algorithm redesigned or removed? Cheers, Mark

• Anonymous
  June 16, 2010
  This is a great blog post. . It's really nice and informative post. Thanks so much.