UDP performance VERY bad.

[collin80]

Hardware:

Board: ESP32 WROOM32
Core Installation/update date: Apr 13 or so
IDE name: Arduino IDE 1.8.5
Flash Frequency: 80Mhz
Upload Speed: 921600

Description:

I wrote a big sketch where I was reading CAN frames from two buses and trying to send them over wifi to connected machines. I've tried this multiple ways. I got it working pretty well by using TCP/IP over port 23 (telnet) and causing the ESP32 to be a softAP. The antenna on the WROOM32 is total trash and couldn't get a signal if you fired a megawatt MASER straight at it. But, with softAP mode and the thing right next to my machine I get a signal strength of about 65% which should be good enough. Anyway, switching to UDP is a total disaster. It drops frames like crazy. So, I made a simple test sketch (below) to do the same basic thing as the complicated sketch did when it comes to UDP but this sketch isn't doing anything else so it ought to rule out my doing anything stupid in the complicated sketch. Well, it still drops frames like crazy. The test sketch tries to send 400 bytes of payload every 1/2 second. Nothing too taxing. Sometimes I'll see 3-4 frames in a row come through. Then nothing for several seconds, then 3-4 come through then nothing then 1 or 2 then nothing for several seconds, and on and on. This is true even of the simple sketch. The WROOM32 is right next to my machine and signal strength isn't bad. There's no excuse for dropping so many packets. I tried doing begin(17222) just once and not doing stop() and that seems to make it even worse. Sometimes 8 or more seconds go by and no UDP message. This is stupid even for UDP messages. The drop rate has got to be trending toward at least 50% for me. Is this sort of result normal for the ESP32 or the WROOM32?

Sure, I can go back to TCP/IP but that's a rather bloated protocol and now I'm thinking it might be hiding this issue. I do sometimes get weird pauses in the TCP/IP stream which could be due to it losing the ability to transmit for a little bit.

Sketch:

#include <WiFi.h>
#include <WiFiMulti.h>

byte i = 0;

byte serialBuffer[2048];
int serialBufferLength = 0; //not creating a ring buffer. The buffer should be large enough to never overflow
uint32_t lastFlushMicros = 0;

WiFiServer wifiServer(23); //Register as a telnet server
WiFiUDP wifiUDPServer;
IPAddress broadcastAddr(192,168,4,255);

void setup()
{
    delay(5000); //just for testing. Don't use in production

    Serial.begin(115200);

    WiFi.mode(WIFI_AP);
    WiFi.softAP("ESP32DUE", "1234PASSWORD");

    Serial.print("Wifi setup as SSID ");
    Serial.println("ESP32DUE");
    Serial.print("IP address: ");
    Serial.println(WiFi.softAPIP());

    Serial.print("Done with init\n");
}

void loop()
{
    serialBufferLength = 400;
    //If the max time has passed or the buffer is almost filled then send a frame out
    if ((micros() - lastFlushMicros > 500000) ) {
        //Serial.write('*');
        wifiUDPServer.begin(17222);
        wifiUDPServer.beginPacket(broadcastAddr, 17222);
        wifiUDPServer.write(serialBuffer, serialBufferLength);
        wifiUDPServer.endPacket();
        wifiUDPServer.stop();
        lastFlushMicros = micros();
    }
}


### Debug Messages:

Enable Core debug level: Debug on tools menu of Arduino IDE, then put the serial output here

Nothing really notable here. 

�⸮��⸮⸮⸮�ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0018,len:4
load:0x3fff001c,len:956
load:0x40078000,len:0
load:0x40078000,len:13256
entry 0x40078a90
Wifi setup as SSID ESP32DUE
IP address: 192.168.4.1
Done with init
[D][WiFiGeneric.cpp:293] _eventCallback(): Event: 13 - AP_START
[D][WiFiGeneric.cpp:293] _eventCallback(): Event: 15 - AP_STACONNECTED

[collin80]

No ideas? I have now tested with iperf and I can get what seems to be pretty reliable comm through UDP if I use IPerf - Something like 750kB per second. Wireshark shows pretty consistent traffic too - sometimes a 20 ms extra delay but usually very smooth. This seems to indicate that something is wrong on the Arduino side since with ESP-IDF directly I can get a stable connection. TCP also still seems to work fine through the Arduino library. So, can anyone think of a reason for it to work so crummy for UDP in the Arduino library?

[MajicCat]

same observation

[helmut64]

What I don't get, why are you using "wifiUDPServer.begin(17222);" in every loop, this should be in setup only once. Another UDP API is "class UDP" which should be ok for a UDP client.
I also recommand to put debug prints into the UDP code that you can find out what is slow/wrong.

I also recommend a less agreesiven tone, we just like to help each other here.
Regards Helmut

[collin80]

I did cover that in my initial issue statement - I tried it both with wifiUPDServer.begin happening only once in setup and then I tried things with it in the loop like you see. Surprisingly, it works a bit better with begin and stop in the loop but performance is still not good. I will look into the UDP class to see if performance and reliability are better.

Sorry for the aggressive tone, this situation is frustrating but still I tried to write somewhat comically in a way (no you don't need a megawatt transmitter to get a decent signal out of the antenna.) Unfortunately, tone is tough to convey through text so too often it looks a bit more harsh than intended.

I don't know whether it makes me feel better that other people are seeing this issue. I guess that means it's at least not entirely my fault which is nice to know. But, it seems that this might indicate a fault in the library itself and I've been unable to find the issue after much looking. I suppose this means I ought to keep looking. Thank you everyone for the feedback, we'll get this figured out somehow.

[carbonadam]

Im having the same problem is there a work around for the arduino IDE?

[collin80]

I've updated to the bleeding edge as of this moment (July 2) code and tried to compile UDP sketches again. There's good and bad news. The good news is that I can get semi-reasonable performance out of UDP sending now. I'd say right around 80-90% of the packets reach the other side now. That's a whole lot better than 8 seconds of missing packets every so often. I've also tried switching to the AsyncUDP library instead. The function calls seem more intuitive and I like the look of that library a bit better. Either way, it looks like I get batches of packets at an interval right around 200ms. That is, if I send 4 frames 50ms apart what I get instead is 4 messages in very quick succession with a time of about 200ms between the batches. That seems a little weird to me. I didn't dredge the depths of code to figure out why this might be. I'm hoping someone knows the answer. The 200ms thing isn't a huge deal but it leads me to believe that the task is maybe only getting called a few times per second and not very quickly?

However, reception performance still seems like garbage to me. It seems to very often not receive packets when I know I sent them and wireshark shows that they've been sent. Additionally, with AsyncUDP if I receive traffic (even with the included example sketches) it will crash the sketch and tell me that there was an assert failure in pbuf_free (I think it says p->ref > 0 for the assert).

So, long story short, use TCP/IP still. UDP performance is better but it's not there yet.

[carbonadam]

ok so your using this library? https://github.com/me-no-dev/ESPAsyncUDP
and what was the code you udpated in the esp32 arduino lib?
cheers

[me-no-dev]

Setting WiFi sleep to false could maybe also help :) WiFi.setSleep(false) after WiFi.begin or WiFi.mode. FYI setSleep makes sense only in STA mode. for AP mode it's always disabled.

[me-no-dev]

@carbonadam that ESPAsyncUDP is for ESP8266. The ESP32 version is in the libraries folder of this repo.

[yanzixiang]

Additionally, with AsyncUDP if I receive traffic (even with the included example sketches) it will crash the sketch and tell me that there was an assert failure in pbuf_free (I think it says p->ref > 0 for the assert).

#2764

have a look at this @collin80

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This stale issue has been automatically closed. Thank you for your contributions.