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

Aaah

[caluml]

Aaah, it's those pesky DPCs in the MMCSS. It's so obvious really.

Failed engineering

[setagllib]

Once again, over-complication and stupid engineering lead to a humiliatingly bad operating system. It's obvious it didn't receive a modicum of real testing.

Re:Failed engineering

[morgan_greywolf]

Almost, but not quite. Really, it's Microsoft's drive to appeal to the least common denominator. Dumb end-users aren't likely to notice a speed decrease in their network throughput -- not even a significant one. So maybe they did test it, but ignored any performance feedback about the network because it was ignored as smart power users being 'overly picky', since their target customer requires that the CD cases be printed on drool-proof cardboard.

Re:Failed engineering

[blahlemon]

On the other hand (and I'm not disagreeing with you) maybe when they were testing the media functions of the operating system they didn't look at the network traffic performance cause they've got nothing to do with each other. Kinda like hearing a noise in your engine; you're not going to check the drivers side door hinges. On the other hand, you're right about the least common denominator. Fortunately we've come to expect Microsoft to play to the least common denominator.

Re:

[morgan_greywolf]

On the other hand (and I'm not disagreeing with you) maybe when they were testing the media functions of the operating system they didn't look at the network traffic performance cause they've got nothing to do with each other.

They have nothing to do with each other -- until you're listening an Internet radio station or a webcast of the keynote from [insert your favorite conference here].

Re:

[blahlemon]

Yeah, I was thinking about that as I typed the comment but neglected to mention it. Actually, I need to correct my own post, a closer look at the article reveals that it is throttles network traffic by design, an effect that *shouldn't* be noticed in a 100 mb environment. In theory. Sorta. Cause no one needs more then 100 mb.

Re:Failed engineering

[morgan_greywolf]

Cause no one needs more then 100 mb.

Yeah, I seem to remember Bill Gates saying something like "A 100 megabits ought to be enough for anybody!"

Err...or was that something else? ;)

Re:

[Bartold]

Actually, this has nothing to do with failed engineering or Microsoft and everything to do with all of you cheap end users that don't want to shell out money for hardware accelerated audio. Software audio solutions require fine grained timing in order to minimize the mixing latency. Hardware solutions only require big buffers of data to achieve virtually zero CPU usage. I just want to know how many of you suckers out there paying more $1000 out there for a 5% faster CPU instead of $50-$75 for a sound car

Re:

[T-Bone-T]

You've already been made fun of for saying it, but I would like to add a qualifier that I can't believe nobody ever uses.

Cause no one needs more than 100mb, YET. I don't care that my network is slowing down, it won't slow down enough to hamper my internet connection.

Re:

[Master of Transhuman]

Or you're one of maybe 100 million office workers who play MP3's they have on the workstation with Windows Media Player or Winamp through headphones while they're working on files over the local office network.

I can just understand Microsoft not being aware of that scenario - except you can guarantee that EVERY SINGLE MICROSOFT EMPLOYEE just does that. So nobody thought to test that scenario - that was just dumb of Microsoft.

The real question is why the engineers involved didn't understand the size of the i

Re:Failed engineering

[Brian Gordon]

They specifically said they throttled network speed. It's not like something they should have tested for and never found, it's something they did themselves.

And then again...

[Spy der Mann]

it was an IMPOSED, HARDCODED limit WITHOUT ASKING the user. They could just add a registry entry of "maximum network packets per millisecond when playing multimedia files" or something.

Microsoft has a long history of hardcoding stuff without thinking of power users. Remember the 10-limit for open TCP connections per program? They did this because viruses and malware open many TCP connections. "Hey, what about P2P?" "What's P2P?".

Re:And then again...

[Lonewolf666]

They could just add a registry entry of "maximum network packets per millisecond when playing multimedia files" or something.

Better yet, allow "throttling as needed if multimedia buffers run low". That would allow unimpaired network performance in systems with enough CPU power.

But then again, that would have required early planning to include the necessary feedback in audio and graphics drivers. I speculate that the problem was discovered late in the development of Vista, and since nobody wanted to be responsible for another delayof Vista's release, some quick hack was applied ;-)

Re:And then again...

[AaronW]

I had to implement something like this to dynamically throttle packets back based on the load in a router type box. It's not rocket science. I think Linux (if it doesn't already do this) could do it fairly easily with their NAPI networking interface, since the OS can slow down polling and assign a higher priority to audio and video.

Re:

[Laebshade]

Remember the 10-limit for open TCP connections per program? They did this because viruses and malware open many TCP connections. "Hey, what about P2P?" "What's P2P?".

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 p

Re:And then again...

[Xtravar]

it was an IMPOSED, HARDCODED limit WITHOUT ASKING the user.

Not to start a flame war, but isn't this exactly what people find so great about Macs - that the OS designers made all the decisions for them?

Most coders don't want to add a registry setting. Most users don't want to touch it.

There's obviously just something wrong with their big picture view if they can't get this shit straight. It's probably because the network and multimedia teams are separate and don't know what the others' doing.

Not just piracy!!!

[marcosdumay]

P2P is also widely used to dowload free software! Mainly Linux distros! Oh... Nevermind.

Re:Failed engineering

[TubeSteak]

It's not like something they should have tested for and never found, it's something they did themselves.

After reading your post, the parent post and the grandparent post (and every other +3 post in the thread) I feel like I'm the only one who made it to the end of TFA:

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.

Things they apparently didn't bother to test for:

• Multiple NICS
• Gigabit NICS
• Multiple CPUs/Cores

Those things just seem like glaring oversights, especially considering how many people have wifi in addition to the mobo's onboard NIC.

One thing I don't get is how he managed 41.61% CPU utuilization [technet.com] while transferring a file. Did he have the ethernet equivalent of a winmodem?

Re:Failed engineering

[click2005]

One thing I don't get is how he managed 41.61% CPU utuilization while transferring a file

4.4% to draw the moving file animation (it re-reads it every time the anim loops).
3.8% to report to MS about the file you're copying.
2.1% is wasted on old code that constantly scans memory for pictures of rabbits (Balmer is scared of them)
1% is needed for WGA.
2.5% because Vista constantly swaps all application code in and out of the first 640k. Bill still believes its enough.
1.7% to actually copy the file.

the rest is just wasted to make CPU graphs look pretty.

Re:Failed engineering

[Just Some Guy]

1% to bring them all and in the darkness bind them. In the land of buffers, where the packets lie.

Mod parent redundant ;-)

[Ernesto Alvarez]

1% to bring them all and in the darkness bind them. In the land of buffers, where the packets lie.

So, basically the GP poster was right: 1% goes to WGA.

Re:Failed engineering

[_KiTA_]

One thing I don't get is how he managed 41.61% CPU utuilization while transferring a file. Did he have the ethernet equivalent of a winmodem?

No, he had the OS equivalent of a Winmodem.

Re:Failed engineering

[daeg]

On the contrary, network and media playback have a lot to do with each other. Don't forget Microsoft has a home media server coming out soon. What good is great media playback if you can't play it over the network?

Re:

[Rude Turnip]

The decoding of the sound takes place on the receiving end (ie xbox, media receiver)...

Re:

[CastrTroy]

Me thinks my math was a bit wrong. 1.5 K per packet, at 10,000 packets is 15 MB/S, or 1.8 Mb/s. That is actually quite slow, especially if you're trying to transfer a file over your local network. I really should learn to check my math. Feel free to mod me down.

Re:Failed engineering

[schon]

Let's do some math, 10,000 packets, at a standard ethernet packet size of 1.5 K

Sorry, what standard are you talking about?

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?

Re:Failed engineering

[WhiteWolf666]

There's a better criticism. These "maximum" speeds are NOT sufficient to stream medium-to-high bit rate video, particularly HD stuff, something which should be a strength for a "media center" OS.

Furthermore, in the workplace, many people listen to music and access large files on network shares. Clearly, Vista is *broken* for these uses. Not a good indication of Vista being business ready.

Frankly, I don't know why Windows is considered the best business OS. You're much better off with a unixy OS in any environment where gaming isn't important.

Re:

[splutty]

Let's do some math, 10,000 packets, at a standard ethernet packet size of 1.5 K, you would get a transfer rate of 1.5 MB/s, or in more appropriate data transfer units, about 12 Mb/s.

Uhm....

My *internet* link is 20Mb... So yeah. I won't notice...

Re:Failed engineering

[tji]

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

Re:

[dave420]

So by your logic various flavours of Linux are even more humiliatingly bad than Vista, as I've had a slew of problems on Linux that make this bug seem like desired functionality. If you're going to troll, at least try and do it logically!

Re:Failed engineering

[setagllib]

Various flavors of Linux can take a flying leap. The mainline Linux kernel is generally in very strong shape, and I say this after spending years loathing many bad choices in Linux. Many mainstream distributions are doing very well too. Most of all, Linux does not compromise basic performance for "rights management", which Vista does.

Vista's worst engineering decision is to make a system optimized for restrictions and money-farming, not for user experience. The WGA breakdown is the best example. The legitimate users who paid a ridiculous sum to use Vista's 'ultimate' features (you know, the ones which are free in Linux and at least standard in MacOSX) had their systems crippled, and the pirates who bypassed WGA were not even affected. The whole feature does exactly the opposite of what it was supposed to do. That's failed engineering, any way you look at it.

Re:

[cliffski]

have you used vista?
it's a far better user experience than windows XP. if they did put some DRM related stuff in there, I haven't noticed, nor will 99.99% of its userbase.

Re:Failed engineering

[grasshoppa]

have you used vista?
it's a far better user experience than windows XP. if they did put some DRM related stuff in there, I haven't noticed, nor will 99.99% of its userbase.

Jesus, have *you* used vista? The user intended user experience could be orgasmic, but I'll be damned if I can get the thing stable given the state of drivers for my vista approved hardware.

In a year it may be better than XP ( and at best, marginally so ), but right now it's hit and miss.

Re:Failed engineering

[dave420]

So you don't have any idea what you're talking about. This issue has nothing to do with rights management or money farming. It was a mistake that is being rectified. As for the WGA breakdown - that didn't affect anyone negatively for more than a day or two. Microsoft issued help to get it fixed for those hit, and all is well.

Linux isn't in strong shape on the desktop. It doesn't have the application support it needs, its drivers aren't able to perform as well as their Windows counterparts, which means it's constantly making excuses for not being able to use 100% of the computer its on. But then everyone knows this.

I'd rather have an OS that runs every bit of software I want (including games, video editing, office suites, open source apps, etc.) and may have occasional problems, than one that doesn't run everything I want, and still has occasional problems.

I admire your spirit, though :)

Re:

[ZeroExistenZ]

Forum.Post(structures.Forums.SlashDot,(bug.OS == structures.OS.Windows ? "windows is engineered by stupid monkeys" : (bug.OS == structures.OS.Linux ? "It'll be fixed in no time, as expected" : "In sovjet russia " + bug.OS + " bugs you!")));

Re:Failed engineering

[gladish]

As a long-time Linux user (over 10 years) I was always in the "Windows Sucks" camp. Recently I decided to really understand windows at the level of my understanding of Linux. I just finished a 5 year stint doing Linux systems level programming with the latter 2 years doing more on BSD. After reading "Windows Systems Progamming" by Johnson Hart, I was astonished at the complexity of the windows api (win32). Things that are really straight forward with posix programming are a genuine mess with win32. The nubmer of synchronization mechanisms is overwhelming. But after a while you begin to appreciate the flexiblity that the system provides. I decided to move on and buy "Microsoft Windows Internals" by Russinovich and Solomon and am currently reading that. Again, they expose some nasty details of windows and again you'll be saying to yourself, "Oh my god, they over engineered the shit out of this thing." But they continually bring up what the design goals were and again you begin to appreciate what Microsoft has accomplished with windows. Of course you can't expect the system to be flawless. Linux certainly isn't. If you're a windows user, just be glad there are people like Russinovich who can actually understand the windows kernel enough so that Microsoft can continue to make improvements. If you couldn't care less about windows, then I'd still reccomend either book. If you're into Linux (or any posix-like) systems level programming, check out Johnson Hart's book. It's audience is unix converts. If you're just interested in the windows kernel or are a sys admin, check out Russinovich's book. It's really interesting.

Re:

[JasterBobaMereel]

This would be the same Mark Russinovich who set up his own company to sell the tools he wrote to find out why windows was so bad and to fix the holes and mistakes in Windows, and so he could write books telling people how to work around the flaws in windows (sysinternals)

And when Microsoft found out people were listening to him... they bought it and hired him to be a Microsoft Advocate, but don't seem to have listened to him ?

The Windows kernel (NT Kernel) was designed by Dave Cutler (ex of DEC) who designe

Re:

[Z0mb1eman]

>But after a while you begin to appreciate the flexiblity that the system provides

>you begin to appreciate what Microsoft has accomplished with windows

I've always assumed there's more to it than just "Windows sucks", but I've never had the time to learn about how Windows and Linux work more in-depth so I can meaningfully compare them (nor will I anytime soon).

Care to give an example or two of things Windows gets right?

Okay...

[WhatAmIDoingHere]

So why can my Windows 98/95/2000/ME/XP computers play mp3s without this happening?

Re:

[Reverend528]

So why can my Windows 98/95/2000/ME/XP computers play mp3s without this happening?

Slower Network Cards.

Re:Okay...

[KiloByte]

So why can my Windows 98/95/2000/ME/XP computers play mp3s without this happening?

Slower Network Cards.

Then why exactly XP can handle the music just fine on the very same network card on the very same computer on the very same network?

Re:

[morgan_greywolf]

MMCSS is the Multimedia Class Scheduler Service, which a new feature in Vista -- it is not in 98/95/2000/ME/XP. That's why.

Re:Okay...

[rudy_wayne]

"MMCSS is the Multimedia Class Scheduler Service, which a new feature in Vista -- it is not in 98/95/2000/ME/XP. That's why."

Winodws XP -- can play an MP3 file and video file at the same time with no reduction in network speed.

Vista -- same computer, same hardware, -- major reduction in network speed.

In other words, Microsoft tried to "fix" something that wasn't broken.

Re:

[morgan_greywolf]

In other words, Microsoft tried to "fix" something that wasn't broken

Well, on some machines and in some environments, heavy network traffic can cause an XP machine to slow down, particularly on older/slower hardware. Geeks tend to run stuff that, even if it's not the latest, is amongst the top performers for its generation.

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 p

Re:Okay...

[rbochan]

...In other words, Microsoft tried to "fix" something that wasn't broken.

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:

[Daengbo]

Shouldn't any computer powerfull enough to run Vista be "powerful enough to not need such a draconian throttling?"

Re:

[Kokuyo]

So the interesting question would be this: Does this happen only on Vista machines in gigabit environments or also on 10/100 cards?

I was of the impression that it happens with both types. But trying to remember what leads me to believe that I'll have to admit that I obviously only assumed it to be so. So is there anyone who can give us a definite answer to this?

Re:

[Johnno74]

You didn't read the article did you. The rate that the network throughput is throttled to is normally greater than the bandwidth of a 100MB card - if it wasn't for an unfortunate bug where the throttling factor is applied for each network card in your system.... 3 network cards (most laptops - wired, 802.11, bluetooth) and you have the throttle applied 3 times.

Re:

[billsf]

So why can my Windows 98/95/2000/ME/XP computers play mp3s without this happening?

Slower Network Cards. ...but today we have faster LANs, "Gigabit" (400MB/s with 'PC arch') is standard and 10GB is moving in. Therefore:

Higher Bus bandwidth...

BillSF

(Troll warning: redundant)
Crappy software aside, 32bit x 33MHz is rather limiting compared to the 64bit x 133MHz standard that has been with us for awhile. IMO, it appears Microsoft has failed to keep up with the hardware. If MS had put less energy in the hoax call

Re:

[joshv]

"could the DRM servicing overheads have anything to do with it? Are these files causing the issues DRM protected etc?"

What "DRM servicing overheads" are you talking about? You don't know really do you? You are just repeating an idiotic meme you heard elsewhere.

The issue occurs even when the user is playing unencrypted content. It has nothing to do with DRM.

Re:

[Anonymous Coward]

Because they're not Vista. Think of Vista as the operating system that the movie and music industry produced.

Re:

[HalifaxRage]

Stop living in the past! Sure you can put your old "XP" records on the jukebox, grandpa, but this is 2007! It's the future man! Now I'm off to take the flying car to dinosaur island!

Re:

[the_arrow]

Or, for that matter, almost any other operating system?

Re:

[LarsWestergren]

So why can my Windows 98/95/2000/ME/XP computers play mp3s without this happening?

Because they don't have the Multimedia Class Scheduler Service that Vista has, which ups the thread priority, which in turn causes a throttling of network traffic because heavy network traffic interrupts might disrupt playback to the end user? (Only a bug caused WAY too much throttling) You didn't read the article, did you? :)

Re:Okay...

[Opportunist]

The question stands, though, why is an older system capable of playing multimedia content without throttling the network throughput on the same hardware? We're facing the same silicon, so whatever Vista uses to schedule or priorize, it has to mean Vista is less performant than its predecessors. If it was not, there would be no throttling, since said previous versions are capable of playing MMC without throttling the NIC.

There are two possible scenarios now:

1. Vista is actually less performant and the inferior system.
2. We're just plain lucky that we get to play MMC on XP and 2k without interruption, and the system throttles network performance on a "just in case" basis. In this case it's a bug that should be fixed.

Re:

[LarsWestergren]

That is the dumbest fucking thing I've ever heard in my life. Right now my bandwidth is all but maxed out (32 player enemy territory server running in the background). Not ONCE has bandwidth saturation EVER made any media that I've been playing choppy, unresponsive, or have any "glitches" as they describe them.

No, neither have I, but as the article states, tests by Microsoft showed that very heavy network traffic MIGHT in some circumstances affect media playback on Vista. You often have to decide if you wan

Re:

[joshv]

So, you are maxing out a gig-E pipe? If you'd read the article, you'd know that even at 100 mbps speeds, the throttling is not required for glitch free playback.

Oblig

[phasm42]

10,000 packets/second ought to be enough for anyone.

No problems here

[Anonymous Coward]

I have [Cancel][Allow] no idea [Cancel][Allow] what slowdowns they [Cancel][Allow] could possibly be [Cancel][Allow] talking about!

I can hardly wait

[bunhed]

Can't wait until the "glitch-resistant mechanisms" migrate throughout the rest of the Vista. It's gonna be awesome!

Dumb dumb dumb

[Anonymous Coward]

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

That is one of the dumbest things I have heard in a while. Let's see:

• It's a poor solution to begin with.
• It's incorrect. Did no one even bother to calculate the drop-off? Was there not one single engineer amongst them who ever said "Hey, you know, Gigabit is pretty popular these days."?
• It should be unnecessary. Why does standard media playback and networking require so much power that there is not enough time to schedule both of them correctly?
• It is wrong. Why is media playback is more important than network performance? If the network is heavily loaded, well gee, maybe there's a reason for that?

What an over-engineered non-solution to what should have been a non-problem in the first place. Microsoft is supposed to employ some of the smartest engineers in the world: can none of them optimise their code?

Not dumb

[Colin Smith]

Laughable...

Do they have 15 year olds designing their operating system?

 

Re:

[Opportunist]

Well, depending on what the machine is used for, it could actually be that playing back the MM content is more important than the network traffic (e.g. when you're dumping the torrents you leeched while watching a movie to ... erh... I mean... when you're watching important promotional videos while transfering your holiday movies).

But shouldn't I, the user, get to decide what's more important?

Re:

[rbochan]

...But shouldn't I, the user, get to decide what's more important?

Apparently not, if you use Microsoft products.

Re:Dumb dumb dumb

[Jose]

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.

And this seems like a strange conclusion to jump to...especially coming from Mark.

maybe I am just confused, but the NDIS driver handles sending and receiving of pkts, so is the pkt rate limited to 10,000 pps coming and going? (he mentions packets received by network adapter drivers, but I am still curious). if it is limited to 10,000 pps in either direction...then you the theoretical limit comes down by quite a bit.

Even at that, he is assuming full sized packets, which is a bit of stretch, there is a good chance that not all of them will be the full 1500 bytes, factor in broadcast traffic, and other crud which may be running...and you start seeing a noticable drop even on a 100mbit connection.

And, God forbid, 10Gb

[faloi]

It's incorrect. Did no one even bother to calculate the drop-off? Was there not one single engineer amongst them who ever said "Hey, you know, Gigabit is pretty popular these days."?

10Gb is starting to get out there too. Granted, it's not likely to be hitting end-user boxes for a while, but you'd think somebody at Microsoft might've stopped to do the math on that one.

Re:Dumb dumb dumb

[rbochan]

...skipping music is in any way acceptable compared to slight network performance penalties?...

Actually, this is 2007, with stupidly fast processing, memory levels, and network throughput. There's no reason whatsoever that either effect should be showing up when both activities are happening at the same time.
And it's not "slight network performance penalties". It's ridiculously harsh network performance penalties.

Re:Dumb dumb dumb

[Panaflex]

The important point, which the vast majority of posters here are missing, is that the problem should never even exist in the first place.

They know why.. it's the kernel-mode encryption required to send audio to the card. There's two engineering failures here:
1. thread locking is accomplished by raising the interrupt level to DPC (KeAcquireSpinLock)
2. Requiring several steps/levels of encryption to interract with the audio card.

The real issue is a combination of utilizing DPC interrupts for basic thread locking (which thrashes the scheduler during long halts) and encryption (which requires long halts).

The real fallacy, IMHO, is thatMS thinks that because it's in kernel mode that it's immune or safer from attacks - so they created lots of "security features" in the kernel. In many ways this makes attacks much simpler - as you can simply move your code into kernel mode which has fewer limits than user mode!

Re:

[PJ1216]

Wouldn't it be better to just let the music skip, as that's most likely the more unimportant and can easily be shut off? Heck, if not listening to music makes the difference between going home on 5 and working for two hours longer I'd happily choose silence.

That's also an assumption as well. Personally, I rarely have any heavy network usage, though it will spike. If I used Vista, I would rather the network be throttled than the music skip. I'm assuming a majority of computer users are not hardcore users and therefore they were the ones catered too. However, you're second point about not knowing its the media player causing the throttling is a valid point. It would have been better to make this throttling mechanism an option as opposed to forcing it on pe

Wow...

[Kr3m3Puff]

I find this totally interesting. It goes to the heart of what is wrong with Microsoft these days... All seperate groups of folks, not talking to each other, to try and do "what is best" for the user, and then totally stomping on each other. Instead of really looking at thread management and optimising the kernel, they cludge together something to make multi media work by simplying saying "in certain situations, I can't guarentee the thread because of a crappy kernel, so I am going to tell everyone else to slow down".

It is these sorts of things and things like the teams and teams debating the "Shutdown Menu" in Vista that are really showing Microsoft needs to really change if they are going to survive. It amazes me how a bunch of open source developers with all their own agendas do a better job then a bunch of folks all paid by the same company. Of course then there is Apple of an example of a group that shows you can pull it off and still all look like the same organisation.

Funny you should mention that menu

[Toreo asesino]

....it's got to be the biggest let-down of all time.

The shut-down menu, that is... :D

"Bill, Bill! I'm sorry! I didn't mean it! Come back!"

*repents*

Re:

[TeknoHog]

It's interesting to note how Unix philosophy ties in with this difference between Microsoft and open source. With unix, there's no single defined 'user experience' to be optimized, because the components can and will be combined in various ways. Then it's the individual components and the interfaces between them, that will be tweaked and optimized.

Re:

[DoofusOfDeath]

All seperate groups of folks, not talking to each other, to try and do "what is best" for the user, and then totally stomping on each other.

I totally agree. For example, look at the cross-purposes of those working on DRM vs. those working on every other part of the OS.

Re:

[Floritard]

There was something about Bill Gates and Microsoft at the end of one of Jared Diamond's books (Gun Germs & Steel I think) and how they implemented one of his theories about geographical fragmentation and state power. Something about how China stagnated while Europe flourished, and there being an optimum group size when tackling problems, a technique which MS chose to implement in its software development. Looks like they've overshot that balance. Kinda like the US Intelligence community in recent times.

no surprise

[psbrogna]

What I took away from that was "Windows has to go slow to work." Shocker.

Russinovich

[gEvil (beta)]

While I'm pretty sure his explanation is correct, does anyone else find themselves reading Mark Russinovich's explanations with a healthy-sized grain of salt ever since he went on MS's payroll?

Re:

[Christopher_G_Lewis]

No.

Have you ever seen a talk by Mark?

While he might be on the Microsoft payroll, he is definitely NOT one to sell-out.

Re:

[LordSnooty]

I think it's right to at least pose the question, though. Before, Mark was a Windows expert working independently, and was able to voice opinions as he saw fit. Now he's a Windows expert being paid by the company that makes Windows - the very success of Windows Vista will dictate how long his job lasts. He now has an interest in assuring customers and investors that things aren't as bad as they might be. Now, it's all about the bottom line. Of course, he's built up a lot of trust amongst the community, trus

Vista is a turd

[Anita Coney]

Why should Vista have any problems playing audio and videos?! I have an ancient 550Mhz PIII with only 256 megs of ram running W2K and it plays MP3s and video (divx and xvid) much more smoothly than my wife's Vista system (2600+ AMD, GeForce 6800XT 512MB 256-bit GDDR2, 1.5 gigs Ram). My wife's system used to run XP Pro and it rocked for everything, including games. Now even old games such as Sonic Heroes will barely run on Vista.

I gave it an honest chance, but Vista is a turd. If it can't play decades old MP3 technology MS should really give it up.

Completely Unfair Scheduler

[Cyberax]

Microsoft should hire Con Kolivas to fix their Completely Unfair Scheduler :)

New definition of a Kludge here, I think

[Ancient_Hacker]

Okay, I probably would have applied this patch to my software, at 2Am, with a mental note to remove it in the morning and do the right thing, smarten up the task scheduler, perhaps with an app callback saying "I'm falling behind, could you boost me up a bit?".

As goes without saying, arbitrarily throttling one particular task, at some arbitrary level, is the wrong thing.

Perhaps this could go in Wikipedia under "Kludge"?

never trust anyone over 40...

[Speare]

Have you heard anyone under the age of 40 who uses the word 'glitch' to describe undesirable behavior in machinery? Everyone over 40 remembers the modem days so bandwidth issues aren't a big surprise, either. Just another sign that Microsoft is truly the proverbial dinosaur.

(says the guy who just turned forty)

Re:

[DannyO152]

Oh fuss and bother. Another apparent glitch in my plan to pass as young. It's back to the drawing board to get out the slide rule and adding machine.

Hang on a minute...

[Spad]

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

"Today's systems"? Vista's only been out for a year, just how fucking short-sighted are they?

How short-sighted?

[wild_berry]

I'd had two CPU's and Gigabit Ethernet for three years by the time that Vista was on sale to the public. That's not simply "short-sighted with respect to today's systems", that's a total let down to businesses who have high-performance workstations.

Engineering for profit vs. for improvement

[IgD]

I think this is a great example of why the open source development model will lead to better outcomes. Microsoft apparently tweaked Windows for profit instead of to improve efficiency or user experience. This design flaw would have been identified immediately in the open source world and would have been rightly discarded.

Suggestion to the Engineers

[scruffy]

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.

In the interest of getting a fix out quickly, I have carefully considered the problem and suggest changing 10 to 11 or maybe 12.

Ya hurt yer what?

[jpellino]

Oh, I see now. Lovely. This is like turning on your headlights and dropping down to 30 mph.

OK - well that was how those old 6v Beetles worked...

Comment removed

[account_deleted]

Comment removed based on user account deletion

Vista media playback worse than 486

[farbles]

I used to play mp3s with no stuttering on a 486-100 using DosAmp. I cannot play mp3s or video without stuttering on Vista with a dual core 2.4 GHz CPU, 4 GB RAM, 500 GB SATA drive. I can put my XP SP2 drive on the same computer and play media flawlessly while (gasp) multitasking. Like the man says, Vista is a turd.

When my old XP HD crashed I was forced to use Vista exclusively for several weeks. It was like my computer was sick and in the hospital. No TV from my ATI x800 All-in-Wonder (though I did get the FM radio working after a week or two), sucky video game frame rates, unstable network card and sound card drivers and crap multimedia playback. P2P kept crashing the network stack.

Some people say that this isn't Microsoft's fault, it's those third party driver writers to blame. I say fuck that, these folks can write good drivers for the exact same computer in several other operating systems. It's Vista's fault.

MS fanboys will all come out and say their systems all work perfectly. Horseshit. I've now had hands on with more than two dozen Vista machines ranging from laptops to upgrades and in every single case, that's 100% MS fanboys, not 99%, not 80%, all of them had stuttering media playback.

There is no excuse for this sort of crap. My goodness it was such a relief to get an XP install back. My computer was perkier and all of a sudden everything worked again.

If Microsoft does not fix this with the mother of all service pack releases rewriting Vista from the core out then my next post-XP os will not be Windows. My best guess is Vista SP1 will be lipstick on a pig rather than the thorough cleaning out that poor excuse for a beta release really needs though.

R.I.P Mark Russinovich

[Coward Anonymous]

Back when sysinternals was still independent, Mark provided real information with real criticism when things were wrong. Apparently, things have changed.
His "analysis" here is not much more than a series of rationalizations and excuses:

"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." (emphasis mine)

The issue at hand is related to gigE NICs. Please find me a single gigE NIC that does not support TCP/IP checksum offload (even the lowly Realtek does).

His graph showing 40% CPU utilization during a file copy must be a joke or an admission of a dismally performing network stack. There are only 2 possible explanations for that number:
1. His file copy was saturating a 1gigE link - if you've saturated the link, 40% is not great but is decent. However, the test is not applicable to most people who've seen the issue. It also means there is another 60% of the CPU for processing audio - that should be plenty.
2. His file copy was nowhere near saturating the link and Vista's network stack is horribly inefficient. My experience with pervious incarnations of Windows (2K, 2K3 and XP) has shown that under ideal conditions a single file copy will max out (because of inefficiencies in CIFS but that's another story) at ~35MB/s (roughly 1/3 of a gigE link in one direction). If Vista performs at roughly the same rate, then 40% CPU for 35MB/s is terrible. No wonder there is a degradation problem that required network throttling.

Looking down further to the NDIS packet graph, it appears that it is indeed explanation 2 that is correct. Peak throughput through the system was 24.6MB/s (17215*1500). If this test was similar to the CPU test for the previous screenshot, we are seeing 40% for 24.6MB/s. It appears the system will saturate its CPU at 50MB/s half-duplex?!? That's horrible. Or Mark is showing different numbers from different tests. I'm not sure which I want to believe.

Something appears to be very wrong with the network stack in these experiments. I don't have Vista. Can anyone test this?

Disabling MMCSS fixes the issue

[microbee]

http://courtneymalone.com/2007/08/28/a-note-on-vis ta-network-speed/ [courtneymalone.com]

Re:

[MBraynard]

While that might reduce bandwidth for your intended puposes, it would not limit the total reported network bandwidth.

But don't let logic or common sense get in your way.

Re:Well that's just not true

[PJ1216]

I haven't been really on the lookout for it, but I haven't seen any posts explaining that as the cause. I'd expect if that really were the cause, there'd be a much bigger outrage from people and it would have blown up and I'd see articles on it whether I wanted to or not. I don't really see any useful DRM techniques for unprotected MP3s anyway. There'd really be nothing that MS could do with that sort of information.

However, this actually does make sense. In all honesty, they probably would have worked on a better answer than cutting back on networking, but with the time crunch on releasing it, they probably cut corners here and there (and by probably, i mean definitely and by here and there, i mean everywhere). They probably viewed this as an acceptable cut for the time being because for a majority of users, they use very little of their networking bandwidth. If its just a PC connected to the internet, they'd most likely never notice. The only time this would be an issue is for heavy network usage, which would normally only occur on work-related machines because let's face it, aside from geeks and techies, not many people have systems set up that max out their network bandwidth, so, if they were work-related machines, well, they probably wouldn't be playing that much music to begin with.

I'm not a MS shill, though I don't assume everything they do has evil intentions. We have to admit that they are great code writers, just not the best. Just because they do shady things here and there (mostly in business practices however) doesn't mean everything they do is evil. This was a problem they ran into and they made a workaround that would only affect a relatively small amount of their users. They were probably hoping no one would notice it at all until they either A) had a fix or B) just let it go because maybe no one would notice it.

Remember, this wouldn't really slow down your internet unless you have an *extremely* high bandwidth and even then, bottlenecks on the information before reaching you would probably still mask the problem. This is only an issue on system that have heavy network usage on some sort of intranet or other type of local area network, because these would account for the majority of networks that could even use a decent amount of your possible networking bandwidth.

Re:

[gazbo]

Hello, I enjoyed your post and therefore felt you deserved a reply. Feel free to add that to your CV.

http://it.slashdot.org/comments.pl?sid=280101&cid= 20366549 [slashdot.org]
http://it.slashdot.org/article.pl?sid=07/08/26/162 8200 [slashdot.org]
http://it.slashdot.org/comments.pl?sid=280101&cid= 20377327 [slashdot.org]

If they are meant to be humourous then my sense of humour must be completely broken. I'm sure there are more comments of equal paranoia to be found in previous installments of this saga.

Re:

[Anonymous Coward]

Well, I use and love some MS software like the next guy.

You mean, not at all?

Re:

[dBLiSS]

"I think the real fear is the DRM layers that are built into Vista are at the root of this problem"

If you RTFA it explains that it isn't DRM causing the problem.

Re:

[Macthorpe]

Wow, your incredibly well-thought argument has swayed me! Time to burn my Vista DVD, reformat my computer and install Ubuntu! ... No, wait, that was a lie. Sorry about that.

Re:

[hxnwix]

There's good reasons to attack Slashdot. Its business practices, internal workings, and products have a history of abuse, contradiction, and stupidity behind them. I wave no flag for Slashdot and Subscriptions are a pain in the ass that's priced itself out of the market but the look and feel of Digg is heading for the basement. I'd be careful of this because when Slashdot sort themselves out the only thing you'll be left with is hate. As that has nothing to grip on people will see it for what it is and walk

Re:

[WhiteWolf666]

It's not a flawed implementation, its defective by design (and I don't mean DRM'd, I mean literally).

On Linux, with the CFS and/or SD schedulers, if your nice levels are set correctly, sound (MP3) will play just fine with your processor(s) pegged at 100. Heck, forget about sound; you can run multiple Quake 4s with high-speed LAN transfers in the background, and everything works just fine (network transfers slowdown slightly, Quake 4's FPS scales down linearly with the number of sessions running, but there a