4 ms·

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

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.

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.