4

In the hard drive controller card market - the higher-end (LSI, 3Ware) cards have their own on-board CPU and RAM, and take care of interacting with the hard drive, only notifying the system's CPU after the data has been transferred completely.

Is there a card that provides equivalent functionality for USB peripherals? (So that multi-gigabyte data transfers to a USB-connected device would have negligible CPU overhead, as with the above-mentioned SAS/SATA cards?

I'm aware that a cheap card can support DMA. And that 1394 cards can support DMA. I'm inquiring about the existence a card that fully implements the protocol, manages the bus, and transfers the data itself, only handing off data blocks to the host OS when they're fully off the wire.

Jon Bailey
  • 41
  • 5
  • 2
    *cough* FireWire. – Ignacio Vazquez-Abrams Feb 28 '12 at 15:31
  • @IgnacioVazquez-Abrams - I know your response was a joke. But there's apparently not even any 1394 cards that fully offload transfers the way the SAS / high-end SATA cards do. – Jon Bailey Feb 28 '12 at 15:36
  • @JonBailey Many FireWire cards do support DMA (it was famously a way to hack Windows XP for a while). Most of the newer cards do not in order to make the cards/chips cheaper (as nobody uses firewire and it's slowly dying off). – Chris S Feb 28 '12 at 15:51
  • @ChrisS Yes, this is true. Do you even know of a 1394 card that offloads transfers the way the HDD cards do? – Jon Bailey Feb 28 '12 at 15:57
  • There's only one way to offload memory transfers in a modern PC, DMA. It seems like you're hunting for something specific, but not saying what that is. It also sounds like you're barking up the wrong tree. If you want external block storage with all the benefits of a RAID HBA, use eSATA or SAS and actually get a high end HBA. – Chris S Feb 28 '12 at 16:10
  • The high end HBA's do not require the host CPU to decode command packets, or reorder them for example. The CPU on the HBA does this. The work is "off loaded" to the HBA. Also, they do not need to block the host CPU for storage space as the bytes come in off the bus, only when they need to push a completed block into main RAM - "off-loading" the need to hold system RAM blocked with the CPU in iowait. – Jon Bailey Feb 28 '12 at 21:13

1 Answers1

3

Basically any USB controller with DMA will offload bulk data transfers to the on-chip DMA controller instead of doing CPU PIO. From what I've seen most controllers do not have DMA, it's difficult to find.

Chris S
  • 77,945
  • 11
  • 124
  • 216
  • 2
    Thanks! Do you know of any? Is there a single example? :-) – Jon Bailey Feb 28 '12 at 15:32
  • 1
    (And more to the point, are there any that only do the DMA transfer after taking a full block / unit of data off the bus) – Jon Bailey Feb 28 '12 at 15:58
  • Every EHCI controller must have DMA. The control structures are all maintained by the host in its own memory and the USB controller reads them and fills them in (or writes them and frees them), notifying the host when transfers are complete so the host can post more host memory for subsequent data. EHCI is fundamentally built around DMA with the host's memory being used for all transfers. Most USB controllers are EHCI, I believe. – David Schwartz Feb 28 '12 at 16:25
  • 1
    @David The EHCI and XHCI controllers in my HP 8560p laptop do not have DMA. I can confirm that it chews up ~10% of my CPU to transfer at 40-50MBps. – Chris S Feb 28 '12 at 16:47
  • 1
    I don't see how that's possible. Without DMA, how does the controller even read the iTDs, much less read or write to and from the schedule. They're all 100% contained in the host's memory. (I don't doubt that it may take 10% of your CPU to transfer at 40-50MBps, but that's not due to a lack of DMA.) See section 1.2.1 of the [specification](http://www.intel.com/technology/usb/download/ehci-r10.pdf), particularly the 'Schedule Interface Space' part. All data is kept in the host's memory, there's no other mechanism. – David Schwartz Feb 28 '12 at 16:57
  • @DavidSchwartz I really don't know this stuff all *that* well, so I've got no answer =] – Chris S Feb 28 '12 at 17:05
  • As I understand the EHCI specification, it is fundamentally based around DMA. All bulk data is always, and only, contained in the host's memory. – David Schwartz Feb 28 '12 at 17:05
  • This is part of why I'd like to see the full off-load. For example, a chip without any place to store data as it comes in may say "Hold on CPU (go into IO-wait)", then dribble the bytes as they come in off the wire into RAM, then let the CPU have RAM access back again. A disk drive controller card with its own CPU/RAM would only interrupt the CPU (appearing as "cpu usage") to copy the data from its RAM down the PCI BUS to system RAM. – Jon Bailey Feb 28 '12 at 20:59
  • @JonBailey: I doubt any mainstream chip does that (because it's no harder to do it better). They have to have a large enough buffer to hold a single DMA transaction, and then they always run that DMA transaction at the full speed of their own bus (assuming RAM can keep up). This will tie up the RAM bus, but either the DMA is fast (in which case it will be over soon) or it's slow (in which case the CPU can interleave). The CPU has caches so this shouldn't hurt it much. – David Schwartz Feb 29 '12 at 05:36