Ethernet performance & packets loss

[ranran]

Hello,

We try to test our Ethernet performance (STM32H7).

We are using a udp echo with LWIP , and we inject udp packets from PC into STM32H7 .

The performance is OK with most packets, but when decreasing packet size below ~300bytes, we start to get packet lost.

My question is:

1. Is there a benchmark document for STM32H7 showing the expected performance for Ethernet ?
2. Is there a loopback application example using HAL APIs (without LWIP) ?

Thank you,

Ran

[Pavel A.]

Have you seen this thread?

[TDK]

The better way is to give up on Lwip and stm32’s hal ethernet libraries, both of which are maddeningly difficult to understand/debug, and use a wiznet chip instead. But if you’re stuck with those, good luck.

[Giuseppe Cannarella]

Hi ranran, I'm facing same issue... Have you solved? How?

Thanks

[ranran]

Hi,

I've been struglling with it for a long time actually.

We are using ethernet test equipment (so are you?) and we observe the same packet loss with EVAL board too !

I think that the chip has some HW limitation (but I won't get confirmation for this from ST...), it just can't handle ieee 802.3 standard packets ! That's quite bad.

Thanks for any idea

[Ozone · Accepted solution]

If you step back and widen your scope, you realize the same kind of question is raised on many MCU fora.

Hardly any MCU of this (Cortex M) class can keep up with real-world ethernet traffic, except in sterilized test environments.

MCUs must be <relatively> cheap to be successful. Ethernet OTOH requires a lot of offline buffer and core performance.

Just check the ethernet peripherals of Cortex A devices, or chips used for PCs. They use to store multiple packages, usually DMA-ed into the core memory space.

Most MCUs use to implement just enough to get it going. But after all, IoT is a marketing fad.

[Piranha]

Dear, @ranran​ , @TDK​ , @Ozone​ and everyone else interested in Ethernet!

Don't take it personal, but the idea, that Cortex-M class MCUs can't handle Ethernet and IP stack decently, is total nonsense, which unfortunately has proliferated STM32 and other communities. Typical Cortex-M3/M4 is more powerful than Intel 80486, which was able to handle Windows 95, and Cortex-M7 is on par with Pentium II. On a RAM side few tens of KB for Ethernet and IP stack buffers are more than enough for high-performance implementation and modern MCUs have much more internal RAM, not even talking about possibility of adding external one.

There are two main reasons leading to that false belief:

1. ST's drivers and lwIP integration in examples and CubeMX generated code. Everyone is just trying to use those, failing and blaming hardware, but nobody is reading reference manual and looking at the code. But that code is full of bugs, bloated and is inflexible because of idiotic architecture. In another words - total crap! And that is very polite way of describing it!
2. Long ago outdated understanding of Ethernet traffic distribution coming from the age of network hubs. Nowadays all Ethernet traffic is distributed by network switches, which learn MAC addresses and deliver frames only to the target device, not every device. Broadcast frames are exception, but in a normal real-world network those are transmitted from few times per minute to few times per second. Processing those is nothing for a Cortex-M class MCU.

Therefore, when the software is done right, Ethernet and lwIP on STM32 MCUs works spectacularly well! And to prove it to others, I've made a demonstration firmware:

https://community.st.com/s/question/0D50X0000AhNBoWSQW/actually-working-stm32-ethernet-and-lwip-demonstration-firmware

[Piranha]

STM32 HAL is buggy bloatware, but lwIP is pretty solid and stable. Look at my other post and demonstration firmware. WIZnet can't come even close to that performance, functionality and flexibility:

https://www.pjrc.com/arduino-ethernet-library-2-0-0/

[Mikhail Z]

Do you sell the code, or what is your idea behind not releasing it?

[ranran]

Hello Piranha (Community Member),

Thank you for sharing the demonstration.

I see that you tested it with iperf from another PC host.

We have tested performance using Ethernet test equipment.

1. I am not sure that PC iperf can reach ieee 802.3 required performance. The test equipment generate packets and interval between packets exactly according to ieee 802.3 requirement (the interval timing is accurate and we can not change it even if we want to).
2. Another things to note, is what is the packet length in your tests ? Did you try packets below ~150 bytes ?

Thank you!

ranran