LWN: Comments on "Linux first to offer USB 3.0 driver (Linux Devices)"

Say what?

giraffedata — Sat, 20 Jun 2009 20:33:15 +0000

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?

giraffedata — Sat, 20 Jun 2009 20:17:01 +0000

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.

DE-9

giraffedata — Sat, 20 Jun 2009 20:07:21 +0000

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.

Who prevents you from running the thing?

BenHutchings — Thu, 18 Jun 2009 04:00:56 +0000

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.

Is it?

khim — Sun, 14 Jun 2009 08:17:00 +0000

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.

Who prevents you from running the thing?

khim — Sun, 14 Jun 2009 08:08:08 +0000

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...

Linux first to offer USB 3.0 driver (Linux Devices)

mikov — Sat, 13 Jun 2009 17:11:01 +0000

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

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

Linux first to offer USB 3.0 driver (Linux Devices)

foom — Sat, 13 Jun 2009 16:47:16 +0000

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)

mikov — Sat, 13 Jun 2009 16:26:53 +0000

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)

cortana — Sat, 13 Jun 2009 10:00:52 +0000

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

Linux first to offer USB 3.0 driver (Linux Devices)

strcmp — Sat, 13 Jun 2009 08:09:18 +0000

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)

mikov — Fri, 12 Jun 2009 21:28:37 +0000

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)

mikov — Fri, 12 Jun 2009 21:23:56 +0000

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?).

Say what?

gilb — Fri, 12 Jun 2009 20:39:33 +0000

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).

Let's stop at bytes per second

gilb — Fri, 12 Jun 2009 20:37:26 +0000

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

Bandwidth is symmetrical, control is not

Steve_Baker — Fri, 12 Jun 2009 20:35:25 +0000

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.

Say what?

gilb — Fri, 12 Jun 2009 20:31:25 +0000

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.

Let's stop at bytes per second

admcd — Fri, 12 Jun 2009 19:12:04 +0000

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.

Bandwidth is symmetrical, control is not

khim — Fri, 12 Jun 2009 18:38:02 +0000

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...

Linux first to offer USB 3.0 driver (Linux Devices)

gevaerts — Fri, 12 Jun 2009 18:31:16 +0000

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

Linux first to offer USB 3.0 driver (Linux Devices)

Steve_Baker — Fri, 12 Jun 2009 17:36:55 +0000

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.

Say what?

k8to — Fri, 12 Jun 2009 15:10:12 +0000

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

Linux first to offer USB 3.0 driver (Linux Devices)

gevaerts — Fri, 12 Jun 2009 14:52:38 +0000

Full duplex doesn't mean symmetrical

Four new wires

khim — Fri, 12 Jun 2009 14:17:57 +0000

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?

da4089 — Fri, 12 Jun 2009 14:15:36 +0000

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

Let's stop at bytes per second

sbergman27 — Fri, 12 Jun 2009 13:51:45 +0000

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?

DE-9

sbergman27 — Fri, 12 Jun 2009 13:45:36 +0000

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

Linux first to offer USB 3.0 driver (Linux Devices)

Steve_Baker — Fri, 12 Jun 2009 13:41:45 +0000

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.

Say what?

clugstj — Fri, 12 Jun 2009 13:22:38 +0000

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

Say what?

robert_s — Fri, 12 Jun 2009 12:39:56 +0000

"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.

Let's stop at bytes per second

khim — Fri, 12 Jun 2009 11:06:22 +0000

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...

Linux first to offer USB 3.0 driver (Linux Devices)

dion — Fri, 12 Jun 2009 08:40:36 +0000

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)

walken — Fri, 12 Jun 2009 08:40:06 +0000

Try with CONFIG_USB_EHCI_TT_NEWSCHED=y

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

DE-9

ncm — Fri, 12 Jun 2009 07:36:36 +0000

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.

Say what?

yootis — Fri, 12 Jun 2009 06:48:45 +0000

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?

shalem — Fri, 12 Jun 2009 06:40:06 +0000

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.

Linux first to offer USB 3.0 driver (Linux Devices)

balbir_singh — Fri, 12 Jun 2009 02:15:45 +0000

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)

mikov — Fri, 12 Jun 2009 01:28:40 +0000

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.

Say what?

sbergman27 — Thu, 11 Jun 2009 23:10:51 +0000

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.

Say what?

drag — Thu, 11 Jun 2009 22:51:58 +0000

* 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.