4 ms·

usb4 still preserves a legacy usb2 connection pair. on the one hand it's kind of absurd. on the other, a long distance capable, supported everywhere wire proto

usb4 still preserves a legacy usb2 connection pair. on the one hand it's kind of absurd. on the other, a long distance capable, supported everywhere wire protocol is great to be able to assume. displayport's aux channel is a great example of why keeping legacy connectivity around on a second track: it makes lowhgrade kvm like connectivity ultra easy & low cost. it's, ultimately, a pretty good thing that the 480mbit/s pipe is available for use by cheap & common devices. i dont see what else we could do. (aside from mandate that each usb-4 hub integrate a usb-2 over usb-4 adapter like this on each port, which probably makes sense, but also probably would be uncertifiable, would be likely to cause some random device misbeaviors... whitequark will probably have found a dozen random constraints by the end of the week to this chip.)

kevin_thibedeau 5y ago
This behavior is already done to translate 1.5 and 12Mbps packets into 480Mbps. USB 1.1 didn't do that and 1.5Mbps data effectively stole bus time from higher speed traffic.
mikepurvis 5y ago
How wild is it that 480 Mbit/sec is low speed and low cost? Like, it makes sense on one level, but it's just crazy to me how fast that still is compared with PS2 (16kbps), RS232 (115kbps), CANbus (1Mbps), USB 1.1 (12Mbps), 10/100 Ethernet (100Mbps), Firewire (400Mbps). Obviously totally inadequate once you're talking to solid state storage or if there's video/display data in the mix. But still... 480Mbps is fast.
MayeulC 5y ago
> displayport's aux channel is a great example of why keeping legacy connectivity around on a second track: it makes lowhgrade kvm like connectivity ultra easy & low cost On this topic, I wish it was used a bit more. What do you mean with that? Do you actually tunnel keyboard and mouse data trough that aux channel? I am not aware of it being supported by any OS? Or are you only referring to DCC data, using it to switch inputs? (Which you can also do on HDMI and VGA screens). If there is any alternative to HDMI CEC on the DisplayPort side, I'm all ears. That and standardized audio support are features where HDMI currently stands out, IMO.
Dylan16807 5y ago
That kind of mess, but worse, is what thunderbolt used to do. It would cut off USB signals (2 and 3) when the port switched modes, and downstream USB support depended on pcie->usb chips. https://www.reddit.com/r/UsbCHardware/comments/mjz2pu/usb4_architectural_explainer_usb4s_and/ https://www.reddit.com/r/UsbCHardware/comments/mjz2pu/usb4_a...
- marcan_42 5y ago
  That's better, because with the PCIe layer and a real host controller on the dock/hub, you finally get 480Mbps per port for USB downstream devices. Thunderbolt hubs are the only standards-compliant way to do this, today. USB4 with native USB3 tunneling but no native USB2 tunneling is a regression over TB3, and as silicon switches from the TB3 way to the USB4 way with native tunneling, we're now bringing back this problem, all thanks to the USB-IF's incompetence at designing standards. There is absolutely no reason for USB3 and USB4 not to support USB2 encapsulation/transaction translation the same way USB2 did with USB1.
  - Dylan16807 5y ago
    > That's better, because with the PCIe layer and a real host controller on the dock/hub, you finally get 480Mbps per port for USB downstream devices. The hypothetical I was comparing against when I said 'worse' was also delivering 480Mbps per port. The reason I say worse is because this chip converts USB to USB, while those hubs did PCIe to USB, which is much more complicated and a security hazard and doesn't work on many devices. It wasn't about the merits of tunneling as a general idea. Also do thunderbolt hubs have a controller per port? Not just one per hub?
    - marcan_42 5y ago
      A single USB xHCI controller is not bottlenecked to 480Mbps globally, since the multiple ports aren't actually sharing a 2.0 physical layer. The "root hub" isn't like a normal hub in that sense. So you don't need a controller per port, as long as the controller is designed to support this. Quoting the xHCI spec: > In past generations of USB host controller implementations, there was a 1:1 correspondence between a host controller interface and USB bandwidth. The xHCI diverges from this model in that it enables vendors to tailor the bandwidth available through its root hub ports to the needs of the vendor’s target application space. The xHCI can support the legacy model where the bandwidth of a single USB is shared across all its root hub ports, a “bus per port” model where the full bandwidth of a USB is available on every root hub port, or any combination in between. I believe most real 3.0 implementations do it per port, or at least have a bunch of instances, because it doesn't really make any sense to do otherwise. You're not really saving much money by somehow having a global bottleneck equal to the PHY bandwidth. Of course, it's possible for the controller to be bottlenecked upstream in some other way (e.g. by DMA bandwidth), but it would be very weird to find an xHCI controller with a single 480Mbps domain for all 2.0 ports IMO.
marcan_42 5y ago
What USB-IF should have done is specify USB3 to USB2 and USB4 to USB2 transaction translation, like they did for USB2->USB1. It doesn't mean they need to get rid of the USB2 wires, but it means utilizing the 5Gbps+ USB3 bandwidth to host multiple downstream USB2 devices without bottlenecks would be at least possible, and you can always fall back to USB2 hub mode if USB3 is not available. By refusing to make that part of the spec, they have doomed us to always being limited to a total of 480Mbps per host port for USB2 devices, no matter what you do or how many you have sharing it, whether that host port is USB3 or USB4 (unless you use PCI mode). That is ridiculous.
- rektide 5y ago
  Hello dear masterworker of systems. I reply humbly here- as a neophyte to a master- when I suggest, maybe possibly, perhaps, it could be really really hard to specify & guarantee exactly how to ensure that usb2 capability would be entirely, 100%, assuredly unaffected by a usb translation layers. I also think it eases certain design systems constraints. I'm not an expert. The evidence that USB2 was able to translate & carry usb1 is a good counter example to my premise, that the work was done & it worked out fine, and usb1 carries fine over usb2. For a while, I do not believe the USB transaction translator[1] was not totally commonplace: I remember articles specifically highlighting which usb2 hubs had this feature. I dont remember this feature ever causing compatibility problems, but USB1 had such a small feature profile, such limited concerns that it feels like this task was more managable. Once we start adding isosynchronous profiles & perhaps various other usb2 gimmicks, I imagine the transaction translation problem becoming much more thorny; I imagine trying to insure in fact that usb1, usb2, usb3 devices would all translate successfully would be much harder. I'm sympathetic in extreme to the notion that there should be a spec, that we should have tried to define something (and perhaps the specification without mandate would have been great, as usb2 did). But I also still feel like it would/could have been a risk, could have become thorny. That doubt doesn't convince me, but I want to acknowledge that doubt. I also think there is some modest technical advantages. Making a hub that passes through usb4, but which also exposes a variety of simple peripherals is much easier without mandating the transaction translator. It's super convenient to make a hub that passes through usb3/4 but which offers a variety of audio, keyboard, mouse, et-cetera connecitivyt options, at a reduced speed: one can just drop down some cheap-as-dirt usb2 hubs in their solution & glue in those worlds of peripehrals. Demanding all connectivity happen over usb4 & usb4 alone would have mandates much much more expensive solutions. That said, I'm not convinced the savings are worth the cost. If we simply had mandated we do good, build better, I suspect over time we would have found the cost of doing better to be negligible. [1] https://en.wikipedia.org/wiki/USB_hub#Transaction_translator https://en.wikipedia.org/wiki/USB_hub#Transaction_translator

kevin_thibedeau 5y ago

This behavior is already done to translate 1.5 and 12Mbps packets into 480Mbps. USB 1.1 didn't do that and 1.5Mbps data effectively stole bus time from higher speed traffic.

mikepurvis 5y ago

How wild is it that 480 Mbit/sec is low speed and low cost? Like, it makes sense on one level, but it's just crazy to me how fast that still is compared with PS2 (16kbps), RS232 (115kbps), CANbus (1Mbps), USB 1.1 (12Mbps), 10/100 Ethernet (100Mbps), Firewire (400Mbps). Obviously totally inadequate once you're talking to solid state storage or if there's video/display data in the mix. But still... 480Mbps is fast.

MayeulC 5y ago

> displayport's aux channel is a great example of why keeping legacy connectivity around on a second track: it makes lowhgrade kvm like connectivity ultra easy & low cost On this topic, I wish it was used a bit more. What do you mean with that? Do you actually tunnel keyboard and mouse data trough that aux channel? I am not aware of it being supported by any OS? Or are you only referring to DCC data, using it to switch inputs? (Which you can also do on HDMI and VGA screens). If there is any alternative to HDMI CEC on the DisplayPort side, I'm all ears. That and standardized audio support are features where HDMI currently stands out, IMO.

Dylan16807 5y ago

That kind of mess, but worse, is what thunderbolt used to do. It would cut off USB signals (2 and 3) when the port switched modes, and downstream USB support depended on pcie->usb chips. https://www.reddit.com/r/UsbCHardware/comments/mjz2pu/usb4_architectural_explainer_usb4s_and/ https://www.reddit.com/r/UsbCHardware/comments/mjz2pu/usb4_a...

marcan_42 5y ago
That's better, because with the PCIe layer and a real host controller on the dock/hub, you finally get 480Mbps per port for USB downstream devices. Thunderbolt hubs are the only standards-compliant way to do this, today. USB4 with native USB3 tunneling but no native USB2 tunneling is a regression over TB3, and as silicon switches from the TB3 way to the USB4 way with native tunneling, we're now bringing back this problem, all thanks to the USB-IF's incompetence at designing standards. There is absolutely no reason for USB3 and USB4 not to support USB2 encapsulation/transaction translation the same way USB2 did with USB1.
- Dylan16807 5y ago
  > That's better, because with the PCIe layer and a real host controller on the dock/hub, you finally get 480Mbps per port for USB downstream devices. The hypothetical I was comparing against when I said 'worse' was also delivering 480Mbps per port. The reason I say worse is because this chip converts USB to USB, while those hubs did PCIe to USB, which is much more complicated and a security hazard and doesn't work on many devices. It wasn't about the merits of tunneling as a general idea. Also do thunderbolt hubs have a controller per port? Not just one per hub?
  - marcan_42 5y ago
    A single USB xHCI controller is not bottlenecked to 480Mbps globally, since the multiple ports aren't actually sharing a 2.0 physical layer. The "root hub" isn't like a normal hub in that sense. So you don't need a controller per port, as long as the controller is designed to support this. Quoting the xHCI spec: > In past generations of USB host controller implementations, there was a 1:1 correspondence between a host controller interface and USB bandwidth. The xHCI diverges from this model in that it enables vendors to tailor the bandwidth available through its root hub ports to the needs of the vendor’s target application space. The xHCI can support the legacy model where the bandwidth of a single USB is shared across all its root hub ports, a “bus per port” model where the full bandwidth of a USB is available on every root hub port, or any combination in between. I believe most real 3.0 implementations do it per port, or at least have a bunch of instances, because it doesn't really make any sense to do otherwise. You're not really saving much money by somehow having a global bottleneck equal to the PHY bandwidth. Of course, it's possible for the controller to be bottlenecked upstream in some other way (e.g. by DMA bandwidth), but it would be very weird to find an xHCI controller with a single 480Mbps domain for all 2.0 ports IMO.

marcan_42 5y ago

What USB-IF should have done is specify USB3 to USB2 and USB4 to USB2 transaction translation, like they did for USB2->USB1. It doesn't mean they need to get rid of the USB2 wires, but it means utilizing the 5Gbps+ USB3 bandwidth to host multiple downstream USB2 devices without bottlenecks would be at least possible, and you can always fall back to USB2 hub mode if USB3 is not available. By refusing to make that part of the spec, they have doomed us to always being limited to a total of 480Mbps per host port for USB2 devices, no matter what you do or how many you have sharing it, whether that host port is USB3 or USB4 (unless you use PCI mode). That is ridiculous.

rektide 5y ago
Hello dear masterworker of systems. I reply humbly here- as a neophyte to a master- when I suggest, maybe possibly, perhaps, it could be really really hard to specify & guarantee exactly how to ensure that usb2 capability would be entirely, 100%, assuredly unaffected by a usb translation layers. I also think it eases certain design systems constraints. I'm not an expert. The evidence that USB2 was able to translate & carry usb1 is a good counter example to my premise, that the work was done & it worked out fine, and usb1 carries fine over usb2. For a while, I do not believe the USB transaction translator[1] was not totally commonplace: I remember articles specifically highlighting which usb2 hubs had this feature. I dont remember this feature ever causing compatibility problems, but USB1 had such a small feature profile, such limited concerns that it feels like this task was more managable. Once we start adding isosynchronous profiles & perhaps various other usb2 gimmicks, I imagine the transaction translation problem becoming much more thorny; I imagine trying to insure in fact that usb1, usb2, usb3 devices would all translate successfully would be much harder. I'm sympathetic in extreme to the notion that there should be a spec, that we should have tried to define something (and perhaps the specification without mandate would have been great, as usb2 did). But I also still feel like it would/could have been a risk, could have become thorny. That doubt doesn't convince me, but I want to acknowledge that doubt. I also think there is some modest technical advantages. Making a hub that passes through usb4, but which also exposes a variety of simple peripherals is much easier without mandating the transaction translator. It's super convenient to make a hub that passes through usb3/4 but which offers a variety of audio, keyboard, mouse, et-cetera connecitivyt options, at a reduced speed: one can just drop down some cheap-as-dirt usb2 hubs in their solution & glue in those worlds of peripehrals. Demanding all connectivity happen over usb4 & usb4 alone would have mandates much much more expensive solutions. That said, I'm not convinced the savings are worth the cost. If we simply had mandated we do good, build better, I suspect over time we would have found the cost of doing better to be negligible. [1] https://en.wikipedia.org/wiki/USB_hub#Transaction_translator https://en.wikipedia.org/wiki/USB_hub#Transaction_translator