very poor performances with video transfers

[EdoFranzi]

Hi all,
I am trying to send images from my board to my Mac.
My hardware: Portenta H7 (stm32H747 dual core @ 480-MHz) with the external PHY.
I simply modified the embedded example proposed in the package (video_capture).
In the configuration I set in this way (to used HS and ISO)

#define CFG_TUSB_MCU OPT_MCU_STM32H7
#define STM32H747xx 1
#define CFG_TUSB_OS OPT_OS_CUSTOM

#define BOARD_TUD_RHPORT 1
#define BOARD_TUD_MAX_SPEED OPT_MODE_HIGH_SPEED
#define CFG_TUD_MAX_SPEED. BOARD_TUD_MAX_SPEED

#define CFG_TUD_ENDPOINT0_SIZE 64

#define CFG_TUD_VIDEO 1
#define CFG_TUD_VIDEO_STREAMING 1

#define CFG_TUD_VIDEO_STREAMING_EP_BUFSIZE 256
#define CFG_TUD_VIDEO_STREAMING_BULK 0

#define CFG_EXAMPLE_VIDEO_READONLY
#define CFG_EXAMPLE_VIDEO_DISABLE_MJPEG

So, what I check the USB device on the Mac I can see that it uses 480-Mb/s

Now, I tried to send images of 752 x 480 pixels. The xfer is fine, I can see the images on my Mac, but the speed is really slow (about 2 images per second)!! So, the number of byte to send due to the image coding is 752 x 480 x 2 = 721920. As I have mentioned, I am able to send 2 images per second, that means, the channel allow ~ 1.5 MBits / second.

Of course, something is wrong. Does someone has suggestions? Maybe my settings are wrong and for any reasons I am using FS instead of HS. How to figureout the problem?

Best regards
Edo

[matsobdev]

I see some redundant point here:

 #define CFG_TUD_MAX_SPEED. <==(point ;) BOARD_TUD_MAX_SPEED

See cdc_dual_ports example, they say HS device needs a device qualifier. There are extra stuff inside usb_descriptors.c surrounded by:

#if TUD_OPT_HIGH_SPEED
// Per USB specs: high speed capable device must report device_qualifier and other_speed_configuration
...
#endif // highspeed

[EdoFranzi]

Hi, thank you for the advice. Sorry for the "." .... it was a copy/paste issue :-D. As you suggest, I will check the cdc_dual_port to see what is missed in my descriptor for HS operations.
Thank's

[EdoFranzi]

matsobdev, in the usb_descriptor.c of the video example the HS device_qualifier and other_speed_configuration are defined and activated by #if TUD_OPT_HIGH_SPEED. Now, the usb_descriptor.h contains a lot of definitions difficult to undestant for a non specialist. I guess that there are some other issues that make the performances so bad (FS ?)

[matsobdev]

Maybe try #define USE_ISO_STREAMING 1? No idea, but worth trying if that kind of transfer is dedicated for streaming. Oh, it is now as !CFG_TUD_VIDEO_STREAMING_BULK . So maybe CFG_TUD_VIDEO_STREAMING_BULK 1?

[EdoFranzi]

Hi matsobdev, thank you for the hint.
Unfortunately I tried both (iso & bulk).
In my tub_config I have

#define CFG_TUD_VIDEO_STREAMING_BULK 0

and in the usb_descriptor.c, I have

#define USE_ISO_STREAMING (!CFG_TUD_VIDEO_STREAMING_BULK)

So, iso is set. :-(

[matsobdev]

If you saying ISO, maybe cranking up CFG_TUD_VIDEO_STREAMING_EP_BUFSIZE 1024 will help?

[EdoFranzi]

Ahhh, not as good as I expected, but much better than before.
Now I send 752 x 480 x 2 = 721920bytes in 100ms. That means now I can send ~7 images/s (56-Mbits/s).
OK, with HS I had the hope to reach at least ~20 images/s (160-Mbits/s).
Maybe, with another hint from you, I can step-by-step reach my target.
Anyway, thank you :-)

[HiFiPhile]

Currently the USB IP (dcd_dwc2) used in STM32H7 doesn't has DMA support, so the speed is bottlenecked in High-Speed mode.

You can read benchmark details in #920, TLDR somebody got 4.5MB/s in echo test with a STM32F429 so about 9MB/s in one direction.

I'm working on DMA support in #2576

[EdoFranzi]

Hi all,
Much better news.
Now I am able to send 752 x 480 x 2 = 721920-Bytes in 44-ms. This correspond to 16.5-MByes/s (131-Mbits/s). I am approaching to my target of 160-Mbits/s :-) ...
To achieve this, I had to change from isochronous tu bulk (this is quite strange to me).
I also increased the endpoint size (#define CFG_TUD_VIDEO_STREAMING_EP_BUFSIZE 4096); not sure that this is allowed.

Concerning the DMA, for sure it will improve the full dynamic of the system; we can let the cpu do other tasks, but in term of speed of transfer, the cpus is as fast as the DMA (measured on stm32H743).
How do you plan to manage the cache coherency? Callbacks?

Any other suggestions to reach my 160-Mbits/s?
Edo

[matsobdev]

So BULK was the answer :D According to this: https://developerhelp.microchip.com/xwiki/bin/view/applications/usb/how-it-works/frame/ when there is no ISO, with BULK you can go much higher (reading RP2040 datasheet USB part, they say 48 MHz clock for USB so 4 cycles to get 1 symbol from USB PHY, so 1 MB = 1000000 B I suppose here, last so numbers will be lower). Only reasonable way now, according to Jeremy Clarkson would be more CFG_TUD_VIDEO_STREAMING_EP_BUFSIZE :D

Maybe not just more, but divide framebuffer evenly, so CFG_TUD_VIDEO_STREAMING_EP_BUFSIZE 9024 for example. Or more :D

[HiFiPhile]

To achieve this, I had to change from isochronous tu bulk (this is quite strange to me).

It's normal, ISO in HS can do 1 transfer per microframe (125us), thus 1024*8000 = 8MB/s, unless you use high-bandwidth endpoint.
For buck transfer in theory it can do 13 transfer of 512b thus 53MB/s.

Concerning the DMA, for sure it will improve the full dynamic of the system; we can let the cpu do other tasks, but in term of speed of transfer, the cpus is as fast as the DMA (measured on stm32H743).

To be clear I'm referring to DMA inside the USB IP, not system DMA controller. The overhead of ISR and packet copy are reduced.

• CPU is faster accessing TCM memory as the bus width is much wider(64b + 32b*2). However DMA controller can be much faster than CPU depending the configuration, as it can do burst transfer and occupy full bus bandwidth also reduce bus arbitration overhead. On SAME70 for external SDRAM access DMA can be 5x faster than memcpy()

How do you plan to manage the cache coherency? Callbacks?

It will be managed inside driver.

Any other suggestions to reach my 160-Mbits/s?

If you can't wait you can change to NXP MCU like LPC43, LPC55 or I.MX RT.

[kkitayam]

Current UVC implementation supports for FS sample format only. So, when isochronous endpoint is selected for video streaming interface, the bandwidth is up to 1 MBits/s even if the device is HS.

HS sample format is shown below.

FS sample format is shown below.

[EdoFranzi]

Hi all,
Thank you for this efficient discussion.
In a short:

1. For the moment, isochrone transfers are available only in FS
2. An efficient transfer speed is possible in HS with bulk and with large EP buffer CFG_TUD_VIDEO_STREAMING_EP_BUFSIZE 4096
3. DMA is on development

So, the speed problem can be mitigated with the point 2.
Other suggestions ?