Re: [libusb] Issues with low CDC_ACM throughput on STM32 USB-FS (sync/async)

[Jerri L. <Jer...@pr...>]

On 2024-04-23 Tim R. wrote:

Jerri Lipp via libusb-devel wrote:
>
> Undoubetdly true, though as it happens, I'm running this on an old
> junk box that is USB2/EHCI only, so that's not it at least in this case.
>
How old?  Many of the early non-Intel EHCI controllers were crap, and
had problems sustaining high bandwidths.

The motherboard uses an ICH9 chipset. at least 15 years old. I wrote about a laptop which is maybe 5 years old in my other reply. On ICH9, dd gets 960KB/s. on the newer laptop, only about 400KB/s.

On Friday, April 26th, 2024 at 6:45 AM, David Grayson <dav...@gm...> wrote:

> Yeah, it's probably going to turn out to be an issue on the STM32 side. If you want to make more progress, I'd recommend looking at the traffic with a hardware USB protocol analyzer like the Beagle USB 12 from Total Phase to see what's really going on.

I appreciate all the suggestions.

and I agree, since performance varies wildly between platforms, when using dd/linux driver, it's hardly likely that libusb is at fault. The common factor certainly looks to be the device.

I'm not ready to purchase new (even cheap) hardware to debug this. It's more of a mystery than a showstopper for me. I should note that a post on the ST community a week ago yielded no responses from anyone, ST or otherwise. Maybe I'm the only one experiencing this (Maybe I did something stupid with the code generator, I don't know).

On 2024-04-26 RisingEdgeIndustries <su...@ri...> wrote:

Also, check if you are double buffering your EPs

ST's USB middleware supports double-buffering and enabled by default. I verified that the proper IFDEF branch is taken during compilation.

Also, the issue is not that I'm not getting good throughput, but that in order to approach that 1MB/s mark I have to add phantom IN transfers on one computer, and (now that I've checked) that performance is actually worse on a much newer and more powerful laptop.

On 2024-04-26 michel <dia...@ya...> wrote:

You should get more than 500KB/Sec (up to some 800K) on pretty much any system  even using just synchronous request on PC side (use largest possible one).

That's good to know. However, "more than 500KB/s" is actually not that informative. I did get about 500KB/s with the sync API. however, the hardware is running at 150Mhz and is perfectly capable of achieving much higher throughout. The problem I described was that I wasn't getting better throughput even with (only) multiple large OUT transfers in fligh using the Async API. Throughput shot up to 960KB/s if I added a "useless" single one-time IN transfer at the start of the program on a very old computer. But on a much newer laptop, nothing helped and performance was even worse (though I should probably update the BIOS on it).

Try to tune the usb  h/w fifo to maximize the bulk in/out cdc data end point

Also if you have choice of using the FS or HS controller Pock the HS one even it operate at FS only (it still has much more fifo space)

umm... well, I tried all the ports, directly, via a USB2 hub, via xHCI on another system, via USB2 hub connected to the xHCI ports, to a USB-A port on the other system, to a USB-c port on the other system, etc' - the details vary, but it just doesn't seem like I'm getting sane behaviour overall. I've proven that the MCU can handle 960KB/s OUT, on a very old PC, so I expect to achieve that on every system if things are working properly.

Try to tune the usb  h/w fifo to maximize the bulk in/out cdc data end point .

The user-facing USB stack buffer size is maxed out at 64 bytes. and I twiddled with increasing transfer size, that makes no difference. The issue is that vague changes to the host side software/system halve/double the throughput.

Is there something specific, at the stm32 register level that you suggest I play with? I'm curious. Though at this point we're probably a bit off-topic for libusb-devel.

Thank you all for the suggestions.