Hacker News Reader

Comment by jjoonathan | Hacker News Reader

Back when I wanted to do Computer Engineering, I more-than-skimmed-less-than-read the USB 1,2,3 specs and the PCIe 3 specs. The contrast was startling. The USB specs were a complete mess. The PCIe specs were not. This extended from the highest top level decisions (understanding the benefits of packet switched networks) to the lowest (missing figures, ambiguous and redundant terminology, etc).

Something was systematically different between the USB-IF and the PCI-SIG, and whatever it was persisted over many years... and likely continues to this very day, if outward appearances are any indication. If anybody has insight into what makes these groups different, or even just speculation, I'd love to hear it.

View on HN

That's not a very good comparison. USB covers up to the application layer, while PCIe is much more low level than that.

USB is a great standard. Or at least, was until 2.0. It was ahead of its time in performance and the same interoperability principles carried it forward for over 20 years. If you compare the first USB standards to other standards of the era, the amount of thought that has gone into it is fantastic. The fact it has no rivals even today is telling. Compare it to the clusterfuck that's Bluetooth, which took well over a decade to get to a point where its kinda reliable (and it can still vary between implementations).

Unfortunately USB became too complicated with the various modes and backward tidbits it now supports. Also, the rates it now supports have taken it to a whole new level of implementation complexity (ICs, board design, power options, etc).

> USB is a great standard. Or at least, was until 2.0. [...] Unfortunately USB became too complicated with the various modes and backward tidbits

Fortune had nothing to do with it.

USB's deliberations on packets were distinctly underdeveloped. PCI's were well developed. USB got it wrong. PCI got it right. The compatibility complexity explosion in USB and lack thereof in PCIe is a direct result.

This pattern continues across every single stratum of the standard that I dug into. Why?

(Every single stratum except the app layer. As you note, PCIe does not operate there and USB does.)

> It was ahead of its time in performance

I thought USB was always in the value segment and never competed on performance. That's the stated intent and that's what I remember: it was never the fastest external port on my computer.

> If you compare the first USB standards to other standards of the era, the amount of thought that has gone into it is fantastic.

My entire complaint compares it to PCIe and notes the comparative lack of thought.

> Compare it to the clusterfuck that's Bluetooth

Agreed, Bluetooth is worse. Maybe clusterfuck is the default state of affairs.

The question, then, is if there's anything to be learned from the USB/PCIe dichotomy. Is there an Engineering Steve Jobs keeping the PCI-SIG in line? Does it have fewer members? Is having one dimension on which you do not compete in the value segment critical to maintaining overall quality? I feel like there's a case study to be had, but I don't know enough to rank the causes or generalize with any certainty.

Parent post complained about "absurd naming conventions". Those were there in USB 2.0: Low, Full and Hi speed (and with USB 3.0, Super speed) are a source of pure confusion. The messaging regarding speed versus USB revision is confusing to the public as well. Bus versus Self powered is also inpenetrable terminology to anyone who hasn't read the specification.

There are also some dubious technical decisions, even in USB 2.0. Toggle bits -- sequence numbers that have been degenerated to a single bit -- are a frequent source of headaches for device implementors, but don't provide the intended integrity improvement. The VID/PID design seemed like a good idea in the USB 0.9 days, but it soon became clear that a large number of implementors would be making very different devices based on the same silicon, and the standard never evolved. Instead of developing a proper Battery Charging device class, USB-IF gave their seal of approval to the goofy schemes the wallwart manufacturers had come up with.

And "USB as she is spoke" is worse: high-power bus-powered devices claiming to the self-powered in their descriptors, Hi speed devices with ceramic resonators, hubs that source current into their upstream ports, devices with USB A receptacles and A male to A male cables, USB-RS232 bridges that require drivers despite the existence of the CDC ACM device class, crimped shield termination on A to B cables that will satisfy EMC standards at the time of manufacturing but not a month later when the cable reaches the consumer... all bearing the USB logo... and USB-IF does nothing to address any of these situations, only caring about getting their annual blood money from licensees.

> USB is a great standard. Or at least, was until 2.0. It was ahead of its time in performance and the same interoperability principles carried it forward for over 20 years.

Firewire was better

> Firewire was better

Firewire was faster but it wasn't better. It could only handle the minority usages (external storage), but not the majority ones (mice & keyboard - which were always wired back then).

Firewire also had hellish compatibility, whereas things like USB HID was amazingly plug & play in an era where that really didn't exist. And early on in Firewire's life it made the mistake of changing physical connector and not being backwards compatible.

> Firewire was faster but it wasn't better. It could only handle the minority usages (external storage), but not the majority ones (mice & keyboard - which were always wired back then).

I'm not sure why you say it could not handle mice and keyboards - pretty sure it could but just were never used for it due to license costs.

> Firewire also had hellish compatibility, whereas things like USB HID was amazingly plug & play in an era where that really didn't exist. And early on in Firewire's life it made the mistake of changing physical connector and not being backwards compatible.

I never experienced compatibility issues with it. The S800 standard was backwards compatible, sure they used different connectors but you could have passive cable that converted S800 port to S400 and plug that into a computer that only supported S400.

FireWire wasn't trying to support mice and keyboards. Nor was it trying to be all things to all users. It was trying to be an ultra-fast interface. And FireWire absolutely was backwards-compatible with an adapter. Still is. I never had any compatibility issues with FireWire.

Can you expand on that? IIRC it's not that simple, there are trade-offs for both solutions. Quoting wikipedia's Firewire article:

>USB requires the presence of a bus master, typically a PC, which connects point to point with the USB slave. This allows for simpler (and lower-cost) peripherals, at the cost of lowered functionality of the bus.

https://en.wikipedia.org/wiki/IEEE_1394#Comparison_with_USB

In the beginning, USB1/2 vs Firewire was a much clearer comparison.

Firewire could power a 2.5" spinning hard disk. (usb could not provide enough power)

You could hook two macs together with firewire, and turn one into a hard disk via target disk mode. (peer to peer)

Firewire could transfer video from cameras without dropping frames. (guaranteed bandwidth)

On the other hand, USB was always the cost king.

I believe there was a $1/chip royalty for firewire, and that limited its growth.

USB in practical terms has caught up.

The other difference was the Firewire did a lot more in that chip, basically offloading a lot of work from the CPU, so it was higher-performing and lower CPU usage.

USB was made mostly by Intel, and they intentionally made it "dumb" so that the CPU had more work to do, in order to push high-performance CPU chips. But of course, the big factor was that license cost, which made Firewire devices cost more, whereas USB was very cheap to implement.

Firewire sucked for simple low bandwidth devices like mice and keyboards though. Even though the connectors were about the same size it really was quite different from USB. Firewire was mostly about bulk data transfer and streaming. It was much more specialized than USB, and it's really not a surprise that it died off once USB got fast enough to do the same streaming, even if it wasn't as good at it.

> Firewire sucked for simple low bandwidth devices like mice and keyboards though.

Did it? I know it was not used for it but I think this was more because of the patent license cost and the relatively low cost of mice and keyboards which made the license cost of $1 a big chunk of the total cost.

> It was much more specialized than USB

Not sure what you mean by this, if you mean less mainstream, yes it was less mainstream, still better. Support for DMA, memory mapped devices, daisy-chaining, peer to peer. It really was revolutionary and still is.

There aforementioned PCI-Express is to some extent feels like "Firewire done right", mainly because the frame formats are strikingly similar. On the other hand, Firewire, like pre-3.0 USB, is not truly packed-switched, but uses shared bus with TDMA-ish timeslots (and the whole mechanism of arbitration and root-election is hellishly complex).

We're really going with a protocol that involves constant polling (rather than interrupts) as being ahead of its time? :)

The USB hardware "polls" by acting as a master. It's a master-slave protocol which is just fine for simplicity and bus utilization. The polling is abstracted from the software with the concept of hardware endpoints (mailboxes, really). How are you going to implement interrupts over a serial bus, unless it's multi-master (very complicated implementations, slow)? You don't have direct interrupt lines like in PCI.

I don't have a strong opinion on the topic (I never really bothered to look under the hood but from a purely user perspective USB has been quite serviceable for me so far) but I think you're begging the question:

>You don't have direct interrupt lines like in PCI.

Surely the people who've designed USB could have opted to add an interrupt signal if they had deemed it necessary. Sure it would've added one more signal but given that there were only 4 pins on the original USB it doesn't seem overwhelming.

That being said I agree with you that dismissing polling wholesale without digging deeper is quite silly, it can be a problem when it increases latency or wastes CPU cycles but as far as I know latency isn't much of an issue in most uses of USB (even for things like keyboards, mouses and controller it's usually dwarfed by the latency of the video pipeline) and I doubt anybody handles the USB phy in software so CPU usage shouldn't be a worry.

The whole point of USB is reduced wiring. Side channel interrupt would not have made sense.

"Polling" doesn't involves the host CPU, adds no latency. It is done by the USB controller, which sends poll packets to the device. This is all a philosophical decision by USB which is master/slave and doesn't support anything asynchronous by the slave.

The master can choose to ignore certain slaves on the bus if it desires, which isn't always possible with an asynchronous slave. Recall that many devices dangle off a single USB chain.

> it can be a problem when it increases latency or wastes CPU cycles

I think it wastes power. On a setup with interrupts, you could clock gate the host controller and if the device needs to say something it can raise the interrupt line and wake up the host. I don't think there's a way to clock gate a USB1 controller and then do e.g. wake on LAN.

PCIe does interrupts over a single serial lane just fine.

Conventional PCI can also do in-band interrupts (the mechanism is exactly same), but many devices do not support that.

The reason is that PCI is multi-master by design and PCIe uses duplex packet-switched serial links. There is no master who decides who gets to use the bus at given moment (for parallel PCI there is, but it is relatively simple circuit that is conceptually part of the bus itself, not of particular device connected to it).

Reply on news.ycombinator.com