3 ms·

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 ri

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
- marcan_42 5y ago
  > 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. You are misremembering. All 2.0 hubs have TTs. The question is whether they have one (same problem as USB3, all ports share a single 12Mbps pipe in 1.0 mode) or multiple (can aggregate multiple 12Mbps devices without bottlenecks). What USB3/4 have done is doom us to a world equivalent to multi-TT hubs not existing. Except it's worse because with single TT hubs, at least you can still chain multiple to a parent hub and aggregate without bottlenecks at that level. > Once we start adding isosynchronous profiles & perhaps various other usb2 gimmicks, I imagine the transaction translation problem becoming much more thorny Thorny, perhaps. Impossible, no. This is trivial to prove: sticking a PCI USB2 host controller behind a Thunderbolt/USB4 bridge works fine, and that is for all intents and purposes a USB2 to TB/PCIe "transaction translator", and PCIe itself is more like Ethernet and can be tunnelled over almost anything. The USB host transaction layer (which is a pretty 1:1 map to xHCI) is tunnelable just fine (this is how USB over the network protocols work too, with host support). It's the wire layer that isn't, because once you drop to that layer you can't reconstruct or control the original transaction states properly. What USB2 did for TTs is extend the protocol in such away that the missing information/cases could be handled properly, with cooperation from the host. There's no reason why they couldn't have done this for USB2 to 3 too. > Making a hub that passes through usb4, but which also exposes a variety of simple peripherals is much easier without mandating the transaction translator. As I said, they could still keep the USB 2 lines. Having TT support in the standard doesn't mean hubs have to implement it. We'd still have the differentiation between TT-ful and TT-less hubs if you want. The problem is, right now, TT-ful USB3 hubs aren't possible. I agree that having the 2.0 lane in Type C makes a ton of sense. Just let me tunnel it over the SS lanes too! Source: I've written USB support for projects way too often, including a bare-bones OHCI driver once. I also authored the virtual xHCI implementation in qemu.

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

marcan_42 5y ago
> 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. You are misremembering. All 2.0 hubs have TTs. The question is whether they have one (same problem as USB3, all ports share a single 12Mbps pipe in 1.0 mode) or multiple (can aggregate multiple 12Mbps devices without bottlenecks). What USB3/4 have done is doom us to a world equivalent to multi-TT hubs not existing. Except it's worse because with single TT hubs, at least you can still chain multiple to a parent hub and aggregate without bottlenecks at that level. > Once we start adding isosynchronous profiles & perhaps various other usb2 gimmicks, I imagine the transaction translation problem becoming much more thorny Thorny, perhaps. Impossible, no. This is trivial to prove: sticking a PCI USB2 host controller behind a Thunderbolt/USB4 bridge works fine, and that is for all intents and purposes a USB2 to TB/PCIe "transaction translator", and PCIe itself is more like Ethernet and can be tunnelled over almost anything. The USB host transaction layer (which is a pretty 1:1 map to xHCI) is tunnelable just fine (this is how USB over the network protocols work too, with host support). It's the wire layer that isn't, because once you drop to that layer you can't reconstruct or control the original transaction states properly. What USB2 did for TTs is extend the protocol in such away that the missing information/cases could be handled properly, with cooperation from the host. There's no reason why they couldn't have done this for USB2 to 3 too. > Making a hub that passes through usb4, but which also exposes a variety of simple peripherals is much easier without mandating the transaction translator. As I said, they could still keep the USB 2 lines. Having TT support in the standard doesn't mean hubs have to implement it. We'd still have the differentiation between TT-ful and TT-less hubs if you want. The problem is, right now, TT-ful USB3 hubs aren't possible. I agree that having the 2.0 lane in Type C makes a ton of sense. Just let me tunnel it over the SS lanes too! Source: I've written USB support for projects way too often, including a bare-bones OHCI driver once. I also authored the virtual xHCI implementation in qemu.