Mark Russinovich On Vista Network Slowdown 423
koro666 writes "In his latest blog post, Mark Russinovich analyzes the network slowdown experienced by some users when playing multimedia content. 'Tests of MMCSS during Vista development showed that... 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... [to] pass along, at most 10 packets per millisecond (10,000 packets per second)... [T]he 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.'"
Re:Okay... (Score:2, Informative)
Re:Failed engineering (Score:5, Informative)
If you're talking about MTU (which is 1500 bytes, not 1.5K), that's the maximum, not the standard.
The average packet size depends on type of network traffic. On most ethernet networks I've managed, average packet size was 700 to 800 bytes.
Never Mind the Bandwidth, Feel the Vibe (Score:1, Informative)
Microsoft is focused on improving its products and reaching out to new markets. Meanwile, the comments on Slashdot continue to get less informative and relevent to people outside its core audience. From being some great visionary power that could tear down someone's server with the mere waving of a hand it's become the problem. It has no clear forward vision and most servers just shrug off the famed Slashdotting. Microsoft has changed. The world has changed. Meanwhile, Slashdot just tears itself up in frustration.
Wake up.
Re:Okay... (Score:2, Informative)
My wife had an e-Machines 1.2 GHz Celeron machine (purchased before we were engaged) with an el cheapo Intel 810 chipset. When she was still running Windows XP, she'd complain all the time about audio dropouts -- I found that these occured during high periods of disk activity or network traffic. Adding memory improved things from the disk side, but network I/O still sucked on XP. When we switched her to Fedora Core 4, and later to Ubuntu Breezy, things improved a lot. I'm guessing if Vista didn't have such high system requirements, this feature would actually have helped her.
On her new machine, an Athlon 64 x2 3800 with 2 GB of RAM and a nice VIA chipset with on-board 6-channel audio, on-board GigE, etc., I'm sure she'd be complaining about the network performance instead of dropped audio if she were running Vista instead of Ubuntu Feisty.
Re:Okay... (Score:5, Informative)
No, in other words, Microsoft/**AA tried controlling something they weren't in control of before.
Where do you want to go today, indeed.
Re:Failed engineering (Score:5, Informative)
Okay. But, math doesn't match up with the numbers you typed.
1,500 Bytes is not the average packet, it's the maximum on most ethernet segments. But, the subject original subject is a stressful network environment effecting music playback. 10,000 packets per second is REALLY cranking the data.. so this isn't simple WWW browsing, etc. This is bulk file transfer. So, a large average packet size becomes more realistic in that environment.. say 1400 Bytes.
1,400 Bytes * 10,000 Packets per second = 14,000,000 BYTES / sec = 112,000,000 bits/sec = 112 Mbps
Obviously, that's not even possible on most common home networks, which are 100Mbps. But, an increasing number of people are doing Gig-E at home, in which case 112Mbps is well within the norms for bulk file transfer.
On modern fast multi-core systems, enforcing a pre-set cutoff for packet rate seems like a poor choice. As the linked article showed, the system had plenty of CPU left and didn't need to be throttled at that low a rate. There are also NIC and Driver factors in there.. others might be more or less efficient than the author's equipment -- offload of parts of packet processing and interrupt minimizing techniques can make a big difference.
In any case.. It's easy to say "that's what you get for using MS / Vista". But, really.. that's true in this case. Windows gives you the lowest common denominator. It's designed to be usable with any hardware, by users of any experience level, and to avoid problems by assuming a worst case scenario. So, that's the kind of solution you get given the assumptions MS uses. As we've seen in the Linux world, the solution is to take great pains to build a scheduler that holds up to ridiculous stresses.
Re:Completely Unfair Scheduler (Score:1, Informative)
Re:And then again... (Score:3, Informative)
You're almost right. The limit is for half-open connections: these are connections in the process of being made; however, this can effectively limit your amount of connections for things like bittorrent, because you connect slower than other peers. When you're constantly disconnecting and reconnecting to new peers every second, it becomes a problem. Hitting an artificial cap on half-open connections causes problems with surfing, too. Some bittorrent programs, like uTorrent, have a setting to limit the amount of half-open connections, so they won't interfere with other web activities. Fortunately, for Vista and XP, which employ the hard limit of half-open connections (tcpip.sys), there are patches available.
Disabling MMCSS fixes the issue (Score:3, Informative)