Linux first to offer USB 3.0 driver (Linux Devices) [LWN.net]

Linux Devices reports on the addition of USB 3.0 support in the upcoming 2.6.31 kernel. "A kernel hacker from Intel has posted a Linux driver for USB 3.0, making Linux the first operating system (OS) to support the new connectivity standard. Sarah Sharp announced that her xHCI-compliant driver for USB 3.0 will be supported in Linux 2.6.31 in September. The xHCI (Extensible Host Controller Interface) host controller driver is available now, and will be formally supported by the Linux kernel in September in version 2.6.31, reports Sharp, also known as the "Geekess." This should make Linux the first OS to offer a USB 3.0 driver, according to Sharp, who says she has worked a year and a half on the project."

to post comments

Linux first to offer USB 3.0 driver (Linux Devices)

Posted Jun 11, 2009 20:33 UTC (Thu) by tzafrir (subscriber, #11501) [Link] (2 responses)

Can anybody point me to a distribution (an actual operating system) that supports this?

Linux first to offer USB 3.0 driver (Linux Devices)

Posted Jun 11, 2009 20:44 UTC (Thu) by Tara_Li (guest, #26706) [Link]

Any of them will, if you grab the patch and apply it to the current kernel (and can do any magic needed to get it to fit - which shouldn't be that much, honestly, as 2.6.30 just came out...) Question then is if you have the hardware to need the driver.

I'd really expect that if you have the hardware, you know how to do it, or know someone who knows how, and will be happy to help you to get the chance to play with the shiny new geek toy.

I mean - note that we're looking at something on a par with gigabit ethernet. And likely to be enough ports to support some kind of mesh networking, rather than the star topology that has become the norm these days.

Linux first to offer USB 3.0 driver (Linux Devices)

Posted Jun 11, 2009 20:50 UTC (Thu) by mpmselenic (guest, #57902) [Link]

No, no one is yet shipping a distribution based on 2.6.31, which isn't due to be released for months.

Yes, anyone can download and build that kernel and run it in their distro of choice today.

Say what?

Posted Jun 11, 2009 21:11 UTC (Thu) by sbergman27 (guest, #10767) [Link] (24 responses)

"""
The spec is said to offer physical-layer throughput speeds of up to 5Gbps (gigabits per second), compared to USB 2.0's 480Mbps (megabits per second). By comparison, Firewire (IEEE 1394) currently tops out at 3.2Gbps.

It's said real-world transfer rates for USB 3.0 may be as much as 500Mbps, compared to 25Mbps to 35Mbps for typical USB 2.0 mass storage drivers, offering the potential for 20x faster speeds.
"""

Translating all of this to MBps (megabytes per second), for easier understanding...

---
The spec is said to offer physical-layer throughput speeds of up to 625MBps compared to USB 2.0's 60MBps. By comparison, Firewire (IEEE 1394) currently tops out at 400MBps.

It's said real-world transfer rates for USB 3.0 may be as much as 62.5MB per second, compared to 3MBps to 4.5MBps, offering the potential for 20x faster speeds.
---

So what's with the 10:1 ratio between wire speed and real world speed for USB 3.0? And I could have sworn my current USB 2.0 drives have managed better than 4.5MB/s.

And why are we still quoting speeds in terms of bits per second in the year 2009? I thought we agreed upon a standard size for a byte a while back, and the proponents of '7' lost?

Say what?

Posted Jun 11, 2009 21:16 UTC (Thu) by tzafrir (subscriber, #11501) [Link] (3 responses)

Do you have a 100MB ethernet adapter?

Say what?

Posted Jun 11, 2009 21:39 UTC (Thu) by sbergman27 (guest, #10767) [Link] (2 responses)

No. I have a mix of 12.5MB/s and 125MB/s NICs.

Say what?

Posted Jun 12, 2009 6:40 UTC (Fri) by shalem (subscriber, #4062) [Link] (1 responses)

I doubt you have 125MegaByte/second NIC's unless you've got fiber using NIC's, Gigabit over coper is a sham and only does 500 Mbit (which they
multiplied by 2 as its fullduplex, with that reasoning 100Mbit nics are 200Mbit). Yip, another score for the marketing department.

Say what?

Posted Jun 12, 2009 6:48 UTC (Fri) by yootis (subscriber, #4762) [Link]

Completely wrong. Gigabit ethernet is 1 gigabit in each direction simultaneously. Fiber or copper doesn't matter, they get the same speed.

I routinely get 960 megabits per second in each direction at the same time.

Say what?

Posted Jun 11, 2009 21:20 UTC (Thu) by martinfick (subscriber, #4455) [Link] (12 responses)

Serial buses tend to be quoted in bits per second. Disk throughput (not traditionally serial) mostly uses Bytes.

I suspect that the first statement was meant to be bits, and the "real world" statement was meant to be bytes (because dividing by 10 is hard).

Say what?

Posted Jun 11, 2009 22:51 UTC (Thu) by drag (guest, #31333) [Link] (11 responses)

* This. *

This is the answer.

The guy f*d up on the math, did a typo, or simply lacked understanding. I regularly see speeds of 10-20MBps on fast flash devices over USB 2.0.

Sure there is overhead to maintaining USB devices, but your looking at 10-20% overhead, not 90%. That's worse then Wifi which your lucky to get data transfer at 50% of the speed your connected at.

Say what?

Posted Jun 11, 2009 23:10 UTC (Thu) by sbergman27 (guest, #10767) [Link] (10 responses)

FWIW, if I don't get at least 30MB/s from a mechanical USB 2.0 drive, I start looking around for what the problem is.

The purpose of my original post was to point out how quoting bits/s instead of bytes/s causes great confusion for essentially no benefit. Mbps? MBps? Divide by 10? Divide by 8? 7 bit? 8 bit? Start bit? Stop bit? Parity bit? Frame bits?

I've dealt with this crap for 21 years or more, and it's time for the madness to end.

Computone? Digiboard? Okidata? TI? Do you cross 2 and 3? 4 and 5? Tie together 4, 8 and 20? Does 7 go to 7... or to 5? DB25? DB9? God save us if it's a conversion cable. Or a conversion crossover cable.

We've dumped most of the insanity. But let's get rid of the rest. Stop my nightmares.

Just tell me how many Megabytes Per Second the damned interface is nominally supposed to transfer and I'll be as happy as a clam at high tide.

DE-9

Posted Jun 12, 2009 7:36 UTC (Fri) by ncm (guest, #165) [Link] (2 responses)

That's "DB-25" and "DE-9". "D" is the shape, "B" or "E" the size, and "25" or "9" the number of pins. A "DA shell" has room for lots of pins, a "DF" not many.

DE-9

Posted Jun 12, 2009 13:45 UTC (Fri) by sbergman27 (guest, #10767) [Link] (1 responses)

Except that in practice, virtually nobody ever says DE-9.

DE-9

Posted Jun 20, 2009 20:07 UTC (Sat) by giraffedata (guest, #1954) [Link]

Oh, lots of people get DE-9 right. And there's nothing to lose by saying it right even if most people don't.

If you want to see a connector name that is almost universally misused, look at RJ-45. Virtually everybody calls the 8P8C modular telephone connector RJ-45, even though the real meaning of RJ-45 (an ancient hookup standard for modems) is formally documented.

Let's stop at bytes per second

Posted Jun 12, 2009 11:06 UTC (Fri) by khim (subscriber, #9252) [Link] (3 responses)

Just tell me how many Megabytes Per Second the damned interface is nominally supposed to transfer and I'll be as happy as a clam at high tide.

But how many bytes per megabyte? Some still think 1048576 (or may be 1024000 like on floppy disk?) is the right asnwer... The only sane unambigous measurement is byte per second...

Let's stop at bytes per second

Posted Jun 12, 2009 13:51 UTC (Fri) by sbergman27 (guest, #10767) [Link] (2 responses)

Bytes per second is fine with me.

FWIW, to me the only place where it makes any sense at all to use kibibytes (an how I despise that term!) is for RAM. Durable storage like hard drives, CDs, DVDs, and even flash memory, really, should just use simple powers of 10. RAM is a special case.

By the by... does anyone happen to know what style of "megabits per second" are referenced by USB 2.0's 480 mbit/s spec?

Let's stop at bytes per second

Posted Jun 12, 2009 19:12 UTC (Fri) by admcd (subscriber, #5415) [Link]

Ah, but how many bits in a byte.

I'm not sure whether there are any current systems where a byte isn't 8 bits. However, some standards bodies use "octet" to avoid any possible ambiguity.

Let's stop at bytes per second

Posted Jun 12, 2009 20:37 UTC (Fri) by gilb (subscriber, #11728) [Link]

USB 2.0 is 480x10^6 bits/second. PHY people tend to think in powers of 10.

Say what?

Posted Jun 12, 2009 14:15 UTC (Fri) by da4089 (subscriber, #1195) [Link] (2 responses)

i can't help but mention bps vs baud as well :-)

Say what?

Posted Jun 12, 2009 20:39 UTC (Fri) by gilb (subscriber, #11728) [Link] (1 responses)

In baud, I expect that USB 3.0 would be listed as 500 Mbaud as the symbols are made up of 10 coded bits.

That would make 802.11a/g 250 kbaud for all of its data rates (from 6 to 54 Mb/s).

Say what?

Posted Jun 20, 2009 20:17 UTC (Sat) by giraffedata (guest, #1954) [Link]

In baud, I expect that USB 3.0 would be listed as 500 Mbaud as the symbols are made up of 10 coded bits.

The fact that you can separate those bits in time means it's 5000 Mbaud.

In fact, it's directly analogous to a classic baud-measured protocol, Bell 103A: A 300 Baud modem transmits 300 bits per second, with every 10 representing one byte analogous to a byte in the USB stream.

On a transmission line, it is posible to represent multiple bits in a single indivisible unit of time -- a symbol --, and that's where baud and bps differ. For example if you have 4 defined voltages, a single symbol carries two bits.

Say what?

Posted Jun 11, 2009 21:54 UTC (Thu) by sf_alpha (guest, #40328) [Link] (2 responses)

Real world speed measured from single devices. This explain why 10:1 ratio apply for typical USB 3.0 devices.

At time USB 2.0 released, most early generation controller does not have enough processing power and buffer to reach 100Mbps throughput. But now I can copy files from my USB 2.0 drives at 20MBPS++ (200Mbps++).

And ... USB 3.0 now support FULL-DUPLEX, real-world throughput is much improved and theorically may reach maximum throughput at 4Gbps+ if controller is good enough.

Bit rate is mostly describe rate of serial of bits that transfer on the wire. Byte per second is usually use to measure throughput of real data or payload.

Say what?

Posted Jun 12, 2009 13:22 UTC (Fri) by clugstj (subscriber, #4020) [Link] (1 responses)

4Gbps full-duplex on a single wire? How do they do that, or did they add more wires for USB 3.0.

Four new wires

Posted Jun 12, 2009 14:17 UTC (Fri) by khim (subscriber, #9252) [Link]

4Gbps full-duplex on a single wire? How do they do that, or did they add more wires for USB 3.0.

Connector A, Connector B and Connector Micro B - two new wires for SuperSpeed Up and two new wires for SupeSpeed Down. Like Gigabit Ethernet, just shorter and few times faster...

Say what?

Posted Jun 12, 2009 12:39 UTC (Fri) by robert_s (subscriber, #42402) [Link] (2 responses)

"And why are we still quoting speeds in terms of bits per second in the year 2009? I thought we agreed upon a standard size for a byte a while back, and the proponents of '7' lost?"

Nope. That's not how it works. Take 8b10b coding for example. It takes 10 bits to transmit a(n 8 bit) byte, so the raw bitrate is indeed ten times that of the datarate.

Say what?

Posted Jun 12, 2009 15:10 UTC (Fri) by k8to (guest, #15413) [Link] (1 responses)

That wouldn't stop us from quoting in bytes. It complicates the picture a bit, but there are plenty of complications.

Say what?

Posted Jun 20, 2009 20:33 UTC (Sat) by giraffedata (guest, #1954) [Link]

That wouldn't stop us from quoting in bytes.

But bytes aren't a unit of measure to be quoted. They're units of data.

8 bits don't make a byte like 12 inches make a foot. It's more like 24 beers make a case. You could point to a keg of beer and say it contains 6.9 cases of beer, but in fact there are no cases of beer in it.

Computer memory and disk sectors, on the other hand actually have bytes in them.

It complicates the picture a bit, but there are plenty of complications.

Co-opting the word "byte" as a unit of measure does complicate the picture, and it doesn't make anything less confusing, because there are so many levels on which to count the bits. Most people would say it's fraudulent to say 5E9/8 bytes travel down this line every second, since less than 80% of that number end up as actual bytes in computer memory.

The only unambiguous measure you can give is the raw bit signalling rate. Try to get more real-world than that, and you have to get specific about which real world you mean.

Say what?

Posted Jun 12, 2009 20:31 UTC (Fri) by gilb (subscriber, #11728) [Link]

The 5 Gb/s is marketing speak, the real, raw data rate is 4 Gb/s. The PHY has 200 ns symbol time (5 Gsymbols/s) but encodes the data with 8b/10b, i.e., every 10 symbols on the wire corresponds to 8 bits of information.

If you rated 802.11a/g the same way it would be 72 Mb/s. The 54 Mb/s data rate uses a 3/4 coding, i.e., for every 3 bits input, you get 4 coded bits on the air. (4 us symbol time, 288 coded bits per symbol, 216 data bits per symbol.)

This sort of exaggeration seems to be becoming more common. I sometimes hear that HDMI 1.0 is 4.5 Gb/s, when it is really 3.6 Gb/s (TMDS encodes 8 bits for every 10 symbols as well).

The good news is that the 4 Gb/s is bi-directional, there are separate up and down link wires, as opposed to USB 1.0 and 2.0 in which the same wire and hence the available bandwidth is shared for up and down link.

The protocol for USB 2.0 is not particularly efficient either, which is part of what gives the much lower throughput for a single device. The aggregate throughput (i.e., with more than one device) can be higher. OTOH, the simplicity of the protocol makes endpoints cheap.

USB 3.0 looks to be a much more efficient protocol, so it is possible that the throughput improvement will be significant, aside from the improvement in the PHY rate.

Linux first to offer USB 3.0 driver (Linux Devices)

Posted Jun 12, 2009 1:28 UTC (Fri) by mikov (guest, #33179) [Link] (12 responses)

Oh good. Now all that is left to do is to fully support USB 2.0 and we are ready to enter the future.

USB 1.0 devices (namely USB->Serial converters) still don't work reliably when plugged into a 2.0 hub. I suppose now that we have glorious USB 3.0 support they will cease to function completely... I realize that I sound cynical and bitter, but that's because I am.

Linux first to offer USB 3.0 driver (Linux Devices)

Posted Jun 12, 2009 8:40 UTC (Fri) by walken (subscriber, #7089) [Link] (1 responses)

Try with CONFIG_USB_EHCI_TT_NEWSCHED=y

I can't figure out why this is not the default, though... :/

Linux first to offer USB 3.0 driver (Linux Devices)

Posted Jun 12, 2009 21:23 UTC (Fri) by mikov (guest, #33179) [Link]

I actually tried that right away and it didn't fix the problem. I haven't tested the latest kernel versions though, but they are not an option in my case anyway. It is a shame, because the same hardware works flawlessly in Windows (and I bet it even works in Windows 2000, which is how many years old?).

Linux first to offer USB 3.0 driver (Linux Devices)

Posted Jun 12, 2009 8:40 UTC (Fri) by dion (guest, #2764) [Link] (9 responses)

I'm willing to bet that the USB Serial converter problems all stem from the fact that there is no standard class for serial ports on USB, so everybody and their dog has to reinvent the serial device and not everybody does a good job of it.

I once worked with a keyspan usb serial adaptor, it was actually a general purpose 8 bit microcontroller that needed firmware uploaded via usb before it could do anything serial related.

Linux first to offer USB 3.0 driver (Linux Devices)

Posted Jun 12, 2009 21:28 UTC (Fri) by mikov (guest, #33179) [Link] (8 responses)

I don't think the problem is in the converter driver per-se. If thought it was I wouldn't be complaining; I would just use different hardware with a better driver. The problem is deep somewhere in the bowels of the USB subsystem.

In my experience the Keyspan adapters are the best, but they are not so easy to buy. Plus, Debian doesn't support them out of the box (which is not Keyspan's fault, but one of the very few cases in which Debian demonstrates fanatical stupidity).

Linux first to offer USB 3.0 driver (Linux Devices)

Posted Jun 13, 2009 8:09 UTC (Sat) by strcmp (subscriber, #46006) [Link] (7 responses)

I had assumed it is Keyspan who chooses the license of their firmware. How is following the license fanatic and stupid, where do you live?

Linux first to offer USB 3.0 driver (Linux Devices)

Posted Jun 13, 2009 10:00 UTC (Sat) by cortana (subscriber, #24596) [Link] (1 responses)

According to http://wiki.debian.org/KernelFirmwareLicensing#keyspan.28... the license is fine for non-free.

Is it?

Posted Jun 14, 2009 8:17 UTC (Sun) by khim (subscriber, #9252) [Link]

Permission is hereby granted for the distribution of this firmware image as part of a Linux or other Open Source operating system kernel in text or binary form as required.

I fail to see how it can be compatible with non-free distribution. It's not distributed as "part of Linux or other Open Source operating system kernel", it's distributed separately (the whole point of excercise is to strip non-free blobs from kernel and push them in separate packages) and so the text as written does not apply. The question if separate distribution for Linux not "as part" of a Linux is open as far as I can see.

Linux first to offer USB 3.0 driver (Linux Devices)

Posted Jun 13, 2009 16:26 UTC (Sat) by mikov (guest, #33179) [Link] (4 responses)

The firmware runs within the Keyspan device, not the Linux kernel. It might as well be in a flash in the device, but that would increase the cost.

So, yes, requiring that this firmware be open source, given that there don't even exist free tools to compile it, is idiotic. It has absolutely no benefit for anybody. It is the same as requiring the design schematics for supported devices to be open source.

Linux first to offer USB 3.0 driver (Linux Devices)

Posted Jun 13, 2009 16:47 UTC (Sat) by foom (subscriber, #14868) [Link] (3 responses)

It is the same as requiring the design schematics for supported devices to be open source.

I really wish this hadn't gone out of style. For the few devices I own that *do* have easily accessible electrical schematics and PCB layout images, it really makes a big difference to their repairability. It used to be standard practice to always provide schematics with electronics devices, but that doesn't seem to have translated into modern computer equipment.

Linux first to offer USB 3.0 driver (Linux Devices)

Posted Jun 13, 2009 17:11 UTC (Sat) by mikov (guest, #33179) [Link] (2 responses)

I agree 100% (although in practice SMT boards are probably very hard to repair).

But preventing the OS from running on non-free hardware?

Who prevents you from running the thing?

Posted Jun 14, 2009 8:08 UTC (Sun) by khim (subscriber, #9252) [Link] (1 responses)

But preventing the OS from running on non-free hardware?

If your hardware includes everything it needs - it can be considered black-box and used as such. If it needs something from an OS - this part should be hackable. Or else your OS includes some part which can not be supported (by Debian developers at least) - and Debian does not like it. Firefox was excluded from Debian using the same logic, it's not just about firmware.

Probably such blob can be put on web somewhere and then the device will only be supported till it's present on web? Also not a good idea: people will whine when device perfectly usable yesterday suddenly does not work. So the proper way, sadly, is to remove everything from distribution and give the end-user ability to download and install firmware. I think Debian work on the second part...

Who prevents you from running the thing?

Posted Jun 18, 2009 4:00 UTC (Thu) by BenHutchings (subscriber, #37955) [Link]

Yes, we are actively packaging non-free firmware so long as the licence clearly says we can do so. Unfortunately this does not seem to be the case for the Keyspan serial firmware, as the licence says:

Permission is hereby granted for the distribution of this firmware image as part of a Linux or other Open Source operating system kernel in text or binary form as required.

and we would be distributing separately from the kernel.

Linux first to offer USB 3.0 driver (Linux Devices)

Posted Jun 12, 2009 2:15 UTC (Fri) by balbir_singh (subscriber, #34142) [Link]

I wish the XHCI spec was open. No one can validate the driver without signing an agreement.Rant, Rant, Rant!

Linux first to offer USB 3.0 driver (Linux Devices)

Posted Jun 12, 2009 13:41 UTC (Fri) by Steve_Baker (guest, #265) [Link] (5 responses)

Although it maybe wasn't designed for it and its latencies and overhead
probably will significantly reduce performance from the stated specs, at
these speeds and with full-duplex support, it competes with Ethernet,
Fiberchannel and even Infiniband (at the very low end admittedly.) I can
easily see using USB 3.0 as a poor man's Infiniband replacement. If
future motherboards come with as many USB 3.0 ports as todays boards have
2.0 ports, then it would be trivial (and cheap?) to setup rack-level mesh
or star topologies or even small scale fully connected topologies. Should
hopefully at least give 10+Gbps Ethernet a kick in the pants.

Linux first to offer USB 3.0 driver (Linux Devices)

Posted Jun 12, 2009 14:52 UTC (Fri) by gevaerts (subscriber, #21521) [Link] (4 responses)

Full duplex doesn't mean symmetrical

Linux first to offer USB 3.0 driver (Linux Devices)

Posted Jun 12, 2009 17:36 UTC (Fri) by Steve_Baker (guest, #265) [Link] (3 responses)

That's true, but given that it's designed for things like hard drives,
where uploading to your hard drive is as important as downloading from it,
I think it's very likely the bandwidth is symmetrical. I have not read
anything to suggest it is otherwise at least.

Linux first to offer USB 3.0 driver (Linux Devices)

Posted Jun 12, 2009 18:31 UTC (Fri) by gevaerts (subscriber, #21521) [Link]

The bandwidth is, but it's still a strictly master-slave tree topology

Bandwidth is symmetrical, control is not

Posted Jun 12, 2009 18:38 UTC (Fri) by khim (subscriber, #9252) [Link] (1 responses)

I think it's very likely the bandwidth is symmetrical. I have not read anything to suggest it is otherwise at least.

Badwidth is symmetrical, but like all version of USB there are devices and there are hosts. PC is a host, HDD is device and some cams can be both (host when connected to printer, device when connected to PC). Since difference between host and device is fundamental you can not just connect two PCs via USB - you need connecting device. Device like this one can act as mediator, but all such devices have poor, unreliable and, most importantly, slow drivers and in general it makes USB unusable as network solution... Certainly not threat to Ethernet...

Bandwidth is symmetrical, control is not

Posted Jun 12, 2009 20:35 UTC (Fri) by Steve_Baker (guest, #265) [Link]

If the 3.0 controllers support the USB On The Go (OTG) extension, it might
not be a problem (although it may still require a special cable for
electrical reasons,) otherwise I suppose PC to PC USB would continue to
require a bridge chip. A bridge chip can probably be made decently fast,
but would still introduce latency. Since 3.0 allows for slave initiated
communications I suspect a bridge chip will be unnecessary. Furthermore
the spec seems to specify a special A to A cable for debugging and "other
host-to-host connection applications." I'm cautiously optimistic as it
really seems like 3.0 is taking on Firewire which has always had this
capability.

As far as the network topology goes, at the USB level it would just be a
point to point link, one end a host/master, the other a device/slave. The
mesh network wouldn't be handled at the USB protocol layer, but at a
higher layer.

I'm not saying it's going to work the way I'd like, just that it might,
I'm keeping my fingers crossed.