Repository navigation
FreeRTOS port: HTTP latency ~1 s with default poll delay #190
Description
Hi,
Environment
- MCU: STM32H7S7L8H6H (Cortex-M7, caches enabled), PHY LAN8742 (RMII)
- Driver:
stm32_hal_ethfrom wolfIP, HAL ETH,ETH_RX_DESC_CNT = 4 - RTOS: FreeRTOS via CMSIS-RTOS2, tick = 1000 Hz,
- wolfIP v1.1.0, static IP 192.168.1.200, Windows PC as client on the same LAN
- Other tasks: MQTT client (wolfMQTT + wolfSSL, TLS 1.3)
config.h:LINK_MTU 1536,MAX_TCPSOCKETS 6,RXBUF_SIZE/TXBUF_SIZE4 KB- HTTP server:
httpd_init(&httpd, ipstack, 80, NULL)+httpd_register_static_page()(tiny static page)
Problem
A new TCP connection per request (curl in a loop, 10 iterations) shows very irregular latency on a local LAN:
- min 46 ms, max 2370 ms, median 1217 ms, P95 1964 ms
- most values are around 500 ms, 1000 ms or 1400 ms, which look like TCP retransmission timers
Wireshark shows frames that the stack never seems to see (a SYN, the ACK of a FIN, a GET right after the handshake ACK), followed by retransmissions after 250 ms or 1 s:
3.0895 .200 -> .95 [Retransmission] FIN, ACK (+1 s)
3.0989 .95 -> .200 [Retransmission] SYN (+1 s)
3.1217 .95 -> .200 GET / HTTP/1.1 (no response)
3.3634 .95 -> .200 [Retransmission] GET (+240 ms)
3.3660 .200 -> .95 [ACK] + response (2.6 ms after the retransmission)
Even in the good case, SYN-ACK takes ~22 ms and the GET answer ~64 ms.
What I found
- With a plain busy loop (no FreeRTOS wrapper, no MQTT task):
latency is about 1 ms and I see no retransmissions.
while (1) { wolfIP_poll(ipstack, HAL_GetTick()); }
- With the FreeRTOS wrapper (
src/port/freeRTOS) and default settings (WOLFIP_FREERTOS_POLL_MAX_MS 5u), latency is about 1 s. - Setting both
WOLFIP_FREERTOS_POLL_MAX_MSandWOLFIP_FREERTOS_POLL_MIN_MSto1udivides the latency by about 10.
Questions
- [Is
wolfip_freertos_notify_from_isr()expected to be called fromHAL_ETH_RxCpltCallbackin the STM32 port? I could not find a call in the project.] If it is, a 5 ms maximum delay should not matter, so it may be worth documenting or enabling by default. Tested with it and 5msWOLFIP_FREERTOS_POLL_MAX_MSand i got a 20ms delay in http - What
ETH_RX_DESC_CNTand poll task priority do you recommend with the FreeRTOS wrapper?
Thanks!
Metadata
Metadata
Assignees
Labels
No labels
Activity
dgarske commentedon Nov 10, 2026
Hi @Hamady91 , I am working on this issue. We don't officially support the STM32H7S7L8H6H from what I can see. Did you have to make any other porting or code changes to get that working on the H7S? Can you tell me more about your project and use of wolfIP? Also can you confirm that you are using the fixes in #180 ?
Thanks, David Garske, wolfSSL
Hamady91 commentedon Nov 10, 2026
Hi @dgarske
I had zero things to change from the library to make it compatible with the H7RS series . I only used the define STM32H7 in config.h
It seems that the ethernet IP is the same than H7 that you already support.
The plan for our use is to have a https server + mqtts . And the need of a reliable and simple library made me use wolf ip + wolf ssl.
I can't go deeper in details due to the confidentiality of the project
Concerning the fixes i will check this quickly but everything came from the realese of the V1.1.0
Have a nice day !
dgarske commentedon Nov 10, 2026
Hi @Hamady91
I reproduced it on a NUCLEO-H7S3L8 (same H7R/H7S family, LAN8742, D-cache on,
ETH_RX_DESC_CNT4, FreeRTOS port with default settings): a curl loop with a new connection per request gave a median around 1.4 s and a P95 around 2.4 s, the same pattern you saw.stm32_hal_eth.cand the FreeRTOS port are unchanged between v1.1.0 and master, so this is exactly what you are running.I've put up a PR #191 to fix this.
Can you please send an email to facts at wolfssl dot com and reference this issue? I'd love to hear more details and how best we can support you.
Thanks,
David Garske, wolfSSL
Hamady91 commentedon Nov 10, 2026
To give you more info @dgarske
I tested the PR #191 and it is now around 50ms even with TLS enabled + MQTTS ! So it seems to have fixed the issue !
I will send a email soon 💯
Thanks for the quick fix and fast replies