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."
Maybe if said HD camera has a USB host controller, like that USB-2-GO stuff.
Otherwise, I suspect USB 3.0 is as braindead as USB 1.0 and will still require a computer to do all the actual work.
Uh. No. In 1996 FireWire was at 393 Mbit/sec (S400 standard). USB 3 seems like it will be plenty faster. There is more than jus speed advantage, though. FireWire likes to change plugs at every new generation. USB does not.
Could you please explain that a bit?
It's my understanding that high throughput drivers usually use DMA.
In my experience polled mode drivers are pretty rare. Especially in high throughput.
Weaselmancer
rediculous.
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.
I'm holding out for WARP speed...
'bursty' ... is that sort of like 'minty'? ;)
No, it's that max speeds for USB 2.0 refer to the max burst speeds, not the maximum sustainable speed. A single 7200 RPM drive attached via USB 2.0 will be substantially slower than if you attached it via SATA or IDE, even though 60 MB/s (= 480 Mbit/s) should be enough for most drives.
Game! - Where the stick is mightier than the sword!
It seems USB3 it will be about as fast as Firewire 800. And until then, we'll be stuck with sucky USB2 speeds because Firewire is essentially dead. This is simply incredibly annoying.
>Am I the only one who didn't really notice a 10X speed improvement when moving from 100 Mbit Ethernet to gigabit Ethernet?
Well, youre probably not getting 10x. Depending on a slew of factors (your switch, cable length, etc) youre getting anywhere between 100 to 800 mbps. Have you tried any speed tests? With gigabit I can copy to my nas at 25 megabytes per second. At 100 I was getting under 12. So that's twice the speed for me, which is most likely limited by the CPU on my nas and not ethernet.
>Conventional hard drives are just too slow.
Not really. Current drives go way past the limitations of USB2. We need a faster USB. Firewire is dying so USB needs to take up the slack on fast local connections. Shame esata isnt taking off with the home market.
>It looks like Linux may even support this before Windows, thanks to the Windows 7 schedule
USB 3.0 will work like any device: with a driver. I expect both XP and Vista to have it as manufacturers will simply write their own drivers without waiting for MS to package it into a service pack.
Gigabit Ethernet is a vast improvement over 100Mbit. Two windows boxes with fast SATA drives I see no less than 20 megabytes/second transfer speeds on a Vista64 XP64. Top speeds exceed 30 MB/sec (~300+Mbps)! My home server runs Linux but for some reason SAMBA is dog slow no matter how much I tweak the damn conf file. 10-12MB/sec tops for Linux Windows (without tweaks it was 3-4MB/sec!).
I have a four disk 1.5TB raid 5 array using SATA disks on a pciX controller and mdadm. Copying from the array to an **old crusty 20 gig ATA** root drive I see 40+ MB/second! So saying today's drives are too slow is not the case. I would love to see the speed with an SSD, bet it would easily soar over 100MB/sec! Wish SAMBA could keep up.
I have yet to actually test my Linux notebook with NFS to the server as I just use wireless so its always going to be slow. But saying you see no increase means you aren't really taxing the network.
PS if anyone knows how to speed up SAMBA under Ubuntu 8.04 please let me know. I used all the tcp_nodelay and the other tcp settings but nothing really works.
USB2 promised 480Mbps and never delivered it. You get 250Mbps on a good day. Now we have marketing claims that USB3 will be "10x faster," yet a video demo shows it's 3.5x faster. That's 1.5Gbps, not 5Gbps.
From the article
The Windows demo saw around 318 MBps, while the Linux demo typically showed 125 MBps. I saw as high as 233 MBps while formatting the disk. dd is not the best application to use for performance testing; I only used to whip up a simple demo.
Application layer measurements showed poor performance (around 2 MBps). I think two things added fixed latencies between the application layer and the host controller hardware. First, there was a massive amount of debugging output in the host controller driver and mass storage driver. Second, I had placed some msleep() calls in the USB MSD driver so that I could see the debugging output and trigger a PCI analyzer at the same time. I didn't have time to take those out before I ran my demo. I need to run more tests to disable debugging and profile the upper layer stack for other bottlenecks.
i.e. the 3.5x figure is from something which is not optimized. Actually it doesn't sound like the host controller or mass storage hardware is optimized either, she said it could use longer burst sizes. Plus it's an FPGA, not an ASIC. It's too early to judge performance yet.
Still the Windows demo figure of 318MB/s is quite close to the 350MB/sec projected max speed for USB 3.0 from the video.
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;
An awful lot of people are looking down their noses at USB 3 because it's not Firewire. Has everyone forgotten that Firewire grants devices DMA access to physical memory? Any physically connected device can be used to bypass the system's security. I'm grateful that USB isn't more like Firewire.
Wake me up when Firewire over UTP gets popular. THAT would be interesting.
Too bad they used Windows to show it performing about twice as fast as the Linux test ...
The tests were nothing alike. The Linux demo was sending data to an actual storage device, not to a loopback device designed only to test throughput. The Linux driver also had a great deal of debugging code running which contributed to the relatively low throughput.
None of which is to say that Linux was or deserved to be the star of this show. It's nice, however, to see technology vendors demonstrating software on platforms other than Windows.
Sampling and encoding the events before they hit the limited USB connection is. That requires extra equipment, however.
Sam ty sig.
Yes, but the difference is a USB device or controller costs about 2 yen, while a Firewire endpoint costs about $20, half of that in licensing alone!
Firewire is by far a superior interlink in terms of performance, but it is overpriced (you can thank Steve Jobs for that one).
-Billco, Fnarg.com
The agreement essentially brings patents held by these companies into a single portfolio that can then be licensed by manufacturers for a single fee. That fee is US$.25 per system that includes FireWire ports, regardless of the number of patents used or the number of FireWire ports implemented. This is a dramatic decrease from the US$1 per port per device (see "Apple To Charge 'Per-Port' Licensing On FireWire") that Apple originally announced it would charge for its own patents.
$10 is not in licensing fees.
Protocol latency is a big deal. If you have a large per-transaction overhead, then the overall throughput of a given medium will be very sensitive to the number of transactions it creates on the media, as opposed to the total number of bytes it needs to move.
That's part of the reason the HTTP sprouted request pipelining, since the round-trip-time between the endpoints of the connection figured largely in the startup latency of each connection.
It sounds like the typical PC implementation of USB relies heavily on the CPU to handle all but the lowest levels of the protocol. (I'm relying on hearsay here.) If this is indeed the case, then it'll be hard for USB to reach the max sustained speeds for storage devices, unless there's a mechanism for requesting large blocks of data (or large numbers of small blocks) in a single transaction.
For us old-school types, it's similar to the reason XMODEM didn't get much faster with faster modems over a certain speed. XMODEM didn't pipeline anything. It'd send a block, and then wait for an ACK. Since the latency of fancier modems was higher than the simple FSK 300 baud modems, the handshake turnaround time of the ACK swamped the gains made while sending the blocks. (Also, the tiny block size didn't help.) Thus, pipelined protocols like ZMODEM and large-block non-pipelined protocols (XMODEM-1K) came about to address this.
Program Intellivision!
Again, bull shiat. Use google before stating "recent developments."
USB 2.0 was released in April 2000.
Those licensing fees were announced in May 1999.
In Jan 1999 Apple announced that it would be $1 per port. As far as I know it's always been $1 per port. Now I don't know of any devices with 10 ports on them (Making the licensing fee $10). Here's a CNET article from the same time.
Both were before USB2.0 was released and considerably less than what you claim.
http://en.wikipedia.org/wiki/Power_over_Ethernet
If that's a troll it's a good one, but you can provide 7.5x more power over ethernet then the USB spec allows (15.4W vs 2.5W). 802.3at pushes things even further to 24W max.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
USB suffers from 1 ms time quantization and thus latency. I see nothing about fixing this.
Example badness:
When running MIDI over USB, timing is forced onto 1 ms slots. Normally when playing a chord, the keys don't all hit at exactly the same moment. You can't really tell, except that this makes the music sound natural. With the 1 ms problem, the keys happen at exactly the same moment (bad) or spread out into two separate events (worse).
Yes, USB 3.0 is still quantized. However, USB 2.0 devices can be sampled more often than 1ms. The 1ms frame was broken into 8 microframes in USB 2.0. I'm not a sound engineer, but it seems like you could have some buffering on the device side to send several sound samples with time stamps in one microframe. The software on the other side could re-space out the samples. Would you really notice a 125 us delay when playing music?
Hmm, a crappy host based implementation at 5Gbps or a storage targeted, low everhead one at 3Gbps (possibly going to 6Gbps if the next gen spec gets extended to eSATA), I know which one I will use =)
Actually, USB 3.0 was targeted for mass storage devices. They added the concept of Bulk Streams to support "out-of-order data transfers required for mass storage device command queuing." (USB 3.0 spec, section 4.4.6.4) Basically, the host can queue up to 65K SCSI commands, and the device can choose which command it wants to service first.
The host doesn't have to poll the device to see when commands are done because they added device notifications to USB 3.0. So the host fires off 65K of SCSI requests and the device asynchronously notifies the host as they get done. I'm no firewire expert, so I have no idea if it does something comparable. :)
USB hasn't changed the approach towards class compliance, and they continue to improve those related specifications. If you want to point fingers, look at the hardware and software vendors. FTDI, for example, makes a nearly ubiquitous USB-serial chip that is not class compliance in spite of the fact that every major OS supports the serial device class.