Packet transmission failure caused by Not enough space

[Gaoqianjin]

Problem: AP as a UDP server,sends a broadcast packet with a size of 1440 bytes,
which is sent every 10 milliseconds.
After sending 80 packets, the number is recounted.
There are 10 to 30 packets are sent by Not enough space.
However, If you send packets once every 50 milliseconds, this is a complete success.
Environmental Science：
Station as a UDP client, it is normal to receive broadcast packets.
Esp-idf: commit 2935e958fc4b43c90550364d76ae8f0a3cb8488d
Sdkconfig: see attachments sdkconfig.doc
Problem replay: see attachments AP_LOG.txt
Code: see attachments AP.doc

[WiFive]

https://github.com/espressif/esp-idf/tr ... wifi/iperf

[ESP_Angus]

Hi Gaoqianjin,

There's a limit to the number of buffers available in the WiFi driver to transmit frames. Because each WiFi frame has to be ACKed at the RF layer, and because WiFi is a shared medium with mixed signal quality at times, there can be delays which cause this buffer to back up.

You can tune a number of parameters for WiFi buffer size in the WiFi configuration. The most useful one for UDP TX is to increase the number of WiFi TX buffers: http://esp-idf.readthedocs.io/en/latest ... buffer-num . This will increase the WiFi stack's maximum RAM usage but also allows more frames to be queued for transmit.

The iperf app (linked by WiFive above) has an sdkconfig.defaults file with some other performance tweaks, although these are for both UDP & TCP and both TX & RX so most won't change your particular situation.

The best thing you can do if a UDP send returns ENOMEM is to wait a short period and retry it. ENOMEM may still happen even with the larger buffers - this depends on the WiFi network signal quality, other traffic, any power saving modes set by the firmware, and the frequency of packets being sent.

[Gaoqianjin]

I want to get the size of the buffer free. If I find that the size of the buffer is enough, I will send it or else it will not be sent. Is there a solution?

[Gaoqianjin]

Power saving is very important, so I want to get the size of buffer free, and send packets when the buffer is free enough.

[ESP_Angus]

I'll check with my colleagues if this is possible.

The complexity is that there is an entire TCP/IP stack between your code which sends a UDP packets and the WiFi driver transmit buffers. At any time the TCP/IP stack may have to respond to a DHCP packet, or an ARP packet, or an ICMP packet, or some other data sent from other part of the system. Or the WiFi driver may be required to send something out at the WiFi layer. So even if you check there is a free TX buffer "now", you may still get ENOMEM if something else takes up that buffer before the UDP packet gets there.

[liuzhifu]

HI @Gaoqianjin currently we don't have API to get the available freed TX buffer number/size of WiFi driver. I think @ESP_Angus already provided the solution: "The best thing you can do if a UDP send returns ENOMEM is to wait a short period and retry it".

[Gaoqianjin]

Thank you for your clarification

[Gaoqianjin]

Hello, when AP sends a package every 1 milliseconds, it is found that station and AP can't create links. see attschments send_log_1ms.rar,recv_log_1ms.txt.
By grabbing data packets, it is found that AP rarely sends Beacon, and AP has no time to send Beacon.
In this case, Beacon rarely leads to buffer overflow. Is it justified by what I say?
Is there a solution to ensure high speed and massive data transmission?
However, station sent the broadcast packet to AP to receive the solution, which is much better, but this is not what I want.

[Gaoqianjin]

Hello, when AP sends a package every 1 milliseconds, it is found that station and AP can't create links. see attschments send_log_1ms.rar,recv_log_1ms.txt.
By grabbing data packets, it is found that AP rarely sends Beacon, Maybe AP does not have time to send Beacon.
In this case, Beacon rarely leads to buffer overflow. Is it justified by what I say?
Is there a solution to ensure high speed and massive data transmission?
However, station sent the broadcast packet to AP to receive the solution, which is much better, but this is not what I want.