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."
New OS has old problems (Score:5, Insightful)
Pushing Vista too early is only going to hinder long-term deployment.
Re:Typical (Score:5, Insightful)
ITS (Score:4, Insightful)
Because only MS ever uses that excuse.. (Score:3, Insightful)
REally? (Score:5, Insightful)
Interesting, VERY interesting. This either means that Microsoft Programmers are incredibly incompetent or they are hiding something. I can take a really old Linux kernel (or windows 98 install) on a Pentium 233 mmx processor and see less than 0.05% drop in networking performance while playing an mp3. In fact I dont see that drop playing 2 mp3's at the same time while transferring large amounts of data over 100 base T. I do this daily on my whole house mp3 jukebox that is linux based, it has 2 seperate sound cards that plays 2 different mp3 files while I upload another 60-80 mp3 files I corrected the data tags on. I do not see the performance hit of 10% on hardware that is at least 20 to 30 times slower than the typical Vista machine.
What are they hiding?
Re:New OS has old problems (Score:3, Insightful)
Only among the geek crowd, who don't want Vista anyway. The "general public" doesn't care. The computers they buy new come with Vista, and that's what they will use.
Re:Back in 1994... (Score:2, Insightful)
Re:REally? (Score:5, Insightful)
That it's caused by the DRM subsystem.
This parent is a troll. (Score:2, Insightful)
I can encode a 320mbit VBR MP3 at about 20X playback speed. That's encoding, the slow phase. MP3 playback is NOT a real-time task. It hasn't been for ages. The system decodes the next several seconds of audio, stores it in an audio buffer, and tells the system to play it. If you hit pause, it then stops the active playback immediately, but there's still more audio data available. This way, there's no reason for the audio to skip, and the audio program doesn't need to be top priority or realtime.
Ironically the only audio program I've had problems with skipping under Windows is iTunes, and only when running some other task at 100%.
In any case, audio programs don't need realtime priority and there's no reason why playing audio should cause network performance to degrade in a properly designed system. I can see a poorly designed system manage to completely screw things up with interrupt handling, though.
--
Sigs are lame.
Re:Back in 1994... (Score:5, Insightful)
Re:REally? (Score:5, Insightful)
Me, after using Vista: "Any sufficiently advanced incompetence is indistinguishable from malice."
What a Load of... (Score:5, Insightful)
What a load of utter Crap! If such a trade-ff was ever necessary, then we would have been seeing it in Win XP as well, and obviously we don't.
Vista networking is broken! Try copying over files from your XP machine on a mapped drive if you don't believe me. And audio/video functions in Vista are equally broken. And I bet its for the same reason: Kiss-Up To Hollywood DRM.
Microsoft has caved to the almighty Hollywood dollar, and with Vista you're pwned more than ever!
Re:Back in 1994... (Score:3, Insightful)
Windows can't compete with a 1 Mhz computer made in 1992 with 38,911 BASIC BYTES FREE
READY.
[]
Re:What Microsoft said makes sense-SO WHY??? (Score:5, Insightful)
So why is it that Win XP never had this problem on slower hardware? Nor Win2K, ME, 98SE, 98, 95...
Since when? (Score:2, Insightful)
That's funny, the last time I remember any OS taking any significant hit to play an MP3 I was running on a 166 mhz Pentium II.
I object to the "defective by design" tag (Score:3, Insightful)
But, the practice of tuning the system such that audio playback is constant and stutter-free by sidelining other components is VERY common in system design. Sometimes it is built directly into hardware - you dedicate fewer, faster lines to audio and slower and buffered to the networking. When audio skips you are FUCKED. When network traffic stalls, TCP - and in fact UDP and most other protocols layered in some fashion over Ethernet or ATM - is actually designed to handle it by retransmission.
A 90% drop is ridiculously high, but it IS keeping your audio system fed with data reliably. Perhaps it just needs some extreme fine-tuning. It's certainly the case that a PCI Express audio card because of the high overhead would not be fed data fast enough (PCI Express is high bandwidth but not low-latency) if a PCI Express networking device was pushing data around. We've had this stuff before on Creative cards, where the PCI latency and bus mastering has been tweaked such that the PCI chipset holds the bus for "far too long" causing problems with the rest of the system. But in the end there are not that many TRULY elegant ways of doing it.
Every system bus is contended at some point, and if the contention shows VISIBLE or AUDIBLE artifacts, then the user will be pissed off. That means, display corruption, legobricking of MPEG data, audio skipping or looping, you cannot have this on a high quality multimedia system, however, 100mbit/s transfer rate really is just fine when it comes down to it. Not perfect considering you paid for something 10x faster, but still, not all that bad for multimedia performance.
Re:Nice error, the drop is 10% (Score:5, Insightful)
Re:Nice error, the drop is 10% (Score:5, Insightful)
Also, I'm not sure if I'm interpreting those screenshots correctly (I don't use Windows so I'm not too familiar with its monitoring tools) but if 100% in that graph corresponds to 1 Gb/s transfer speed, then the speed drops from 32 megabyte to a still very respectable 16 megabyte per second. People seem to suggest that networking grinds to a halt when playing audio, but although this drop is very significant, it by no means renders your network connection unusably slow. In fact, it's still pretty damn fast.
I'm sorry, but you aren't making any sense whatsoever. If I buy a racecar that I use on Sundays at the track, and turning on the radio decreases it's top speed from 200mph down to 100mph, is that OK because that is "still pretty damn fast"? If I book a flight that should take 10 hours but whenever the stewardess serves food or beverages, it decreases the plane speed so that the flight takes 20 hours instead, travelling at only 300mph, is that ok because it is "still pretty damn fast"?
If I am running an internal network, where data transfer speeds are critical to the work I am doing and playing MP3s decreases that speed by 50% (assuming it is the 50% you are claiming the article says and not 85-90%) is that ok because it is "still pretty damn fast"?
I have been playing MP3s on systems as old as 486's (which used a whopping 10% CPU - with NO network degradation) - there is NO load on today's system when playing an MP3 - except through poor design - or worse yet, intent - so there is no reason why network speeds should drop AT ALL - much less 50%, 85%, 90% or whatever. As others have noted in other threads on /. and elsewhere, such bottlenecks of late all seem to be due to DRM related issues in Vista... I wouldnt doubt a similar issue is the cause here - and the reason why Microsoft is (properly for once) stating that some of this issue is actually due to design.
The fact is, on today's multi GHz, multi-core systems, a 10% drop in network performance would be outrageous for something as simple as playing an MP3 or other audio stream... 50% is ludicrous... and I can't even think of a word to describe what an 85-90% drop would constitute.
Yes, when it comes to the Internet world, even a 90% drop in network performance on a gigabit network card doesnt really mean anything for most people - such an attitude misses many still valid points and issues, such as there are numerous users who don't have that Internet bottleneck to make such slowed down connection speeds a moot point (college students for one, businesses with dedicated high speed lines for another) - there are also users of every sort who have home networks set up who WILL see the degradation in speed since they are not limited by their Internet Connection Speed (businesses, home users, gamers doing LAN parties, you name it) - and most importantly, there is no VALID technical reason why playing any audio stream should degrade network performance on today's hardware.
That last point brings up the final issue. It really does not matter if MS claims there are valid design reasons or valid technical reasons for the drop in network performance (whether 10%, 50%, 85%, 90%, whatever) - because as far as the features end users want, there is NOT - and the only "features" I can think of that would cause this are DRM related technologies so liberally sprinkled all over Vista. Any other reason is quite simply poor coding and design... and as MS didnt write, and has barely changed any of the networking stuff in Windows in quite some time, I think it is more of an issue of "features" that no one wants, may be illegal (under the fair use doctrine) and should never have been dumped into Vista to begin with.
People seem to suggest that networking grinds to a halt when playing audio, but although this drop is very significant, it by no means renders your network connection unusably slow. In fact, it's still prett
Re:REally? (Score:5, Insightful)
"Please note that some of what we are seeing is expected behavior, and some of it is not. In certain circumstances Windows Vista will trade off network performance in order to improve multimedia playback. This is by design."
In other words they see a bug especially on gigabit connections.
Yes. The bug is that the audio system has any correlation whatsoever, however minor and imperceptible, with the frickin' network stack, and even moreso that this is expected.
It's not expected behavior. I don't care how much they jump up and down and cry that most people won't notice, this is bullshit.
Me: Every time I get in my car, a hammer pops out and hits me in the jaw, painfully.
GM: That's a bug. It shouldn't hurt so much.
Rational observer: WTF?
There's no lost context or missing information. The facts are that MS is OK with the idea that an MP3 reduces your network throughput. There's really nothing else to say in the matter. That one admitted fact alone is enough to declare it defective by design.
Maybe RTFA before writing the summary? (Score:5, Insightful)
"In most cases the user does not notice the impact of this as the decrease in network performance is slight. Of course some users, especially ones on Gigabit based networks, are seeing a much greater decrease than is expected and that is clearly a problem that we need to address."
If the alternative to Microsoft FUD is Anti-Microsoft FUD, I'm not sure we're much better off.
Re:New OS has old problems (Score:4, Insightful)
Yeah, but the general public doesn't pay MS's rent. Corporate licensing and OEM deals are where the money comes from, and those are both in serious trouble right now in that nobody with more than a few hundred desktops considers Vista even remotely acceptable. Granted, by the time Vista SP2 is out in 2010, they may have fixed a lot of this stuff.
Re:Nice error, the drop is 10% (Score:5, Insightful)
This laptop I am working on now ($5k USD class laptop) came delivered with Vista. Let me give a few exmaples of what I had to deal with to make the issues clear.
A quick example of this would be how I needed to copy high-bitrate media-files (HDTV, 20mbps) locally before I could play them in Vista. On GigE freakin' LAN.
Copying 4GB+ virtual machines, again on GigE LAN could take better parts of a day. Checking the performance monitor, I could see that I had 10mbps actual data-transfer. I'm not kidding here. IO was beyond piss poor.
This is something I've never had issues with in any other OS. I'm not calling it unacceptable. I'm saying it's fucking crap.
In short: There were a few improvements I honestly liked in Vista (apart from the eyecandy), and those were really nice improvements, but honestly...
All the issues I had in Vista which I assumed any modern OS has tackled years ago, with regards to performance, usability and all that were simply too much for me to handle. I'm back at XP SP2 and I feel like that's the biggest hardware upgrade I have ever done.
For those interested in the technical aspects of this, I would wrote a simple, hypothetical article on the aspects of OS complexity and performance [kjonigsen.net] from a developers point of view on the tight Kernel-DRM coupling some time back.
That, however, is nothing compared to what this guy did [auckland.ac.nz].
Reading these it's pretty obvious why Vista has exactly the issues it has, and why MS sucking up to the entertainment industry probably is the worst business move they have ever made.
Re:missing tag? (Score:5, Insightful)
Re:This parent is a troll. (Score:3, Insightful)
I'm not a Microsoft apologist - I haven't run an MS operating system for several years, and I've never used Vista - but this bug is quite understandable. I posted in the last story suggesting it was probably exactly what Microsoft describe. Now that I know that it only affects receiving, I will suggest that it's an overoptimisation in the interrupt handling code. I would guess that they switch from interrupt-driven to polling mode on high-priority latency-sensitive drivers when they are busy. The sound device would be one of these. If they don't switch back fast (or often) enough, then the leading edge of some interrupts will be lost, and if they delay even longer then packets will be lost because the network card's receive buffer will become full. Sending would not be affected.
The fix for this should be simply altering a constant somewhere to make the sound devices stay in polling mode for less long, or after more interrupts in a short period. Even with QA time, it shouldn't have taken more than a week to get the patch out.
Re:REally? (Score:3, Insightful)
It's a shame you posted as AC, because you've almost certainly got it exactly right. Every operating I've used (with the possible exception of BeOS, and QNX) has problems playing audio under high load. It's usually not a big issue, because most machines aren't loaded that much these days, and most people don't notice the odd stutter in their sound.
You can avoid this by making the interrupt handler in the audio driver run at a really high priority. If you don't even wait for interrupts, you just poll to see if the device is waiting for data, you will never skip (as long as the decoder gets enough CPU time). The down side to this is that you are likely to lose (or delay handling) interrupts raised by other devices. Either MS is polling the audio interrupt, or they have things configured so that the audio device's interrupt is not masked while handling interrupts for the network device. In either of these cases, you get missed, or delayed, interrupts from the network device. This means that the receive buffer fills up and ethernet frames get dropped.
Or, it could be the evil DRM spying on you. Don't let logic get in the way of a good conspiracy theory.
Re:This parent is a troll. (Score:3, Insightful)
Bad form replying to myself, but I just realised that it's more likely that they simply don't mask the audio controller's interrupt when entering the network interrupt handler. This would let the audio driver preempt the network driver, which would cause delays in handling network interrupts. The fix for this is slightly harder. Ideally, you would just use a larger buffer for the sound subsystem, but the hardware might not support this. Another option would be to mask the audio hardware's interrupts, but poll he device once every few received frames. This is probably what they will have to do, but it's a non-trivial fix.
The ideal solution would be to have the interrupts for the network controller and audio device routed to different CPUs, but this would could make things worse if both subsystems have some kind of shared lock. Ideally, you would have almost no code in the interrupt-servicing part of each driver, and use a lockless ring buffer or similar structure for this to communicate with the next layer up, and no other resources, so they could be run without contention. I don't know how feasible this design is in the Vista kernel though.
Re:REally? (Score:3, Insightful)
Truth in report (Score:3, Insightful)
However, reading the actual Microsoft response gives a completely different take on things. Microsoft realizes that this behavior, while having good intentions, is causing issues. Far from being some unfounded bug, there is a real purpose behind why the slowdown is occurring, namely a focus of multimedia scheduling performance trumping all. They are going to address these issues, not ignore them, but you wouldn't know it from the article teaser.
I have Vista on one of my PC's. I find it slower and more or less undesirable compared to Windows XP64 on my other boxen. It's there largely for me to get familiar with, as we're all undoubtedly going to be dealing with it soon and for a long time to come. You may be able to avoid Windows in your personal computing, but you'd have to live in a tiny bubble indeed to go through a work day without interacting with a co-worker, client, or customer who isn't on a Microsoft product of some sort.
Re:I object to the "defective by design" tag (Score:3, Insightful)
This came up last week, so we're waiting for a fix from Microsoft.
Is this how stupid /, readers are now? (Score:3, Insightful)
I can drop my file transfer ability by using my USB TV-Tuner that installs itself as above average priority.
In tryin to give better audio quality it's effecting other areas of the system.
Wow! Yet ever other post is a stupid conspiracy piece of crap.
Get a freaking clue before you post. And if you're still wondering why it's a Vista issue and not a XP issue at this point call you grandma for tech support instead of the other way around because you're not qualified to think apparently.
Re:Nice error, the drop is 10% (Score:3, Insightful)
Hmmm... lets say I do graphics all day, and archive the raw data to our file server (or perhaps even store the data there)... instead of wasting the power of my iPod's battery (assuming I have one) or needing a dock with speakers... why can't I just play MP3s from my computer while I am working? And when I do, why should I wait 3 minutes (or 5 minutes) for a file transfer that should take 1.5 minutes?
Data transfer speeds aren't always critical to wanting to reach maximum transfer rates (as in my example). Nonetheless, you are still missing the point. There is no reason for the network degradation (under these circumstances) - regardless of what MS claims. Period. End of story.
Re:M$ expected behaviour! (Score:4, Insightful)
DUH!!!!!!!!! It's NOT off topic. The point it was relevant to you apparently missed. Let me spell it out to the moderator who obviously has no brain or just likes modding anything that mentions OS/2 as off-topic.
- Z! (which I use exclusively on OS/2) works on Windows
- Someone asked is this an aspect of playing MP3s via Windows Media Player which on Vista seems to talk to MS no matter what you click - or if this can be repeated using non MS audio playing apps.
- This was in response to, and for providing more information about; testing this with a non-Windows Vista/Media Player app to evaluate that question.
- I don't (and won't) run Vista, so I cant test this... but the idiot moderator who flagged my post as off-topic maybe could...
Ah well... at least only some mods are idiots.
Re:Typical (Score:3, Insightful)
"No need to read 1984 anymore, we're living it."
or
"They don't let kids read 1984 anymore, might give 'em some ideas"
Re:I object to the "defective by design" tag (Score:3, Insightful)
Having to drop network performance to ensure such a low bandwidth stream gets to the sound card on a machine with a big fat wide PCI Express bus and a multicore, multi-GHz processor is just laughable.