MS Responds To Vista's Network / Audio Problems 528
quirdan writes "With the discovery last week of the connection between Vista's poor networking performance and audio activities, word quickly spread around the Net. No doubt this got Microsoft's attention, and they have responded to the issue. Microsoft states that 'some of what we are seeing is expected behavior, and some of it is not'; and that they are working on technical documentation, as well as applying a slight sugar coating to the symptoms. Apparently they believe an almost 90% drop in networking performance is 'slight,' only affects reception of data, and that this performance trade-off is necessary to simply play an MP3."
Re:Nice error, the drop is 10% (Score:5, Informative)
Re:missing tag? (Score:5, Informative)
However, some users over at the 2CPU forums have discovered an unexplained connection with audio playback resulting in a cap at approximately 5%-10% of total network throughput.
M$ expected behaviour! (Score:5, Informative)
That is utter BS. On a decade old machine, its possible to run a network and audio playback at real time speeds. Given the power of even low end PCs these days (minimum spec Vista machines) its crazy they cannot handle both together.
Re:REally? (Score:5, Informative)
If it accessing the onboard TPM this is quite likely. I cann bet that they smacked a few global locks around those accesses just in case to ensure that a silly race condition in the access will not allow someone to break through the precious DRM. PC TPMs are disgustingly slow so every access leads to a fairly long period when interrupts are not being serviced. As a result the system capability to process interrupts drastically decreases whenever the DRM subsystem has been activated. Add to that some priority to multimedia and the picture will be exactly as observed.
This is all hypothetical of course, but it more or less makes sense. I would not be surprised if that is the case.
Re:Nice error, the drop is 10% (Score:5, Informative)
Re:What Microsoft said makes sense (Score:4, Informative)
Re:M$ expected behaviour! (Score:5, Informative)
Even my G3 iMac with OSX 10.3.9, which it wasn't designed to run at all, could do that, using iTunes and running Firefox and Thunderbird and Skype (all memory- and CPU hogs) at the same time.
I didn't believe it (Score:5, Informative)
I transferred a 3.5 gigabyte file from my Ubuntu Fawn laptop to my Vista Ultimate workstation. Both are dual-core Intel processors; the Ubuntu laptop is a T5600 @ 1.83ghz, and the Vista workstation is an e6600 @ 2.4ghz. They are connected through a normal Belkin with a 100mbit ports.
(Amusingly, the file in question was a Vista Ultimate ISO.)
While the transfer took place I opened Vista's task manager and looked at the network utilization graph. Steady at 38% with almost no deviation. I let that go for a minute.
Then I played an mp3.
Immediately the utilization went to 27% and held steady. As soon as I stopped the mp3, it shot back up to 38%.
I did this all with WMP at first, thinking that'd be it. To double-check I ran my usual player, Winamp, with the exact same results.
Here is a screenshot [crashnet.org] of the network graph. Every single one of those dips you see was me playing an mp3. Disgusting!
Thinking that just maybe the problem was disk usage, I did two things. First, I forced a defrag on Vista while the transfer was underway. Network utilization was unaffected. Next, I tried streaming music from my own darkwave station [mirrorshades.org] (and then shamelessly plugged in on slashdot). Network obligingly dropped to 27% even though streaming shouldn't use the disk.
I'm convinced. This is a seriously messed up issue and I hope to whatever diety that Microsoft rectifies it quickly.
For the record, Vista has managed to annoy me a lot less than any previous incarnation of Windows, at least in userland, once I turned off the UAC crap. And I like some of the little extras that it does. But from a technical and administrative standpoint, this is highly obnoxious, and I'm pretty appalled.
I do have to say, though, that until I went out of my way to test this, I had never noticed the difference, and I'm a technical guy. The average user would probably never notice the difference under any circumstances. That does not excuse this type of idiocy, but it may explain why MS chose to do this. Just a guess.
Re:M$ expected behaviour! (Score:3, Informative)
Sure, as long as you use a kernel optimized for so little memory by today's standards, probably might want to stick to 2.4 or earlier. Forget about a GUI tho. But there's no reason it wouldn't feel as snappy at the command prompt as it would under DOS. There might be an ultra-lightweight GUI out there somewhere, but bear in mind you're talking about a machine that's barely adequate for Windows 3.1.
4 way combination bug. (Score:3, Informative)
A) Networking stack in Vista is rewritten, for example, IPv6 is native, IPv4 is optional.
http://www.microsoft.com/technet/community/column
B) Audio stack is re-written, allowing for the new mixer, where each app has its own volume control (and some DRM, but that's not relevent to this issue)
http://www.avsforum.com/avs-vb/showthread.php?t=7
C) the Thread scheduler is changed in Vista
http://www.microsoft.com/technet/technetmag/issue
D) Appears to only affect Gigabit and above networking.
item C is possibly the key to this bug, I'm sure the Networking people did lots of perfomance testing, and so did the Multimedia people, as well as the Kernel folks... But, perhaps the full ramifications of the Thread Scheduler could not have been tested in every other combination.
The basic problem is that Multimedia playback changes the thread scheduler, which affects EVERYTHING. it could have been "Inkjet Printing while playing audio fails", "cannot hot-swap IDE drives while playing audio", "an open audio application blocks hibernate if brand XYZ laptops"... by chance, gigabit networking performace was affected, not because of any direct link.
Whats needed is for all performance or reliability minded software to be tested both normally, and while playing music in the background (or just with a program that turns on MMCSS, and then does nothing else). Just like when running under a debugger, multi-core machine, virtual machine, etc. different timing, thread deadlock, and race conditions may be found.
Re:M$ expected behaviour! (Score:3, Informative)
Sure, as long as you use a kernel optimized for so little memory by today's standards, probably might want to stick to 2.4 or earlier. Forget about a GUI tho. But there's no reason it wouldn't feel as snappy at the command prompt as it would under DOS. There might be an ultra-lightweight GUI out there somewhere, but bear in mind you're talking about a machine that's barely adequate for Windows 3.1.
I'd think Blackbox, Fluxbox, Window Maker or even Enlightenment would work.
If not, there's always wmii, ratpoison and the like.
Not nice, but probably doable. Unlike a 386 with 4 MB of RAM, onto which I once had to install Win95. Floppy disk install.
The damned thing used to boot for so long that my mother, who used the machine for work, would come in in the morning, turn it on and go grab some coffee. By the time she got back, the computer would be just about ready.
Now, admittedly, I wouldn't really bother experimenting with it, but I'm fairly certain this is still doable - and usable. I don't know the specs of one of my friend's old computers, but it was quite old (maybe a 486?) and we installed Damn Small Linux on it. GUI worked, though he didn't need it - it's just a lynx/nethack machine for the times he's too lazy to get up.
Re:Not Sure (Score:3, Informative)
I think this is actually a chipset bug - I see this on intel chipsets all the time now. My quadcore machine at work, my Toshiba M200 laptop; they both have IDE throughput issues, and drag the rest of the system to a halt.
No idea why. The latest drivers did help somewhat though - it doesn't stall nearly as much.
You might want to check your drivers on www.driveragent.com and see if there are newer chipset drivers out which fix the problem.
Of course, this is all anecdotal; it might still just be a problem on the Vista end.
The betas and rc, at least (Score:2, Informative)
I'm not sure quite what the problem was, either the chipset differences of the two machines or program differences from the beta/rc to the final, but somehow the switch really nuked my shared audio performance.