Slashdot Mirror
MS Responds To Vista's Network / Audio Problems
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."
No, the network speed drops to ~10-15% of non-audio playing speed. Very significant issue.
Kindness is the language which the deaf can hear and the blind can see. - Mark Twain
No, it's not. Read the old FA:
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.
"performance hit is obviously expected behaviour" and from the article, "Windows Vista will trade off network performance in order to improve multimedia playback"
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.
There are 10 kinds of people in the world... those who understand binary and those who don't.
Good thinking.
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.
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
http://blogs.zdnet.com/hardware/?p=702
Just follow any CFS thread (or any Linux scheduler threads in the archive), the new shiny Linux scheduler.
So I ran my own test.
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 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 (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.
mirrorshades radio -- darkwave, industrial, futurepop, ebm.
My suspicion is:
s /cableguy/cg0905.mspx
1 3073
s /2007/02/VistaKernel/
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.
When I used vista I didn't see a slow down in network speeds, but at the time I was reorganising media on my hard disk, I started at 10gigabyte file transfer, vista stopped, completely stopped literrally, its like i was running vista on a 66mhz processor, it was not funny, 1hour later when I had reinstalled XP it was much better.
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.
Coming soon - pyrogyra
Ran just fine on my 5yr old 'Dell' (only the case and mobo) when they were out. I never noticed any problems. I used that box as my no.2 desktop and my home's file server/intercom-interfacing stereo. After I got a new box to replace it (this one -made- for Vista) I noticed problems. THREE TIMES it not only ran up all 3 of my secondary fans while pumping music thru the system, it actually killed its own power. Under a lower stress level. (The new box only runs as desktop/whole-house jukebox, the old one still works as a server, just running Gentoo/samba).
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.
Burn the Land and Boil the Seas, you can't take the sky from me...