Performance question, MSC on STM32U5 / DWC2

[satirebird]

Hi,

I started a small test with tinyUSB on a STM32U5A5 evaluation board. Integration and compiling worked really well. The system has the following features:

• USB HS core
• FreeRTOS
• MSC device class
• (optional SD card)
• CFG_TUD_MSC_EP_BUFSIZE 32k
• CFG_TUD_DWC2_DMA_ENABLE 1

I made some performance tests. To check which effect is related to the SD card I made a dummy MSC interface returning all zeros. On the host side I used linux dd command for the tests. I got the following results.

Dummy interface:
Reading: 15 MBytes/s
Writing: 34 MBytes/s

SD-Card connected:
Reading: 8.5 MBytes/s
Writing: 12.2 MBytes/s

Writing is almost twice as fast as reading. Enable or disable DMA doesn't make much difference except that the IRQ rate drops significant when DMA is enabled.

Does anyone know why the reading speed is much slower than writing?

[HiFiPhile]

Hi,

What block size you used with dd ?

[satirebird]

I tried several values, 512, 1k, 4k, 32k, 1M. The difference is very little. (Except the write speed drops by choosing smaller chunks bs < 4k)

[satirebird]

I think that the turnaround time is significant.
For my understanding the, reading works as follows:

1. Host requests a chunk
2. IRQ sends a message to the tinyUSB task.
3. The task is scheduled by the OS and writes the data into the transfer buffer
4. The data is scheduled for USB transfer.

I think during the steps 2 and 3 the USB EP is stalled. This lost time results in a significant drop of the throughput.
I case of writing the USB hardware fifo can be filled with the next chunk from the host during the transfer to the tinyUSB task. In the end it works much faster.

But currently I don't know how I can test my assumption.

Are there any kind of double buffering mechanism in MSC?

[HiFiPhile]

I took out my STM32U5A5-NUCLEO and did a test:

• cdc_msc_freertos example (I'll push a fix when buffer size > 512 msc_disk.c)
• CFG_TUD_MSC_EP_BUFSIZE 32k
• DISK_BLOCK_NUM=512 (256KB disk)

With Mingw's dd 8k read I got 18.8MB/s without DMA and 23MB/s with DMA.

So I thought it could be something wrong in your side but anyway I booted into Linux to check (dd should be quicker run natively), guess what I got 14MB/s !

It turns out actual block read size is pretty random, especially with 512 bytes blocks command-status turnaround overhead is pretty high:

I tried different queue schedulers without success, maybe there are some USB mass storage specific tuneables.

I think during the steps 2 and 3 the USB EP is stalled. This lost time results in a significant drop of the throughput.
Are there any kind of double buffering mechanism in MSC?

TUSB tries to queue each USB transfer with maximum possible length, in case of DMA enabled there is no cpu intervention between 2 packets.
But at higher level there is no double buffer implemented.

You could be interested by #2967

[HiFiPhile]

I got good block size on dd with iflag=direct, but since my Linux laptop send USB IN token less often than my Windows PC, speed is not improved much. I'm afraid it can't be improved much by the device.

Hard working host, always tries to send IN token in time:

Lazy host: