You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm having issues after building and flashing the sdk. I got the following details from chatting with chatgpt, but it represents the issue I think. Is there any memory issues others are facing?
When sending large or frequent UDP packets (via libpeer on the ESP32-S3) the application logs repeated errors:
ERROR ./deps/libpeer/src/socket.c 128 Failed to sendto: Not enough space
These errors indicate that the underlying network stack (LWIP on ESP-IDF) is running out of buffer space (returning ENOBUFS). It appears that the application is sending data at a rate the socket’s buffers cannot handle.
Sample Logs:
INFO ./deps/libpeer/src/agent.c 32 create IPv4 UDP socket: 54
...
ERROR ./deps/libpeer/src/socket.c 128 Failed to sendto: Not enough space
ERROR ./deps/libpeer/src/socket.c 128 Failed to sendto: Not enough space
...
Expected Behavior
The application should either:
• Successfully send all UDP packets without returning ENOBUFS, OR
• Gracefully throttle/back off sending when the LWIP/UDP buffers are full (instead of continuously logging an error).
Additional Context
• UDP on resource-constrained devices (like the ESP32-S3) typically has limited buffer space. If the sending rate is too high, the socket will return “Not enough space” (ENOBUFS).
• Temporarily increasing LWIP buffers via idf.py menuconfig (under “Component config” → “LWIP”) can mitigate the issue but can also reduce available RAM for other parts of the application.
• Ideally, the application should implement flow control. When sendto() fails with “Not enough space,” it should back off or queue data for later sending, rather than retrying immediately.
Possible Fixes
1. Implement Application-Level Rate Control
• Check the return code from sendto(). If ENOBUFS is returned, wait briefly (e.g., 20–50 ms) before trying again.
2. Tune LWIP Buffer Settings
• Increase pbuf pool sizes, UDP buffer sizes, and/or other memory parameters in menuconfig → Component config → LWIP.
3. Add Retries or Adaptive Sending
• Use a queue or ring buffer in the application layer, pushing data to the socket only when space is available.
A combination of these approaches should eliminate the high-rate UDP “Not enough space” errors.
The text was updated successfully, but these errors were encountered:
I'm having issues after building and flashing the sdk. I got the following details from chatting with chatgpt, but it represents the issue I think. Is there any memory issues others are facing?
When sending large or frequent UDP packets (via libpeer on the ESP32-S3) the application logs repeated errors:
ERROR ./deps/libpeer/src/socket.c 128 Failed to sendto: Not enough space
These errors indicate that the underlying network stack (LWIP on ESP-IDF) is running out of buffer space (returning ENOBUFS). It appears that the application is sending data at a rate the socket’s buffers cannot handle.
Sample Logs:
INFO ./deps/libpeer/src/agent.c 32 create IPv4 UDP socket: 54
...
ERROR ./deps/libpeer/src/socket.c 128 Failed to sendto: Not enough space
ERROR ./deps/libpeer/src/socket.c 128 Failed to sendto: Not enough space
...
Expected Behavior
The application should either:
• Successfully send all UDP packets without returning ENOBUFS, OR
• Gracefully throttle/back off sending when the LWIP/UDP buffers are full (instead of continuously logging an error).
Environment
• Hardware: ESP32-S3 board with 8MB PSRAM
• ESP-IDF Version: v5.5-dev (commit gcc9fb5bd5e)
• Operating System: macOS (for development)
• libpeer: Custom WebRTC/UDP library (in deps/libpeer/)
Additional Context
• UDP on resource-constrained devices (like the ESP32-S3) typically has limited buffer space. If the sending rate is too high, the socket will return “Not enough space” (ENOBUFS).
• Temporarily increasing LWIP buffers via idf.py menuconfig (under “Component config” → “LWIP”) can mitigate the issue but can also reduce available RAM for other parts of the application.
• Ideally, the application should implement flow control. When sendto() fails with “Not enough space,” it should back off or queue data for later sending, rather than retrying immediately.
Possible Fixes
1. Implement Application-Level Rate Control
• Check the return code from sendto(). If ENOBUFS is returned, wait briefly (e.g., 20–50 ms) before trying again.
2. Tune LWIP Buffer Settings
• Increase pbuf pool sizes, UDP buffer sizes, and/or other memory parameters in menuconfig → Component config → LWIP.
3. Add Retries or Adaptive Sending
• Use a queue or ring buffer in the application layer, pushing data to the socket only when space is available.
A combination of these approaches should eliminate the high-rate UDP “Not enough space” errors.
The text was updated successfully, but these errors were encountered: