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."
Back in 1994, I bought a Power Macintosh 7100. One of the first PPC chips, about 66MHz, and running a positively archaic operating system.
I still have the machine, and drag it out from time to time. When this story broke, I pulled it out of storage to test it, and see how it compared. With a 10/100 ethernet card in, running the mac's System 7.5.3, it could successfully play an MP3 while transferring, and it made no difference whatsoever to send or receive speed over the network.
Take note Microsoft: 1994, 66MHz, System 7.5.3, more than 13 fricken years ago.
FTA:
"The connection between media playback and networking is not immediately obvious. But as you know, the drivers involved in both activities run at extremely high priority. As a result, the network driver can cause media playback to degrade. This shows up to the user as things like popping and crackling during audio playback. Users generally hate this, hence the trade off."
Granted, I don't want my audio stuttering, but the idea that the CPU can't keep up because of file transfer is insane. Maxing out an ethernet connection doesn't take much CPU. Even if we put the audio at a very high priority, I don't see how that would immediately degrade ethernet performance by 90%. I could accept no more than about 5% in a worse case scenario.
To be fair if I renice rhythmbox to 18 and transfer a file, things go to hell. Renicing to 10 clears it up. I saw no degradation of speed. Apparently Debian can do file transfers at full speed while playing an mp3 on a rather old PC*. Something isn't right here...
*Athlon XP 2400+, 1GB DDR
"In certain circumstances Windows Vista will trade off network performance in order to improve multimedia playback. This is by design."
I know we've been over this before. But for whom are we 'improv[ing] multimedia playback'? Is it really an issue in 2007, to perform a network transfer and play an MP3? Or is it Vista's "secure audio path" that is responsible for this? Remember, this is the same Vista that polls your hardware every few ms to check if you're playing 'premium content'.
I know not everything bad Microsoft does is done with forethought and malice (..) but really now. After reading the 'cost analysis of Vista content protection', can you not understand the apprehension? If some "multimedia" (albeit not 'premium content', but who's counting) is played, other parts of the system deliberately go into a 'limited' state? After reading that, does it sound like a bug to you?
"But as you know, the drivers involved in both activities run at extremely high priority. As a result, the network driver can cause media playback to degrade. This shows up to the user as things like popping and crackling during audio playback."
I call shenanigans.
Even if this is a legitimate "bug", i.e. the Vista testers were actually experiencing crackling audio while performing high bandwidth network transfers, who made the conscious decision to throttle the *network* instead of fixing the audio path and audio drivers? Windows XP had no problems performing high-bandwidth transfers and using the sound simultaneously. Besides normal operating system scheduling there was no 'throttling' of any device A when any device B activates. This is Vista content protection backfiring, plain and simple.
In other words they see a bug especially on gigabit connections.
Now back to yoru regularly scheduled bitching and "ZOMG my calculator gets better performance" fact-free discussion.
Actually, the TCP/IP stack is a rewrite. Assuming this bug is somewhere in the TCP/IP stack, this is a prime example of why you should *not* rewrite.