Slashdot Mirror


Intel Developers Demo USB 3.0 Throughput On Linux

Sarah Sharp writes "Intel's Open Source Technology Center is working on USB 3.0 support for Linux. USB 3.0 has wire speeds of 5Gbps and promises to be 10 times faster than USB 2.0. A recent video demo shows speeds that are 3.5 times faster than USB 2.0. The USB 3.0 drivers will be submitted to the mainline kernel when the eXtensible host controller interface (xHCI) specification reaches a 1.0 release."

6 of 231 comments (clear)

  1. What's in a name... by alain94040 · · Score: 5, Insightful

    USB 2.0 gave us high-speed and full-speed. Some marketing department had to work really hard on the USB 3.0 specs, to come up with... super-speed.

    Now let's talk about the obvious problem: at 5 Gbit/s, it's faster than the Ethernet in my house (1 Gbit/s). Am I the only one who didn't really notice a 10X speed improvement when moving from 100 Mbit Ethernet to gigabit Ethernet? Conventional hard drives are just too slow.

    Maybe SSD + USB 3.0 would be really cool. Imagine a Flash based HD camera talking to a Flash based hard drive. Is 2009 the year of the Flash?

    Which brings me back to my original point: for the next generation USB, I propose the name flash-speed :-)

    PS: thanks to Intel for helping Linux stay on the leading edge. It looks like Linux may even support this before Windows, thanks to the Windows 7 schedule... I just wish Intel's pre-conditions on contributing to the xHCI specs didn't start with stuff like:

    Step 1. Print and execute the xHCI Contributor agreement. Note: The agreement must be executed by a corporate officer.

    --
    http://fairsoftware.net/

    1. Re:What's in a name... by John+Allsup · · Score: 5, Interesting

      I guess for hard drives, the question is how close to eSATA it gets.
      Also, does USB3 still have the CPU overhead and latency of earlier USB compared to FW?

      --
      John_Chalisque
  2. Re:Wha? by Hal_Porter · · Score: 5, Informative

    Yup the host sets up a structure in memory which lists all the USB endpoints. When a driver wants to do some IO it asks the host controller driver which adds a request into the structure with a pointer to a buffer. The host controller hardware reads the structure with busmaster DMA and generates the USB packets. When the device answers the host controller DMAs the data into the the driver's buffer interrupts the CPU. Then the host controller can pass the buffer back to the driver. Polling is done by leaving the request in the structure, it doesn't require any CPU activity. Intel like USB because they invented it, not as some sort of conspiracy to load your CPU.

    --
    echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
  3. Re:cool, at least it is progress by thermian · · Score: 5, Funny

    yeah yeah, i read the comments about gigabit ethernet being faster, thats not the point, usb 3 is still better than usb 2, enjoy the weekend...

    We're geeks, reading stuff like this *is* enjoying the weekend.....

    --
    A learning experience is one of those things that say, 'You know that thing you just did? Don't do that.' - D. Adams
  4. Compared to USB 1... by MonoSynth · · Score: 5, Interesting

    This shows where Linux is nowadays. It took literally years before USB1 was even supported and now Intel uses Linux to prove USB3's performance!

  5. Re:Wha? by raynet · · Score: 5, Informative

    Taken from wikipedia: "Although high-speed USB 2.0 nominally runs at a higher signaling rate (480 Mbit/s) than FireWire 400, typical USB PC-hosts rarely exceed sustained transfers of 280 Mbit/s, with 240 Mbit/s being more typical. This is likely due to USB's reliance on the host-processor to manage low-level USB protocol, whereas FireWire delegates the same tasks to the interface hardware. For example, the FireWire host interface supports memory-mapped devices, which allows high-level protocols to run without loading the host CPU with interrupts and buffer-copy operations."

    --
    - Raynet --> .