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