4 ms·

I always bring this up in the hope that it's seen by someone that has deep knowledge on the subject. The Raspberry Pi's USB 2.0 implementation seems to be horri

I always bring this up in the hope that it's seen by someone that has deep knowledge on the subject. The Raspberry Pi's USB 2.0 implementation seems to be horribly inefficient. An RTL-SDR uses over 40% of a CPU core on a Pi 4 just doing USB transfers. It's less than 5% on a typical laptop, as well as on other aarch64 SoMs such as Nvidia Xavier. What's going on? Is the peripheral itself just really cheesy? Is the driver not using DMA when it could be?

sitzkrieg 4y ago
welcome to raspberry pi hardware. the usb bus has been problematic since the beginning. i thought the 4s better but it still seems off, but not sure why
- kelnos 4y ago
  I would assume the USB3 ports on the 4 would be better, as they go through a dedicated USB controller connected to the PCIe bus. The USB2 ports are provided by the SoC itself, and that controller is not the best.
  - sgtnoodle 4y ago
    Indeed, that would certainly make sense. I've wondered if this device would do significantly better or create its own problems. https://hackaday.com/2022/03/07/a-chip-to-address-the-fundamental-usb-3-0-deficiency/ https://hackaday.com/2022/03/07/a-chip-to-address-the-fundam...
    - amstan 4y ago
      While that's a cool chip, it doesn't really apply here. USB2.0 ports on the RPI4 only have 2.0 lines (from DWC2 inside the SOC). USB3.0 ports on the RPI4 have both 2.0 and 3.0 lines going to it (both sets of lines for this port coming from the same place: the pcie connected usb controller). Even though both of the above ports come with 2.0 lines, they're quite different in how they're implemented. The chip you linked would be useful if that pcie controller didn't come with 2.0 connections.
      - sgtnoodle 4y ago
        Ah, cool. This is great info. I just assumed the 2.0 lines would have gone to the SoC still. I'll have to measure the CPU load again and make sure I'm plugged in to a blue port.
amstan 4y ago
The USB2.0 ports are driven by an ip block called dwc2. It's always been a potato. I suppose it was designed for ancient phones that mainly needed it to be as device(aka gadgets) to other usb hosts (eg: a phone connected to a computer, where dwc2 was inside a phone), it just happened that it had this feature called OTG (which is a fancy way to say you can reverse the data direction, so you have host capabilities as well). Because these host capabilities were an after thought (pretty much designed only for flash drives at most) for a niche feature of a phone, it wasn't ever implemented properly. Another fun thing that happens is that a lot of DWC2's functionality has to be delegated to software instead of the fast hardware. In USB the host needs to send out a packet toward to devices every 1ms. In other USB implementations this happens in the background, driver/kernel doesn't even get notified about it until there's something interesting to do. In DWC2, every 1ms the driver has to do some work, I think it even has to handle 8 interrupts per 1ms. You'll notice that whenever you have any usb device connected, and you `cat /proc/interrupts` you'll probably see a steady increase of 8000/second, this is not normal. On higher speed hardware like the rk3288, DWC2 doesn't use that much CPU, but for the lower power RPI cpu, this is a significant amount.

sitzkrieg 4y ago

welcome to raspberry pi hardware. the usb bus has been problematic since the beginning. i thought the 4s better but it still seems off, but not sure why

kelnos 4y ago
I would assume the USB3 ports on the 4 would be better, as they go through a dedicated USB controller connected to the PCIe bus. The USB2 ports are provided by the SoC itself, and that controller is not the best.
- sgtnoodle 4y ago
  Indeed, that would certainly make sense. I've wondered if this device would do significantly better or create its own problems. https://hackaday.com/2022/03/07/a-chip-to-address-the-fundamental-usb-3-0-deficiency/ https://hackaday.com/2022/03/07/a-chip-to-address-the-fundam...
  - amstan 4y ago
    While that's a cool chip, it doesn't really apply here. USB2.0 ports on the RPI4 only have 2.0 lines (from DWC2 inside the SOC). USB3.0 ports on the RPI4 have both 2.0 and 3.0 lines going to it (both sets of lines for this port coming from the same place: the pcie connected usb controller). Even though both of the above ports come with 2.0 lines, they're quite different in how they're implemented. The chip you linked would be useful if that pcie controller didn't come with 2.0 connections.
    - sgtnoodle 4y ago
      Ah, cool. This is great info. I just assumed the 2.0 lines would have gone to the SoC still. I'll have to measure the CPU load again and make sure I'm plugged in to a blue port.

amstan 4y ago

The USB2.0 ports are driven by an ip block called dwc2. It's always been a potato. I suppose it was designed for ancient phones that mainly needed it to be as device(aka gadgets) to other usb hosts (eg: a phone connected to a computer, where dwc2 was inside a phone), it just happened that it had this feature called OTG (which is a fancy way to say you can reverse the data direction, so you have host capabilities as well). Because these host capabilities were an after thought (pretty much designed only for flash drives at most) for a niche feature of a phone, it wasn't ever implemented properly. Another fun thing that happens is that a lot of DWC2's functionality has to be delegated to software instead of the fast hardware. In USB the host needs to send out a packet toward to devices every 1ms. In other USB implementations this happens in the background, driver/kernel doesn't even get notified about it until there's something interesting to do. In DWC2, every 1ms the driver has to do some work, I think it even has to handle 8 interrupts per 1ms. You'll notice that whenever you have any usb device connected, and you `cat /proc/interrupts` you'll probably see a steady increase of 8000/second, this is not normal. On higher speed hardware like the rk3288, DWC2 doesn't use that much CPU, but for the lower power RPI cpu, this is a significant amount.