Mark Russinovich On Vista Network Slowdown
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.'"
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. you would get a transfer rate of 1.5 MB/s, or in more appropriate data transfer units, about 12 Mb/s. That's way faster than most internet connections available on cosumer PCs. Even if your flawed assumptions about packet size were true, how about people with 100Mbps or gigabit networks that aren't downloading from the internet, but transferring files on a LAN? I also know quite a few people with 10 Mb hubs still operating on their network. Ahh, and because there are a small number of people stuck with 1995-era equipment, then it's OK for everybody else to suffer horrible network performance?
No, in other words, Microsoft/**AA tried controlling something they weren't in control of before.
Where do you want to go today, indeed.
...Rob
The American Dream isn't an SUV and a house in the suburbs; it's Don't Tread On Me.
> Let's do some math
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.