Ethernet Speed is not sufficient in STM32F767

[vbk22398]

Presently we are using STM32F767ZI for our ongoing projects. Our application demands high speed data transfer rate through ethernet. We are taking the help of UDP for transfer of real time audio data between 2 STM32F767ZI Nucleo Boards. Further we need to increase the speed of Transmission and Reception of this audio data. So, we seek help for the following information among the community members.

1.

Presently, the HAL Drivers are in polling. Can we convert this HAL Drivers to utilize DMA? Would it make any difference in the speed of Tx and Rx.?

2.
How to increase the speed of LwIP Ethernet in STM32F767ZI? With/ Without DMA!
3.
What parameters decide the speed of data transfer in LwIP middleware that is there in the cube IDE?

[mbarg.1]

Let me try to help ... but you gave very little details on sw - post your code as full SMT32Cubeide project without debug files and we do not need to resort to glass ball ..

We dropped LwIP and moved to NetX as it already uses DMA, but I remember also Freertos had DMA; are you using any OS?

What speed are you looking for ? where you stand now? 

The main bottleneck we found is not in Ethernet MAC controller but in MCU processing power; try to run a flood of syn test and you can easily see that you will not be able to get all packets.

Wireshark acquisition can help to see what happens and where you need to work ...

 

[vbk22398]

---

@mbarg.1 wrote:

but I remember also Freertos had DMA; are you using any OS?

What speed are you looking for ? where you stand now? 

---

I am not using any O.S. It's a simple polling "udp send task" in while(1)/

I need the speed to be atleast 50mbps.

[mbarg.1]

DMA by sure can do it with H7 ( we do not have benchmark with F7) as raw interface BUT you will need a lot of work if you do not rely on some library.

With DMA, you can get a stream of packets with minimal sw interventions but then you must have an application capable of processing packets and packet pool - here packet size can be critical.

My approach; do not re-invent the wheel.

Even if some modifications to libraries are recommended if you play the performance vs code portablity and modularity.

Should you decide to use NetX, we can help.

[vbk22398]

@mbarg.1 
The code is as follows. Have posted both the Transmission and Reception code. If you need any more specifics, please let me know.


Thank You

[Andrew Neil]

Remember that the "Lw" in LwIP" stands for lightweight: so it is optimised for size - not for speed.

[Pavel A.]

@vbk22398 The Ethernet of STM32 already uses DMA. That is its own bus-mastering DMA, and it cannot work in any other way. The polling you see in examples polls for completion of transfer of one packet via that DMA.

Actually your question means, how to eliminate the polling and do something useful in parallel with ETH transfers, like queueing more TX packets or doing other work in parallel.

 

[vbk22398]

@Pavel A. I understand. Well, there are so many peripherals like UART,I2C,ADC, etc., They don't use DMA naturally or by default. Why, ethernet is having DMA by default and what is the need for the following.

---

@Pavel A. wrote:

@vbk22398 The Ethernet of STM32 already uses DMA. That is its own bus-mastering DMA, and it cannot work in any other way. The polling you see in examples polls for completion of transfer of one packet via that DMA. 

---

Why do we need DMA with Ethernet?

[Andrew Neil]

---

@vbk22398 wrote:

@Pavel A.  there are so many peripherals like UART, I2C, ADC, etc., They don't use DMA naturally or by default. Why, ethernet is having DMA by default 

---

I guess Ethernet is typically handling a lot more & faster data ...

[LCE]

I have used the F767 with lwIP, I think even with the HAL drivers (not using these anymore) the F767 reached 90 Mbit/s with TCP.

So check your code, especially the ETH register settings that set speed and duplex.

[vbk22398]

Increasing the audio samples in the udp packet increased the speed of the udp transmission. But it made the audio to be more noisy, choppy and didn't give the desired result and we compromised the speed and make some changes in how the audio data was processed. It worked and thanks to @Pavel A. @LCE @Andrew Neil @mbarg.1 for taking time to reply.

[LCE]

Don't forget that the other side (probably a windows PC?) can have some terrible latency, so we're using TCP for audio data transfer, with external RAM on the STM32 (H7) side to buffer at least 0.5 seconds of audio data (8 channels at fs = 200 kHz).

And yes, increase packet size to the maximum!

Concerning packet size: I found that my windows PC had a maximum TCP packet size set to only ~1200 bytes or so, that gave LWIP some extra work and time and reduced the data rate, so you might want to check that in the windows registry.

Check this:

Recommended TCP/IP settings for WAN links with a MTU size of less than 576 - Microsoft Support

Look for:

Method 3: Set the MTU size for the network interface manually