Intel Developers Demo USB 3.0 Throughput On Linux 231
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."
Re:What's in a name... (Score:3, Interesting)
Or would the whole thing somehow circumvent the need to tell the OS what's going on with the file system?
Re:What's in a name... (Score:3, Interesting)
The thing is that USB is bursty, in practice you'll probably still get much better speed out of Gigabit ethernet than you will with USB 3.0.
As for Gigabit ethernet, it's a massive upgrade from 100 megabit ethernet, at least in my usage. It only takes 2 modern drives in RAID 0 to saturate Gigabit ethernet, or just 1 fast SSD.
Re:What's in a name... (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?
But it doesn't fix it (Score:1, Interesting)
USB3 will make wire speeds faster, and devices more expensive, but it won't deliver the performance we need, because they haven't fixed the root issues. USB is a silly polling system where the host has to ask each device in the tree if it has anything to say, and then (if it's a "bulk" endpoint), allocate time and finally do the transfer (interrupt and iso endpoints have time allocated all the time). Unless they make fundamental changes (which they won't), USB will load up the host excessively and give disappointing performance. But at least with USB3, the price to add it to a device shouldn't be that much lower than FireWire, so we might see more people making the right choice for what to support.
Motherboards (Score:3, Interesting)
When can I buy my first motherboard that is USB 3.0 compliant? I want to build a rig in the spring. I'd consider holding off until the summer to get USB 3 so it is more future proof, but I won't wait another year.
Re:What's in a name... (Score:5, Interesting)
That USED to be true. It's not the hard drive, all the layers that get put in between when you access a disk over the network. Modern hard drives can easily do 60MB/s sustained.
For instance, I have a couple raid6 arrays which clock in at about 250 MB/s and 150MB/s natively. If I hook that machine up directly to another machine's ethernet port I only get about 30MB/s sharing the device w/ iSCSI. SMB and NFS yield similar results. This is true even though I can get over 900Mbps using iperf.
Sharing disks over gig-e sucks when you actually need throughput. It's great for when you just need to expand a SAN and speed is secondary. I've heard that bonding two Gig-e cards doesn't realize much of an improvement FWIW, so I assume latency is part of the reason it's slower.
Re:What's in a name... (Score:2, Interesting)
Honestly, Intel didn't have much choice, the NT kernel can't exactly be obtained, modified and distributed for free
At the moment Windows supports three host controller drivers. OHCI and UHCI for USB 1.0 and EHCI for USB 2.0. There's nothing special about host controller drivers, anyone can write one. If they wanted they could write a host controller driver for xHCI and then Windows would support USB 3.0.
latency badness (Score:5, Interesting)
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).
Compared to USB 1... (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!
Firewire Not Dead, Doing Pretty Good Actually (Score:3, Interesting)
Whenever a story about USB3 is written, the following caveats should be mandated by law if necessary:
1. Speed claims are theoretical, and do not reflect real-world results by a long shot. Lots of overhead, CPU dependence, etc.
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.
2. Firewire 3200 is approved and on the way. It will be faster than USB3, backward-compatible with FW800 (same cables and ports) and should begin appearing on Macs in January. Firewire isn't dead; Firewire 400 is being eased out in favour of faster versions.
If FW 3200 performs like its predecessors, it should be (in real-world usage) routinely about 2x faster than USB3.
Moral of the story: don't settle for mediocre.
There's throughput and then there's latency (Score:4, Interesting)
While not having to do with USB, the driver architect and concepts are likely very much the same.
Re:Wha? (Score:5, Interesting)
so why do FireWire 400 readers still consistently beat out USB 2 [scribd.com]:
heck, those benchmarks show that even using FireWire 400 to read a PIO CompactFlash card still beats USB 2.0 UDMA reading a UDMA-enabled CompactFlash card.
Re:What's in a name... (Score:1, Interesting)
Do you have some benchmarks to back that up? The best I have seen with Linux is around 25MB/s (that was a couple of years back though), with XP x64 (which is more or less Windows 2003) I get 32MB/s with a good enclosure.
Re:What's in a name... (Score:4, Interesting)
Re:Wha? (Score:1, Interesting)
Intel likes USB because it requires a host (aka PC).
Comment removed (Score:5, Interesting)
Who needs USB anymore ? (Score:5, Interesting)
Why are they wasting everyone's time with USB 3.0, when the rest of the universe is shifting toward Ethernet as a common interconnect ? Note I didn't say IP, just Ethernet - good old CAT-5.
Frig, if the audio folks have already started that transition, then what the hell is Intel doing ? The audio industry is probably the most retarded in the world (according to my failed expectations), and even they see that Ethernet is a cost-effective and braindead simple replacement for all these proprietary cables we've had to contend with over the years.
Re:Wha? (Score:5, Interesting)
good point. and to be honest, most people don't need FireWire 800/1600 just to transfer a few documents or spreadsheets--or even photos & mp3s--to their computer. the few seconds saved doesn't justify the added cost of FireWire over USB. nor do they need to use a high-speed data bus for their mouse, keyboard, webcam, printer, scanner, or what have you. so it makes sense that USB is more prevalent than FireWire.
however, FireWire is still extremely useful (and crucial) to certain professionals who regularly work with large files or have to move around large amounts of data, like hi-res/raw images, lossless audio, hi-def video, etc. that's why FireWire is still pretty standard in high-end music & video production equipment. so the idea that FireWire is dead (or can simply be replaced with USB 2.0/3.0) is just poorly informed.
even the military still uses FireWire for things like the the F-35's vehicle systems network [itwire.com]:
the IEEE-1394B data bus is similarly employed in the F-22 Raptor [aviationspectator.com] for which it was developed. and NASA also uses it [findarticles.com] to monitor debris during launches amongst other mission-critical applications [daptechnology.com].
Speed isn't everything (Score:3, Interesting)
Re:There's throughput and then there's latency (Score:2, Interesting)
I seem to recall that some Linux drivers try to handle this automatically (Intel gigabit chips?). They do interrupts when the traffic is below some threshold and switch to polling when things get busy. The main reason, as you say, is to avoid interrupt storms; polling becomes cheaper on CPU time than interrupts when there is a higher than x% chance of there being packets waiting. It is also more resilient to DoS or server overload - if f.ex. an Apache server receives more requests than it can handle, throttling the polling speed makes more CPU available for handling requests instead of wasting it in interrupts receiving packets that the web server is too overloaded to handle anyway.