Considering that users didn't even notice this for many many months, why would you expect any difference from MS?

--

Less smarmy answer. How would you have tested to find this? Clearly the networking guys are not likely to test their stuff under any combination of software that uses the network running. After all, that would literally need a near infinite test bed. The music guys would most likely test networking (since they do streaming), but would probably only verify that streaming worked smoothly, not that actual network bandwidth stayed the same.

And, as i mentioned before, why would anyone necessarily even notice this. When you're copying files you're probably only copying something small (in which case you wouldn't notice), or something big (in which case you'd probably stop paying attention to it while you did other work). So you'd only notice this if you were copying something big, had an expectation of how long it would take, and then turned on some tunes to help pass the time, only to notice the enormous slowdown. In my life i've never gone through that sequence of steps, so i can see how others would have missed it as well.

Well... Vista has an entirely new networking stack, right, and a new driver model? So, this sounds to me like growing pains for new tech. XP SP2 is the end result of years of refinement, whereas a lot of Vista is new. So, performance is laggy and sucky across the board, surprise surprise.

See Darkseid for an idea of how it could affect way more users than you think...

How many users listen to music while downloading stuff on Bittorrent?

How many users listen to their own music while playing games?

Is that a negligible number of users? Not sure...

From what I can see the problem doesn't happen only when copying big files and maxing your NIC.

I could see how driver/interrupt/whatever issue would affect Bittorrent and network gaming speed, which don't max your connection but need way more TCP endpoints.

If you are connected to 50-100 bittorrent peers and there is some not huge but noticeable choking/verifications done for each of the connections, this could hamper global speed, lower your priority ranking and thus increasing global download time etc. (all depending on how you connect to the internet of course, direct giga, giga through router, wireless etc?)

I'm no expert, but this is could have way more implications than the not so common cases of huge transfers + audio. We don't know for sure.

This ain't on the same scale as the copy speed bug, but still serious IMO and might not be so easily fixable if the problem is in the audio now part of the kernel, DRM stuff (not likely though) or interrupt/network model.

Microsft has responded to this issue )http://blogs.zdnet.com/hardware/?p=724).

quote:

* “We have been looking into this problem and are working on a doc that will go into the technical details of what we have found.”

* “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.”

* “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.”

* “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.”

* “Two other things to note. First, we have not seen any cases where a users internet performance would be degraded, in our tests this issue only shows up with local network operations.”

* “Second, this trade-off scheme only kicks in on the receive side. Transmit is not affected.”

What a load of BULLSHIT. I haven't had an issue playing music while maxing out my NIC since I had a 233 with 64MB of EDO RAM and an ISA SoundBlaster 16.

What a load of BULLSHIT. I haven't had an issue playing music while maxing out my NIC since I had a 233 with 64MB of EDO RAM and an ISA SoundBlaster 16.

Actually I wouldn't call it BS, all of what they have said is true. But even with the tradeoffs that they talk about you shouldn't see a 90% drop in network speed so there is definitely something else going on.

* “Two other things to note. First, we have not seen any cases where a users internet performance would be degraded, in our tests this issue only shows up with local network operations.”

I think that's a big sticking point, that people will miss. While it's still a stupid, horrible bug, it ain't gonna affect your WoW ping times, I'm sorry. You're not going to be saturating your 10/100/1000 NIC with a DSL modem champ.

That being said, very interesting. I can't say I've noticed it on my Vista rigs, but I'll check it out.

Also, I don't understand how a connection to a router or DHCP serving DSL modem operates in a manner any different from any other local network connection. It's the same wires, same NIC. So how could this bug not apply to your internet connection in that case?

The best part is that this bug also seems to affect the Windows System Sounds - look what the Asterisk sound does to network transfer rates:

Also, I don't understand how a connection to a router or DHCP serving DSL modem operates in a manner any different from any other local network connection. It's the same wires, same NIC. So how could this bug not apply to your internet connection in that case?

It'll effect your NIC speed regardless, but the fact that no internet connection commercially available to people is going to saturate the NIC heavily enough for it to matter.

If you're getting stuff off a local server @ 1 gigabit, and downloading something on bit torrent, it may very well screw with your web speed. But surfing Ars and playing mp3s is not going to noticeably effect anything.

Also, I don't understand how a connection to a router or DHCP serving DSL modem operates in a manner any different from any other local network connection. It's the same wires, same NIC. So how could this bug not apply to your internet connection in that case?

It'll effect your NIC speed regardless, but the fact that no internet connection commercially available to people is going to saturate the NIC heavily enough for it to matter.

If you're getting stuff off a local server @ 1 gigabit, and downloading something on bit torrent, it may very well screw with your web speed. But surfing Ars and playing mp3s is not going to noticeably effect anything.

The audio in games does the same thing - what about multiplayer game latency?

Considering the raw transfer rates of the PCI bus, there is no excuse for this bug to exist. Audio is a vanishingly small part of bus traffic. And, both, audio and NICs have buffers and offloaded processing. I'm guessing M$ wishes not to reveal the presence of heavy duty DRM cycles on every audio stream in the machine.

People always say we can never have enough CPU, but modern machines are pretty darn fast. I don't believe this bug to be a thread priority problem, but intrusive DRM.

Originally posted by kcisobderf:I don't believe this bug to be a thread priority problem, but intrusive DRM.

Huh? How in the world did you get that idea? It makes no technical sense. There are no DRM mechanisms at work during regular audio playback. There is no such thing as "heavy duty DRM cycles", either... this isn't fucking laundry, dude.

Huh? How in the world did you get that idea? It makes no technical sense. There are no DRM mechanisms at work during regular audio playback. There is no such thing as "heavy duty DRM cycles", either... this isn't fucking laundry, dude.

It makes no technical sense, but based on what we do know about Vista's underworking networking stack (ie, in this case, nothing) combined with an innate hatred of MS, evidenced by the spelling of MS as M$, it makes perfect sense.

I play WoW while listening to Winamp (a variety of music) just about every day, and I cannot reproduce this issue. Under what conditions does it occur?

quote:

I wonder if this is why my connection futzes out if I'm playing MP3s while on IRC...?

As MS stated (God, I'm using MS as a reference on something, horrifying...) and others have mentioned (here, and on 2CPU forums), it looks like it only really kicks in/is noticed at high NIC loads.

Want to test it? Easy.

Have a gigabit network (10/100 might work to show it too, but gigabit is easier), have 2 PCs, one with Vista, on gigabit. Now, transfer some huge file from one to another, say, an ISO of Pamela Anderson singing the national anthem fully clothed.

Watch the network utilization tab.

Now, start a song. I suggest "Twinkle Twinkle Little Star". Be amazed as network utilization drops! In my case, I tap out at about ~75% of a gigabit link transferring between two high end PCs, one running 2003, one on Vista. Start up an MP3, and it drops to about 10%. 100% of the time, perfectly reproducible, mp3s through Winamp, WMP, or foobar.

The thing is, for an Internet connection, 10% of a gigabit link is still total overkill. It's still ~100Mbps of transfer. Which isn't gigabit, but should not be affecting your IRC skillz, or your WoW ping timez.

I wonder if this is somehow related to the slow network file copy that others (as well as myself) have experienced. While this seems to be related to only when you are playing audio across a network, I wonder if some audio process might still be active slowing file copy even when not playing audio. I have gone back to xp for now and was really hoping to put vista back on when the problems were fixed; however, if this is by design then i think i will be sticking with xp for as long as I can.

I second the opinion of the last time I had any music skipp was a home built K6-2 300 with 64 MB of RAM in Windows 98. This should not be happening with a Dual Core Athlon 6000+ and 2GB of RAM. Anyone who tries to explain this away is, at best, wearing the rose colored spectacles.

Originally posted by Metasyntactic:Considering that users didn't even notice this for many many months, why would you expect any difference from MS?

Yes, that was smarmy alright. And completely devoid of any explanation. It sounds more like a pathetic attempt at covering up a shortsighted decision (by today's standards ofcourse). The first thought that crossed my mind was - most users wouldn't notice because they are using 10MB (=100Mb) networks. duh ! And jubai noticed it because he was using Gbe.

quote:

Less smarmy answer. How would you have tested to find this? Clearly the networking guys are not likely to test their stuff under any combination of software that uses the network running. After all, that would literally need a near infinite test bed. The music guys would most likely test networking (since they do streaming), but would probably only verify that streaming worked smoothly, not that actual network bandwidth stayed the same.

Actually it seems (from Mark's blog) that they did indeed test it - but decided that a 100Mb limit wouldn't affect users. Now with Gb ethernet becoming more widespread that decision was a wee bit shortsighted. And I can understand that. What I cannot understand is you trying to rationalize testing methodologies without understanding what they did and why they did it. I guess I have come to expect more from you.

quote:

So you'd only notice this if you were copying something big, had an expectation of how long it would take, and then turned on some tunes to help pass the time, only to notice the enormous slowdown.

And that is a very rare task ? With home networks becoming more ubiquitous - and making a huge assumption that you aren't allowed to play media in your corporate machine and thus not notice the slowdown - why would you say something like that ?

I love how he never mentions the fact that this worked JUST FINE under XP. Why is this throttling even required? Playing back audio uses so little CPU on a modern system that it doesn't even show up in Task Manager anymore for me with Winamp5...

Just for shits and giggles, I'm going to max out sending from a 1 Gb XP box to a 100 Mb XP box and fire up some tunes to see how things work. Stay tuned for results.

It sounds eminently plausible to me. It would certainly explain why I don't see any slowdown on my 100 Mbit network.

I would question the design decision, though. The essential issue is that Windows isn't an RTOS; interrupt latencies are basically unconstrained (and for these purposes, a DPC is as bad as an interrupt), meaning that the latency experienced by audio software is effectively arbitrary and unbounded. MMCSS tries to mitigate this by telling the network driver "don't generate so many interrupts".

In my view, network activity should be allowed to cause network glitching. For one, it already can; MMCSS can't prevent that. The NIC could decide to just spin forever in its ISR/DPC, if it wanted, and throttling the rate at which interrupts are generated does nothing to diminish this. Since latencies aren't known (or bounded) in Windows, if you really care about seeing the lowest latency possible in your audio application, you need to perform as little concurrent I/O as possible.

Windows could likely be architected to demonstrate better characteristics in this regard, but I think the fundamental issue is here to stay (at least until such a time as vendors ship network drivers which boast known latency characteristics, which seems unlikely in a general purpose OS) and the MMCSS really can't do anything satisfactory about it.

quote:

I love how he never mentions the fact that this worked JUST FINE under XP. Why is this throttling even required? Playing back audio uses so little CPU on a modern system that it doesn't even show up in Task Manager anymore for me with Winamp5...

MMCSS is for more than just audio playback. It's for any application where low latencies are desirable.

And there are certainly applications where a high interrupt load from a NIC could be the difference between working and not working (e.g. decoding video using high complexity codecs; the ten percent saved on cutting down interrupts could definitely be the difference between dropping frames or not).

Why is there need to "prioritize the media process" for networking thereby slow down all network speed when playing back media. This is not required for xp as far as know. The forgetting about gigabyte connections also does not make sense as vista should be optimized for latest hardware (gigabyte has been around for quite awhile) Just does not make sense that xp can handle media better than vista; but then again vista has been a strange animal.

Why is there need to "prioritize the media process" for networking thereby slow down all network speed when playing back media. This is not required for xp as far as know.

The blog says why, to ensure that sound interrupts are handled with as low of latency as possible. But I agree with PeterB that the whole thing seems questionable, especially since no one's really complained about it before.

I also agree with peter b, but did not see his post as we posted at sametime. To me, the whole thing also seems highly questionable as never had any problems with audio playback on xp. I also wonder why there is not sometype of network buffering written for media playback of home media files. Buffering would eliminate the sound interrupts with regard to playback of ones own home media over a home network. Or is there reason buffering would not work for accessing and playing ones own files over a home network (not talking about streaming media over internet)?

Buffering would eliminate the sound interrupts with regard to playback of ones own home media over a home network. Or is there reason buffering would not work for accessing and playing ones own files over a home network (not talking about streaming media over internet)?

Buffering will help with slow media but it won't help with interrupt latency since the card can only process so much sound data at once. The driver for the card has to feed the card sound in chunks and if one of those chunks is late you'll get stutter.

"The driver for the card has to feed the card sound in chunks and if one of those chunks is late you'll get stutter".

I sort a disagree but must say i am not that tech savvy. What i am saying is there should be a way to transfer part of the file to the hard drive so the "media playback" computer can play that part of the file "locally" while the other is being transferred; has nothing to do with audio transfer; but with the transfer rate of data. Or are you saying the latency occurs within the driver or sound card itself and therefore network connection speed is not relavent?

It should be noted that neither the audio or the video of the H.264 skipped during playback. However, the synchronization was off by approximately 1 second by the end of playback of the 3:23 video. Testing with no network load revealed a similar synchronization error; the P-M just can't play back H.264 at 800MHz. However, no popping, crackling, or dropped frames were observed. Playback degraded as gracefully as possible given the limited resources.

Now for a standard DivX file. Network utilization and CPU load are relatively unaffected:

Finally, an MP3, with virtually no effect at all:

So, what conclusions can we draw from this?-The XP audio/video subsystems degrade gracefully when playing back video that is too complex for the available CPU. No crackling, popping, or skipping occurs-XP degrades network performance gracefully as CPU load increases, so playing MP3s or watching non-HD content has trivial impact on network performance.

-The Vista audio subsystem breaks down into a popping, skipping, crackling mess very easily.-As a result, the developers implemented a kludge that decreases network performance to compensate for their shitty new audio stack.

I am not sure what you are saying; but all i can say vista failed in my home network media setup and this explains why --- though i dont understand it. But i know enough that something is seriously wrong with vista. The question for me that remains, what can correct the problem if i am trying to setup a media networked center (through a simple peer to peer server) through vista. It seems to be stick with xp for now as it works?

Or are you saying the latency occurs within the driver or sound card itself and therefore network connection speed is not relavent?

Yes, even if you buffer the whole file you can't give it all to the sound card at once. Most likely the driver has to DMA small chunks of the file into memory and then the sound card plays them from there but that DMA area is going to be a lot smaller than the player's buffer or any filesystem caching going on. So if the driver is delayed by another ISR or DPC the DMA area won't have any new data to play so it'll probably end up just playing the last few ms of sound again until the DMA area gets updated.

But you would need an ISR or DPC to either start at a really bad moment or to run for an extremely long time for that to happen. I would think it would be much more likely for a storage driver to cause this than a NIC driver.

so even if i have file local hard drive file independent of network transfer it will still get garbled by other processess --- is that what you are saying --- its interesting as this never happens when on xp.

So, what conclusions can we draw from this?-The XP audio/video subsystems degrade gracefully when playing back video that is too complex for the available CPU. No crackling, popping, or skipping occurs-XP degrades network performance gracefully as CPU load increases, so playing MP3s or watching non-HD content has trivial impact on network performance.

That depends entirely on the behaviour of the network driver.

The behaviour they are trying to remedy happens in XP and it happens in Vista. The question is not that XP doesn't have a problem (in that compute-intensive and ISR/DPC-intensive procedures can cause a deterioration of media performance). It does; use a NIC that generates a lot of interrupts and your media performance will suffer. It can't help it; it can spend more time in an ISR or DPC than it has buffer for, and it can spend so much time in an ISR or DPC that it doesn't have enough processor for filling the buffer or decoding the video anyway.

The question is whether this is a behaviour that needs "fixing". Given the constraints of the platform they're working with, I would say "no", it is not.

Windows Vista has measurably lower latency for audio, and its audio stack has less jitter than XP's. But the price seems rather high.