USB phones/sound robs which CPU?

[Krusty]

Another thread reminded me of a question I wanted to ask.

We've all heard and understand how USB audio devices, onboard (integrated motherboard) audio all eat up some of the CPU cycles because they are not processing the info themselves as a standalone sound card does.

My question is: What CPU do they use?

In the ever-increasing world of multicore processors, I'd be happy to trade a little CPU resources to an onboard or USB based device, if I knew they'd be using my second, third, or fourth cores, leaving my first core for gaming.

Can you get these things and your games to run on different cores? Would that remove any CPU issues with gaming and the devices mentioned above?

[Skuzzy]

It does not matter what core they use.  When the data is being moved from the USB bus, all the cores are frozen, unless the instructions they are going to execute happen to be in the cache.  The core that handles the USB sound stuff will have its cache completely invalidated.  So when it is done, it will have to fetch from system RAM, raising the likelihood of bus contention occuring between the cores.

When bus contention occurs, only one core can access system RAM at a time.  Because the brain dead USB bus is brain dead, it has to be given highest priority in order for it to be serviced.  So all the other cores have to sit and wait during a bus contention until whoever has the USB bus is finished.

That is about as simple as I can get.  There are a number of other things that can happen as well.

[Krusty]

Yowzers....

Is that specific to USB, or all similar interfaces? Hypothetically if a headset was keyed/built for firewire interface (as a random example) would that be any better?

[Skuzzy]

USB and Firewire are both CPU dependent.  Both are dumb serial inerfaces.

[Pudgie]

Hi Skuzzy,

I was reading this thread & I was thinking about this issue as I also use a USB headset along w/ a CH USB Hotas & am using the Realtek onboard sound chip but as of yet I haven't noticed any performance issues yet (Intel C2D E8600 OC'd to 4.0Ghz, EVGA 780i FTW mobo w/ 4.0Gb OCZ HTC Reaper DDR2 1066 mem running unlinked-1600 FSB/1067 mem speed, EVGA GTX 260 Vanilla OC'd to 285 ref 648/1476/1242. Gave setup for reference).

From what I understand the USB/Firewire buses are subsets of the PCI bus (carries sound, networking/LAN, modem/dialup, etc.) which is controlled by the PCI bus controller which uses bus mastering to prevent any 1 device from hoarding the entire bus, correct?

So what you were referring to when you mention bus contention is a FSB issue (front side bus-between CPU & system mem)? I would have thought that the FSB controller would employ something similar as the PCI bus to counter contention since the advent of multicore processors................... .............................

Would you elaborate on this, please?

Want to gain a better understanding of why I'm not seeing any issues when others are.

 

[Skuzzy]

The USB bus is not a subset of the PCI bus.  The USB bus is a serial bus, not a parallel bus and has its own controller.

Bus contention occurs when one, or more, cores of a CPU need to access memory.  Only one core at a time may access system RAM.  When one core has to access system RAM, all the other cores have to wait.  The arbitration for the bus between the cores is based on the priority of the process.  In the case of USB devices, they get top priority as the bus is too dumb to wait to be serviced or there is risk of losing data.

Bus contention also occurs when a bus master, external of the CPU, accesses system RAM.  This also blocks the CPU's from accessing system RAM.  Most of the time this is not a bad thing, as bus masters are doing work the CPU would have had to do, but a bus master transfer of data to system RAM will invalidate all data in all the CPU core caches.

You are seeing issues, but they are either occuring fast enough you do not notice it, or you have grown use to the slow down.

The USB bus is best suited for small data transfers, like those of a joystick/HOTAS device.  The bus has always been a poor choice for moving a lot of data or a continous stream of data.

[Ghastly]

Skuzzy's point is that the way it was designed, it doesn't have the "smarts" built in to make it play nice, so it has to be have the highest priority interrupt in order to work.  

To my understanding (which may be a bit fuzzy)  -> this means that when it wants to be bus master, everything else in the system takes a back seat - including the processors - and because of the DMA transfer, the memory cache must be refreshed after every USB transfer - which in some modes, I believe is by byte.  All this is the same for every other PCI device, except that other subsystems tend to be designed to avoid interrupting every other process rather than around the concept that they are the going to be the highest priority in the system. <- End

And because a system "works as designed" doesn't mean it necessarily "works well" - or that the user will ever notice that it's designed more cheaply and less than optimally and works less efficiently (even abysmally, in some instances) than might make sense in a perfect world.

<S>

(*Whoops Skuzzy posted back while I was typing...)

[Pudgie]

Thanks, Skuzzy!

I get it now.

So to make the best of a not-so-well designed data transfer system:

1. Keep as many devices as is feasible off the USB/Firewire bus.
2. Utilize the PCI bus as much as feasibly possible due to it's controller having bus mastering capabilities.
3. Use devices on the PCI bus that does all it's processing onboard the device to take advantage of the PCI bus & relieve the CPU of additional cycling to make the most of an already poor design, ie "the lesser of the 2 evils".

I wished that the mobo makers hadn't stopped making enthusiast-level mobos that had no onboard devices on the mobo (sound, LAN, etc) so that you could set up your system w/ the devices you want & not have to pay for devices that you most likely won't use.

Ok I feel better now.

 

[Ghosth]

Agree pudgie, hate looking at Mboards and finding nothing that isn't loaded with onboard video, sound, lan, etc.

[RTHolmes]

USB and Firewire are both CPU dependent.  Both are dumb serial inerfaces.

dont firewire interfaces use their own hardware to manage transfers, specifically to avoid the buffer copy problems you mentioned with USB? thats why they are way more complex and expensive than USB interfaces and get better throughput?


edit: in my experience eg. USB scanners regularly cause XP to hang whereas SCSI and firewire scanners never do for just this reason.

[Skuzzy]

I was at Adaptec when we designed the Firewire interface.  It was a precursor to USB and, yes, it is a bit smarter, but still requires significant CPU overhead.

SCSI is dependent on the host adapter you use.  It can be very high to very low CPU usage.

By far and away, USB is the worst of the lot.

[RTHolmes]

By far and away, USB is the worst of the lot.

thats certainly my experience. had to replace a bunch of fujitsu scanners recently we use for document archiving, used to be SCSI (and USB), never had any problems with em. theyve deleted the SCSI scanners and replaced them with USB2 now, with no firewire option. I dread to think what the time for sorting out USB issues since has cost us