ESP32 TCP latency: ~200–300ms delay between send and recv despite optimizations
Posted: Thu Mar 27, 2025 12:54 pm
I need help in shortening the time it takes to read the response from the server on a TCP socket because I have tried many methods and none of them worked and I do not know what is really causing the delay. My communication looks like this: I send a single message on a given socket and then I expect an ACK response. My processing time is quite fast, but after sending the message I usually observe about 300ms until the response is read, despite the fact that in wireshark I see that the server responds about 30-50ms after sending the message.
The task in which I handle the TCP connection has a high priority in FreeRTOS support and during this time nothing serious is being done by other processes.
I have tried the following approaches:
Disable Nagle’s Algorithm (TCP_NODELAY).
Reduce/Remove Delay in the Main Loop (lower vTaskDelay or no delay).
Use select() instead of repeatedly polling sockets with delays.
Increase Task Priority for the recv/select handler.
Reduce Number of Sockets and simplify code logic.
Short recv() Timeout (via SO_RCVTIMEO with 1ms or similar).
In attachment I share the code and ask for some advice on how I can reduce the response time, because it is crucial in my application. On another modem operating via GSM this time was a maximum of 50ms.
Code: Untitled.c Select all
The task in which I handle the TCP connection has a high priority in FreeRTOS support and during this time nothing serious is being done by other processes.
I have tried the following approaches:
Disable Nagle’s Algorithm (TCP_NODELAY).
Reduce/Remove Delay in the Main Loop (lower vTaskDelay or no delay).
Use select() instead of repeatedly polling sockets with delays.
Increase Task Priority for the recv/select handler.
Reduce Number of Sockets and simplify code logic.
Short recv() Timeout (via SO_RCVTIMEO with 1ms or similar).
In attachment I share the code and ask for some advice on how I can reduce the response time, because it is crucial in my application. On another modem operating via GSM this time was a maximum of 50ms.