4 ms·

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, w

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

cjbprime 7y ago
We're really going with a protocol that involves constant polling (rather than interrupts) as being ahead of its time? :)
- flyinglizard 7y ago
  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.
  - simias 7y ago
    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.
    - bravo22 7y ago
      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.
    - cjbprime 7y ago
      > 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.
  - mzs 7y ago
    PCIe does interrupts over a single serial lane just fine.
    - dfox 7y ago
      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).
ailideex 7y ago
> 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
- simias 7y ago
  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 https://en.wikipedia.org/wiki/IEEE_1394#Comparison_with_USB
  - m463 7y ago
    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.
    - magduf 7y ago
      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.
- jandrese 7y ago
  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.
jjoonathan 7y ago
> 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.
spancap 7y ago
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.
- dbuder 7y ago
  Full and High speed really did confuse consumers and still confuses product designers. Throw in some OTG too. I design stuff that uses type A to type A cables, how else am I supposed to make it work with stuff that has micro/mini/B/C ports? tell my prospective users to buy adapters? Then again, I'm not writing USB on my devices or paying their fee.

cjbprime 7y ago

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

flyinglizard 7y ago
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.
- simias 7y ago
  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.
  - bravo22 7y ago
    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.
  - cjbprime 7y ago
    > 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.
- mzs 7y ago
  PCIe does interrupts over a single serial lane just fine.
  - dfox 7y ago
    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).

ailideex 7y ago

> 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

simias 7y ago
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 https://en.wikipedia.org/wiki/IEEE_1394#Comparison_with_USB
- m463 7y ago
  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.
  - magduf 7y ago
    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.
jandrese 7y ago
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.

jjoonathan 7y ago

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

spancap 7y ago

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.

dbuder 7y ago
Full and High speed really did confuse consumers and still confuses product designers. Throw in some OTG too. I design stuff that uses type A to type A cables, how else am I supposed to make it work with stuff that has micro/mini/B/C ports? tell my prospective users to buy adapters? Then again, I'm not writing USB on my devices or paying their fee.