Ping fluctuations

[podaen]

Board

DOIT ESP32 devkit v4

Device Description

N

Hardware Configuration

I2S audio output

Version

latest development Release Candidate (RC-X)

IDE Name

1.8.19

Operating System

windows10

Flash frequency

80MHz

PSRAM enabled

no

Upload speed

115200

Description

I am making a program that involves url audio streams and starting to notist that it starts fluctuating in filling the buffer.

By doing a ping test I see once the response start to be fluctuating above 200ms and it doesn't recover. And that is what I see in my stream too.

Can it not been made that the ping is not fluctuating so much?? I got this problem also in WiFiclient.h and WiFiClientSecure.h, but I think this is not where the issue is.

Sketch

/*ping test*/
#include "WiFi.h"
#include <esp_wifi.h>
#include <esp_bt_main.h>//power saving bluetooth
#include <esp_bt.h>//power saving bluetooth

const char* ssid = "SSID";
const char* password = "PASS";

void setup() {
    Serial.begin(115200);
    while (!Serial);
    WiFi.begin(ssid, password);

    while (WiFi.status() != WL_CONNECTED) {
        delay(1000);
        Serial.println("Connecting to WiFi..");
    }
    //esp_wifi_set_ps(WIFI_PS_NONE);
    WiFi.setSleep(false);

    esp_bluedroid_disable();
    esp_bluedroid_deinit();
    esp_bt_controller_disable();
    esp_bt_controller_deinit();

    Serial.println(WiFi.localIP());
    Serial.print("RSSI: ");
    Serial.println(WiFi.RSSI());//the closer to 0, the stronger the signal
}

// the loop function runs over and over again until power down or reset
void loop() {
  
}

/*speed test*/
//#include <HTTPClient.h>
//#include "WiFi.h"
//#include <esp_wifi.h>
//#include <esp_bt_main.h>//power saving bluetooth
//#include <esp_bt.h>//power saving bluetooth
//
//const char* ssid = "SSID";
//const char* password = "PASS";
//
//void setup() {
//    Serial.begin(115200);
//    WiFi.begin(ssid, password);
//
//    while (WiFi.status() != WL_CONNECTED) {
//        delay(1000);
//        Serial.println("Connecting to WiFi..");
//    }
//    esp_wifi_set_ps(WIFI_PS_NONE);
//    WiFi.setSleep(false);
//
//        esp_bluedroid_disable();
//    esp_bluedroid_deinit();
//    esp_bt_controller_disable();
//    esp_bt_controller_deinit();
//
//    Serial.println(WiFi.localIP());
//    Serial.print("RSSI: ");
//    Serial.println(WiFi.RSSI());//the closer to 0, the stronger the signal
//}
//
//long speedtest() {
//    unsigned long start;
//    long total = 0;
//    if ((WiFi.status() == WL_CONNECTED)) { //Check the current connection status
//
//        HTTPClient http;
//        //Serial.print("starting...");
//        //http.begin("https://proof.ovh.net/files/1Mb.dat", root_ca); //Specify the URL and certificate
//        http.begin("http://speedtest.tele2.net/1MB.zip"); //Specify the URL and certificate
//        int httpCode = http.GET();                                                  //Make the request
//
//        if (httpCode > 0) { //Check for the returning code
//            //Serial.print(httpCode); Serial.print("           ");
//            if (httpCode == HTTP_CODE_OK) {
//                // get length of document (is -1 when Server sends no Content-Length header)
//                total = http.getSize();
//
//                uint8_t buff[512] = { 0 };
//                int buf_size_actual = sizeof(buff);
//                Serial.print("Buff Size: "); Serial.print(buf_size_actual);
//                WiFiClient* stream = http.getStreamPtr();
//                http.setReuse(true);
//                start = millis();
//                size_t size = 1;
//                long remaining = total;
//                while (http.connected() && (remaining > 0 || remaining == -1)) {
//                    if (stream->available()) {
//                        remaining -= stream->readBytes(buff, 512);
//                    }
//                }
//            }
//        }
//        else {
//            Serial.println("Error on HTTP request");
//        }
//
//        http.end();
//        Serial.print("\tTime: "); Serial.print(millis() - start);
//        Serial.print("\tBytes: "); Serial.print(total);
//        Serial.print("\tThroughput :"); Serial.print("\t"); Serial.print(total / (millis() - start) * 8); Serial.print("\tkbps");
//        return total / (millis() - start) * 8;
//        Serial.println("");
//    }
//}
//
//void loop() {
//    Serial.println(speedtest());
//    delay(5000);
//}

Debug Message

This is a few tests I did, but it is not the worst case scenario. When it gets bad it get above 200ms, I see this once but I forgot the copy. 

> Pingen naar 192.168.1.178 met 512 bytes aan gegevens:
> Antwoord van 192.168.1.178: bytes=512 tijd=935 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=8 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=4 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=6 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=6 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=10 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=7 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=6 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=6 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=8 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=8 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=4 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=11 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=5 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=10 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=7 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=12 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=6 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=8 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=8 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=9 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=6 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=6 ms TTL=255
4ms against 12ms +200%

> Antwoord van 192.168.1.178: bytes=512 tijd=16 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=8 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=7 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=5 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=6 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=7 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=10 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=9 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=11 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=9 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=6 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=8 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=6 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=7 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=5 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=6 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=6 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=10 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=8 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=9 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=7 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=6 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=6 ms TTL=255
5ms against 11ms +100%

> Antwoord van 192.168.1.178: bytes=512 tijd=41 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=6 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=8 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=4 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=5 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=10 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=10 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=8 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=4 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=8 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=8 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=8 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=6 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=9 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=24 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=6 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=9 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=10 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=6 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=6 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=7 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=8 ms TTL=255
> Antwoord van 192.168.1.178: bytes=512 tijd=8 ms TTL=255
4ms against 24ms 500%

without setSleep(false) and ble disable
Antwoord van 192.168.1.178: bytes=512 tijd=115 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=129 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=55 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=73 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=5 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=110 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=121 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=28 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=64 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=99 ms TTL=255
Time-out bij opdracht.
Antwoord van 192.168.1.178: bytes=512 tijd=54 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=78 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=94 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=106 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=42 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=62 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=85 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=113 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=27 ms TTL=255
5ms against 106ms 2000%

connection speed (with an rssi -62 (with antenna) -> +-1300kbs???)
Buff Size: 512 Time: 7142 Bytes: 1048576 Throughput : 1168 kbps1168
Buff Size: 512 Time: 8244 Bytes: 1048576 Throughput : 1016 kbps1016
Buff Size: 512 Time: 6870 Bytes: 1048576 Throughput : 1216 kbps1216
Buff Size: 512 Time: 6739 Bytes: 1048576 Throughput : 1240 kbps1240
Buff Size: 512 Time: 6360 Bytes: 1048576 Throughput : 1312 kbps1312
Buff Size: 512 Time: 6800 Bytes: 1048576 Throughput : 1232 kbps1232
Buff Size: 512 Time: 6645 Bytes: 1048576 Throughput : 1256 kbps1256
Buff Size: 512 Time: 7924 Bytes: 1048576 Throughput : 1056 kbps1056
Buff Size: 512 Time: 6241 Bytes: 1048576 Throughput : 1344 kbps1344
Buff Size: 512 Time: 6324 Bytes: 1048576 Throughput : 1320 kbps1320
Buff Size: 512 Time: 7214 Bytes: 1048576 Throughput : 1160 kbps1160
Buff Size: 512 Time: 7879 Bytes: 1048576 Throughput : 1064 kbps1064
Buff Size: 512 Time: 6289 Bytes: 1048576 Throughput : 1328 kbps1328
Buff Size: 512 Time: 6145 Bytes: 1048576 Throughput : 1360 kbps1360
Buff Size: 512 Time: 6253 Bytes: 1048576 Throughput : 1336 kbps1336
Buff Size: 512 Time: 6421 Bytes: 1048576 Throughput : 1304 kbps1304
Buff Size: 512 Time: 6192 Bytes: 1048576 Throughput : 1352 kbps1352
Buff Size: 512 Time: 6119 Bytes: 1048576 Throughput : 1368 kbps1368
Buff Size: 512 Time: 6440 Bytes: 1048576 Throughput : 1296 kbps1296

Other Steps to Reproduce

See also
pschatzmann/arduino-audio-tools#180

I have checked existing issues, online documentation and the Troubleshooting Guide

• I confirm I have checked existing issues, online documentation and Troubleshooting guide.

[podaen]

After my search I came out here WiFiGeneric.cpp, I'm thinking of a memory problem and maybe caused by a timout.

[podaen]

When I run WiFi on core 0 the fluctuate sooner bigger. And than it stabilizes and than pops up much bigger, but less over time.

I tried with these settings too

esp_wifi_set_mode(WIFI_MODE_NULL);
WiFi.useStaticBuffers(true);

it stills occur.

Antwoord van 192.168.1.178: bytes=512 tijd=6 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=8 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=4 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=4 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=4 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=4 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=5 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=8 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=9 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=5 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=5 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=7 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=6 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=5 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=7 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=4 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=5 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=5 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=5 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=5 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=5 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=6 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=4 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=7 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=5 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=5 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=5 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=5 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=4 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=4 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=6 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=6 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=5 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=4 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=5 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=4 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=6 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=5 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=5 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=5 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=5 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=6 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=7 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=6 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=4 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=6 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=5 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=4 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=6 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=8 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=6 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=6 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=5 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=4 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=7 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=666 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=140 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=629 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=7 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=5 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=4 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=6 ms TTL=255
Antwoord van 192.168.1.178: bytes=512 tijd=4 ms TTL=255

[podaen]

I set the log to verbose, nothing is shown.

I found this about how wifi works

And than I cam out here that includes FreeRTOS

The task of the event running on the same core as the task I am running, during selecting core0 a see a difference in timing.

[podaen]

It have to be something that is running in the background and runs on core0. Why could it be that if the WiFi runs on an other core and the breaks get soo long above the 200. It even cuts the data off from a stream (core independent), but the clock keeps running.

[podaen]

I m ended in FreeRTOS. This is called form the ESP and I think that the buffer takes longer than expected to allocated in to the memory, because something else is called that takes long... or it want to take the same place. And because there is data been lost, I think it's the place that has been taken. There most be priority for the buffer! Anyway that memory has to be preserved for the buffer.

There is something I have done and that is serial... Which can not be turned off, but it's a start. The serial monitor works for both cores and ends up one pin gpio 3. And if we run the wifi on core0 it need to switch from core0 to core1.

it starts to make sens now. It more constant, but when it happens it get more clear.

[podaen]

I have set WIFI_TASK_CORE_ID to 1 in esp_wifi.h, task in to 0. The biggest number I ever had is 81ms, The varriation could be 23ms. but that is not in the standaard deviation, that is normaly around 9ms. I diden't measure the beginnings because the doesn't count for me. I think this is the best number I ever had.

By setting my task to core0 and set the WIFI_TASK_CORE_ID to 0 I get a corrupted backtrace after a few package received. So I changing back to default. Now strang things happens...

Task core1
WiFi core1

199ms at most, verry bad setting

Task core1 (default)
Wfii core0 (default, but with a task)

I cot a corruped backtrace (few package received and crash)

Task core0
WiFi core1

I got a corruped backtrace (few package received and crash)

Task core 0
WiFi core 0

I got a corruped backtrace (few package received and crash)

Task core 0
WiFi core 1

78ms at most.

Task core 1
WiFi core 0

169ms at most

Note: the package where still sending when I changed the settings uploaded and rebooted. I did changed the setting in the library it self and diden't set CONFIG_ESP32_WIFI_TASK_PINNED_TO_CORE_1. This can be the causes the corrupted backtracé. If I set it in to my sketch it doesn't recognize it and esp_wifi_init. If somebody know how to do it, I would be glad to know!

The UART running on to the default core. And the something that triggers FreeTROS to put UART information from core0 in to core1. Still the antenna is not only receiving data but is also transmitting data. Switching between transmitting and receiving happens really fast if the transmitting is not the same amount data than the receiving, like most cases (including mine).

What I do see as that switching between cores doesn't go that fast.

Thing to do: Test a connection without DHCP.

[Jason2866]

I always wondered why the ping times for the ESP32 is in general higher as for ESP32-S2, S3 and C3.
My wild guess the two cores and wifi switching has a general problem "somewhere".

[podaen]

The probebly have a beter design, but I m curious... Could you try the shetch, let it run for 10 min and and post your worst results?

[podaen]

The UART running on to the default core. And the something that triggers FreeTROS to put UART information from core0 in to core1. Still the antenna is not only receiving data but is also transmitting data. Switching between transmitting and receiving happens really fast if the transmitting is not the same amount data than the receiving, like most cases (including mine).

Further test with the esp32 devkit tells me that the urart not causing this breaks.

I m testing now my stream, and it still breaks with loop core0 and WiFi_event to core1, so 60ms is still to much. But it doesn't cuttoff anymore. That's a good thing.

For me it's clear that the software is the solution to solve this... Still wondering why I can't set the loop and the event on the same core, core0. If I would have less than 16ms for every package, I think it would work.

[podaen]

Spoken to soon, it still breaks. Probably on the 60ms, because the occure after a couple minuts. It is like it running out of sync...

[podaen]

This surprises me in the WiFiGeneric.h...

static void _arduino_event_task(void * arg){
	arduino_event_t *data = NULL;
    for (;;) {
        if(xQueueReceive(_arduino_event_queue, &data, portMAX_DELAY) == pdTRUE){
            WiFiGenericClass::_eventCallback(data);
            free(data);
            data = NULL;
        }
    }
    vTaskDelete(NULL);
    _arduino_event_task_handle = NULL;
}

Why deleting it, when the connection is still open?

[podaen]

Ok, I did some measurement. It doesn't take time to create a task a task on a other core and it doesn't take time to delete a task.

@Jason2866 My mistake, switching cores doesn't take time. If you say that an S doesn't have that issue. than it could be board driver related, but we be still not sure. wifi is under 2.0.3-RC1\tools\sdk\esp32\include\esp_wifi\include. other board other esp_wifi.

Mistery unsolved

[podaen]

what does that mean, flight time? I looked it up and it says that is a distance sensor... Not impotent for this topic.

[SuGlider]

I know that WiFi uses LWIP layer to perform networking protocols, and the main point here, buffering and memory allocation.
Arduino has been setup up to use the lowest memory for some TCP/IP and UDP allocations in order to keep more HEAP available to the application and users.

But there is a caveat... using less memory for LWIP implies in performance downgrade.
Thus, if performance is your goal, I think it may be necessary for your application to change LWIP defaults and reach to the balance of memory allocation and performance that will render what you need.

Unfortunately, it is beyond Arduino Layer and demands understanding LWIP setup and configuration.
One way of doing it is by moving to Arduino as a Component in an IDF project instead of using this Arduino pre-compiled framework, In that case you will be able to tweak LWIP using MenuConfig and make it work the way it gives you the necessary performance.

[SuGlider]

Here is where the memory allocation happens and it is possible to change buffers size, static x dynamic buffers and so on.
But it is not exposed to Arduino Layer.

https://github.com/espressif/arduino-esp32/blob/master/libraries/WiFi/src/WiFiGeneric.cpp#L590-L599

You can maybe play with it in your machine... just to see if you can reach to a configuration that works best for your applications.

In order to be able to use such parameter, the Arduino Sketch shall use WiFi.useStaticBuffers(true). The default is false and it uses Dynamic Buffer that may, by itself, degrade the performance. Maybe just start by calling that command in your application to see if it helps with the performance.

This is the general order of execution for using useStaticBuffers() method. Please turn Core Debug Level: "Verbose" in order to see warning and error messages.

WiFi.useStaticBuffers(true);
WiFi.mode(WIFI_MODE_STA); 
WiFi.begin("SSID", "Password");

[SuGlider]

Another option, as said, is to convert it to an IDF project using Arduino as Component and then try changing such LWIP parameters using ESP-IDF MenuConfig.

Anyway, as also said, current Arduino Framework configuration goes in the direction of a nice general network performance, for simple and low latency network usage, with higest possible HEAP availability to users.

It can't be changed by API at this time.

[podaen]

First of all, thanks to take your time to replying this observation.

Actually I have two point I am working on. This is performance, right... And there is memory. I already looked in how to save memorie as much as I can be choosing addition software that doesn't use to much in order to handel my big stream. So I afraid I am a bit stuck here with the memorie.

I know the configmenu from python, but I rader like to program in Arduino. That where my most code are. It is sad that it can't be configt in the Arduino environment. However, I could try to change it in python, look at the settings of LWIP (keep the change) and edit it like it is generated with python. But indeed unfortunately it is not in the arduino so I can not test with it.

I did already tried with static buffer to true, but that wasn't engough. I will try to increase

CONFIG_ESP32_WIFI_DYNAMIC_RX_BUFFER_NUM=32

I am going to set it to 44 and do the ping test... it didn't changed the fact that sometimes there is a delay in it. And it happens really soon and decrease again and increases again and so on...

I tried every setting... also static buffer and increasing the size.

Every time it causes a delay no matter how big the packages are. I tried also package of 32bytes and the delay stays!
I am still keeping my head up that something else takes an enormes time to handle that isn't showed in the log.

And than I was wondering if it was because there is something connected to it. And without anything connected to it still happens now and than.

[podaen]

Does anybody knows what is called in the background, that take an enormes time?

I m starting to thing back it is wifigeneric. because when I cause a bad receiving position I see that delay to after some time!

I think that after a connection has ben established it does something and repeated it self ( but not time depended).

[TD-er]

Does anybody knows what is called in the background?

Not sure about what is called in the background, but just a thought.
Do you also have Bluetooth enabled?
Since it is using the same RF circuit as far as I know, it could be interfering with WiFi.
Bluetooth does frequency hop far more often than WiFi, so maybe having Bluetooth enabled may interfere with WiFi packets being missed?

Edit:
Hmm you seem to disable it in your code:

    esp_bluedroid_disable();
    esp_bluedroid_deinit();
    esp_bt_controller_disable();
    esp_bt_controller_deinit();

But maybe this is not enough?

[podaen]

Powersave to false for the wifi didn't help ether...

[podaen]

I think that after a connection has ben established it does something and repeated it self ( but not time depended).

This is the thing we have to look for and where there is no log in it.

[podaen]

The focus of the lwIP TCP/IP implementation is to reduce the RAM usage
while still having a full scale TCP. This making lwIP suitable for use
in embedded systems with tens of kilobytes of free RAM and room for
around 40 kilobytes of code ROM.

Since it is not size depended I don't think that tcpip would make a difference.

[podaen]

wow. Looking at some crazy things now...

I did set the esp in a position long enough until the connection was lost.

[708876][V][WiFiGeneric.cpp:300] _arduino_event_cb(): STA Disconnected: SSID: PODAEN, BSSID: dc:53:7c:98:1b:fc, Reason: 200
[708878][D][WiFiGeneric.cpp:852] _eventCallback(): Arduino Event: 5 - STA_DISCONNECTED
[708885][W][WiFiGeneric.cpp:873] _eventCallback(): Reason: 200 - BEACON_TIMEOUT
[708892][D][WiFiGeneric.cpp:889] _eventCallback(): WiFi Reconnect Running
[708900][V][WiFiGeneric.cpp:96] set_esp_interface_ip(): Configuring Station static IP: 0.0.0.0, MASK: 0.0.0.0, GW: 0.0.0.0
[710967][V][WiFiGeneric.cpp:300] _arduino_event_cb(): STA Disconnected: SSID: PODAEN, BSSID: 00:00:00:00:00:00, Reason: 201
[710968][D][WiFiGeneric.cpp:852] _eventCallback(): Arduino Event: 5 - STA_DISCONNECTED
[710975][W][WiFiGeneric.cpp:873] _eventCallback(): Reason: 201 - NO_AP_FOUND
[710982][D][WiFiGeneric.cpp:898] _eventCallback(): WiFi AutoReconnect Running
[710990][V][WiFiGeneric.cpp:96] set_esp_interface_ip(): Configuring Station static IP: 0.0.0.0, MASK: 0.0.0.0, GW: 0.0.0.0
[713238][V][WiFiGeneric.cpp:295] _arduino_event_cb(): STA Connected: SSID: PODAEN, BSSID: dc:53:7c:98:1b:fc, Channel: 6, Auth: WPA2_PSK
[713239][D][WiFiGeneric.cpp:852] _eventCallback(): Arduino Event: 4 - STA_CONNECTED
[713654][V][WiFiGeneric.cpp:305] _arduino_event_cb(): STA Got Same IP:192.168.1.242
[713655][D][WiFiGeneric.cpp:852] _eventCallback(): Arduino Event: 7 - STA_GOT_IP
[713658][D][WiFiGeneric.cpp:914] _eventCallback(): STA IP: 192.168.1.242, MASK: 255.255.255.0, GW: 192.168.1.1

I will do the test over and see if I can repeat it...

Now it takes longer for the esp32 to see that the connection has been lost. Before it reconnects itself.

Antwoord van 192.168.1.242: bytes=512 tijd=13 ms TTL=255
Time-out bij opdracht.
Time-out bij opdracht.
Time-out bij opdracht.
Time-out bij opdracht.
Time-out bij opdracht.
Time-out bij opdracht.
Time-out bij opdracht.
Time-out bij opdracht.
Time-out bij opdracht.
Time-out bij opdracht.
Time-out bij opdracht.
Time-out bij opdracht.
Time-out bij opdracht.
Time-out bij opdracht.
Time-out bij opdracht.
Time-out bij opdracht.
Time-out bij opdracht.
Time-out bij opdracht.
Time-out bij opdracht.
Time-out bij opdracht.
Antwoord van 192.168.1.242: bytes=512 tijd=9 ms TTL=255
Antwoord van 192.168.1.242: bytes=512 tijd=15 ms TTL=255
Antwoord van 192.168.1.242: bytes=512 tijd=8 ms TTL=255
Antwoord van 192.168.1.242: bytes=512 tijd=9 ms TTL=255
Antwoord van 192.168.1.242: bytes=512 tijd=9 ms TTL=255
Antwoord van 192.168.1.242: bytes=512 tijd=243 ms TTL=255
Antwoord van 192.168.1.242: bytes=512 tijd=9 ms TTL=255
Antwoord van 192.168.1.242: bytes=512 tijd=16 ms TTL=255
Antwoord van 192.168.1.242: bytes=512 tijd=10 ms TTL=255
Antwoord van 192.168.1.242: bytes=512 tijd=10 ms TTL=255
Antwoord van 192.168.1.242: bytes=512 tijd=15 ms TTL=255
Antwoord van 192.168.1.242: bytes=512 tijd=9 ms TTL=255
Antwoord van 192.168.1.242: bytes=512 tijd=10 ms TTL=255
Antwoord van 192.168.1.242: bytes=512 tijd=8 ms TTL=255
Antwoord van 192.168.1.242: bytes=512 tijd=9 ms TTL=255
Antwoord van 192.168.1.242: bytes=512 tijd=9 ms TTL=255
Antwoord van 192.168.1.242: bytes=512 tijd=17 ms TTL=255
Antwoord van 192.168.1.242: bytes=512 tijd=9 ms TTL=255
Antwoord van 192.168.1.242: bytes=512 tijd=9 ms TTL=255
Antwoord van 192.168.1.242: bytes=512 tijd=8 ms TTL=255
Antwoord van 192.168.1.242: bytes=512 tijd=11 ms TTL=255
Antwoord van 192.168.1.242: bytes=512 tijd=9 ms TTL=255
Antwoord van 192.168.1.242: bytes=512 tijd=9 ms TTL=255
Antwoord van 192.168.1.242: bytes=512 tijd=15 ms TTL=255
Antwoord van 192.168.1.242: bytes=512 tijd=9 ms TTL=255

Even the autoreconnect was not showed on that moment. It was after a minute that autoreconnect shows up.

[1578832][D][WiFiGeneric.cpp:898] _eventCallback(): WiFi AutoReconnect Running
[1578840][V][WiFiGeneric.cpp:96] set_esp_interface_ip(): Configuring Station static IP: 0.0.0.0, MASK: 0.0.0.0, GW: 0.0.0.0
[1581091][V][WiFiGeneric.cpp:295] _arduino_event_cb(): STA Connected: SSID: PODAEN, BSSID: dc:53:7c:98:1b:fc, Channel: 6, Auth: WPA2_PSK
[1581092][D][WiFiGeneric.cpp:852] _eventCallback(): Arduino Event: 4 - STA_CONNECTED
[1581289][V][WiFiGeneric.cpp:305] _arduino_event_cb(): STA Got Same IP:192.168.1.242
[1581290][D][WiFiGeneric.cpp:852] _eventCallback(): Arduino Event: 7 - STA_GOT_IP
[1581293][D][WiFiGeneric.cpp:914] _eventCallback(): STA IP: 192.168.1.242, MASK: 255.255.255.0, GW: 192.168.1.1

[podaen]

[710975][W][WiFiGeneric.cpp:873] _eventCallback(): Reason: 201 - NO_AP_FOUND

What does this line it to my log???

And this line

[708885][W][WiFiGeneric.cpp:873] _eventCallback(): Reason: 200 - BEACON_TIMEOUT

I am not connecting to a server or a beacon. I just did WiFi.begin and logged in and tested with the connection lost and pinged it.

[podaen]

It does a number of things, the callback is repeatedly called.

[2883503][V][WiFiGeneric.cpp:300] _arduino_event_cb(): STA Disconnected: SSID: PODAEN, BSSID: dc:53:7c:98:1b:fc, Reason: 200
[2883503][D][WiFiGeneric.cpp:852] _eventCallback(): Arduino Event: 5 - STA_DISCONNECTED
[2883511][W][WiFiGeneric.cpp:873] _eventCallback(): Reason: 200 - BEACON_TIMEOUT
[2883518][D][WiFiGeneric.cpp:898] _eventCallback(): WiFi AutoReconnect Running
[2883526][V][WiFiGeneric.cpp:96] set_esp_interface_ip(): Configuring Station static IP: 0.0.0.0, MASK: 0.0.0.0, GW: 0.0.0.0
[2885593][V][WiFiGeneric.cpp:300] _arduino_event_cb(): STA Disconnected: SSID: PODAEN, BSSID: 00:00:00:00:00:00, Reason: 201
[2885593][D][WiFiGeneric.cpp:852] _eventCallback(): Arduino Event: 5 - STA_DISCONNECTED
[2885601][W][WiFiGeneric.cpp:873] _eventCallback(): Reason: 201 - NO_AP_FOUND
[2885608][D][WiFiGeneric.cpp:898] _eventCallback(): WiFi AutoReconnect Running
[2885616][V][WiFiGeneric.cpp:96] set_esp_interface_ip(): Configuring Station static IP: 0.0.0.0, MASK: 0.0.0.0, GW: 0.0.0.0
[2887679][V][WiFiGeneric.cpp:300] _arduino_event_cb(): STA Disconnected: SSID: PODAEN, BSSID: 00:00:00:00:00:00, Reason: 201
[2887680][D][WiFiGeneric.cpp:852] _eventCallback(): Arduino Event: 5 - STA_DISCONNECTED
[2887687][W][WiFiGeneric.cpp:873] _eventCallback(): Reason: 201 - NO_AP_FOUND
[2887694][D][WiFiGeneric.cpp:898] _eventCallback(): WiFi AutoReconnect Running
[2887702][V][WiFiGeneric.cpp:96] set_esp_interface_ip(): Configuring Station static IP: 0.0.0.0, MASK: 0.0.0.0, GW: 0.0.0.0
[2890766][V][WiFiGeneric.cpp:300] _arduino_event_cb(): STA Disconnected: SSID: PODAEN, BSSID: dc:53:7c:98:1b:fc, Reason: 2
[2890767][D][WiFiGeneric.cpp:852] _eventCallback(): Arduino Event: 5 - STA_DISCONNECTED
[2890774][W][WiFiGeneric.cpp:873] _eventCallback(): Reason: 2 - AUTH_EXPIRE
[2890781][D][WiFiGeneric.cpp:898] _eventCallback(): WiFi AutoReconnect Running
[2890789][V][WiFiGeneric.cpp:96] set_esp_interface_ip(): Configuring Station static IP: 0.0.0.0, MASK: 0.0.0.0, GW: 0.0.0.0
[2893165][V][WiFiGeneric.cpp:295] _arduino_event_cb(): STA Connected: SSID: PODAEN, BSSID: dc:53:7c:98:1b:fc, Channel: 6, Auth: WPA2_PSK
[2893167][D][WiFiGeneric.cpp:852] _eventCallback(): Arduino Event: 4 - STA_CONNECTED
[2893271][V][WiFiGeneric.cpp:305] _arduino_event_cb(): STA Got Same IP:192.168.1.242
[2893271][D][WiFiGeneric.cpp:852] _eventCallback(): Arduino Event: 7 - STA_GOT_IP
[2893274][D][WiFiGeneric.cpp:914] _eventCallback(): STA IP: 192.168.1.242, MASK: 255.255.255.0, GW: 192.168.1.1

I checkt if the callback causes the delay, but it isn't even called...

[podaen]

And what do we get now, without any change... host not been reached.

Antwoord van 192.168.1.242: bytes=512 tijd=5 ms TTL=255
Antwoord van 192.168.1.242: bytes=512 tijd=4 ms TTL=255
Antwoord van 192.168.1.242: bytes=512 tijd=3 ms TTL=255
Antwoord van 192.168.1.242: bytes=512 tijd=4 ms TTL=255
Time-out bij opdracht.
Time-out bij opdracht.
Time-out bij opdracht.
Antwoord van 192.168.1.192: De doelhost is niet bereikbaar.
Antwoord van 192.168.1.192: De doelhost is niet bereikbaar.
Antwoord van 192.168.1.192: De doelhost is niet bereikbaar.
Antwoord van 192.168.1.242: bytes=512 tijd=472 ms TTL=255
Time-out bij opdracht.
Time-out bij opdracht.
Antwoord van 192.168.1.242: bytes=512 tijd=97 ms TTL=255
Antwoord van 192.168.1.242: bytes=512 tijd=3 ms TTL=255
Antwoord van 192.168.1.242: bytes=512 tijd=4 ms TTL=255
Antwoord van 192.168.1.242: bytes=512 tijd=6 ms TTL=255
Antwoord van 192.168.1.242: bytes=512 tijd=6 ms TTL=255
Antwoord van 192.168.1.242: bytes=512 tijd=6 ms TTL=255
Antwoord van 192.168.1.242: bytes=512 tijd=205 ms TTL=255
Antwoord van 192.168.1.242: bytes=512 tijd=5 ms TTL=255
Antwoord van 192.168.1.242: bytes=512 tijd=69 ms TTL=255
Antwoord van 192.168.1.242: bytes=512 tijd=7 ms TTL=255
Antwoord van 192.168.1.242: bytes=512 tijd=7 ms TTL=255

[podaen]

I just tested connecting to the wifi without internet (Begin() without ssid and pass). Same issue

[podaen]

Changing the dchp to static doesn't change anything. And I don't know how to use less to test the connection , if I don't get input on this. But I am wondering why such a big portMAX_DELAY...

xQueueReceive(_arduino_event_queue, &data, portMAX_DELAY) == pdTRUE)
portMAX_DELAY = 4294967295

If someone can setup an own connection without using wifi.h I would be glad to test the shetch. But I think it is a task that is running independ from the wifi connection that causing this delay. If I could use a less as possible library's we could maybe have a clue. And it something big. Because sometimes it takes a lot of time to handle.

[podaen]

 * @cond !DOC_EXCLUDE_HEADER_SECTION
 * queue. h
 * @code{c}
 * BaseType_t xQueueReceive(
 *                               QueueHandle_t xQueue,
 *                               void *pvBuffer,
 *                               TickType_t xTicksToWait
 *                          );
 * @endcode
 * @endcond
 *
 * Receive an item from a queue.  The item is received by copy so a buffer of
 * adequate size must be provided.  The number of bytes copied into the buffer
 * was defined when the queue was created.
 *
 * Successfully received items are removed from the queue.
 *
 * This function must not be used in an interrupt service routine.  See
 * xQueueReceiveFromISR for an alternative that can.
 *
 * @param xQueue The handle to the queue from which the item is to be
 * received.
 *
 * @param pvBuffer Pointer to the buffer into which the received item will
 * be copied.
 *
 * @param xTicksToWait The maximum amount of time the task should block
 * waiting for an item to receive should the queue be empty at the time
 * of the call. xQueueReceive() will return immediately if xTicksToWait
 * is zero and the queue is empty.  The time is defined in tick periods so the
 * constant portTICK_PERIOD_MS should be used to convert to real time if this is
 * required.
 *
 * @return pdTRUE if an item was successfully received from the queue,
 * otherwise pdFALSE.
 *
 * Example usage:
 * @code{c}
 * struct AMessage
 * {
 *  char ucMessageID;
 *  char ucData[ 20 ];
 * } xMessage;
 *
 * QueueHandle_t xQueue;
 *
 * // Task to create a queue and post a value.
 * void vATask( void *pvParameters )
 * {
 * struct AMessage *pxMessage;
 *
 *  // Create a queue capable of containing 10 pointers to AMessage structures.
 *  // These should be passed by pointer as they contain a lot of data.
 *  xQueue = xQueueCreate( 10, sizeof( struct AMessage * ) );
 *  if( xQueue == 0 )
 *  {
 *      // Failed to create the queue.
 *  }
 *
 *  // ...
 *
 *  // Send a pointer to a struct AMessage object.  Don't block if the
 *  // queue is already full.
 *  pxMessage = & xMessage;
 *  xQueueSend( xQueue, ( void * ) &pxMessage, ( TickType_t ) 0 );
 *
 *  // ... Rest of task code.
 * }
 *
 * // Task to receive from the queue.
 * void vADifferentTask( void *pvParameters )
 * {
 * struct AMessage *pxRxedMessage;
 *
 *  if( xQueue != 0 )
 *  {
 *      // Receive a message on the created queue.  Block for 10 ticks if a
 *      // message is not immediately available.
 *      if( xQueueReceive( xQueue, &( pxRxedMessage ), ( TickType_t ) 10 ) )
 *      {
 *          // pcRxedMessage now points to the struct AMessage variable posted
 *          // by vATask.
 *      }
 *  }
 *
 *  // ... Rest of task code.
 * }
 * @endcode
 * @cond !DOC_SINGLE_GROUP
 * \defgroup xQueueReceive xQueueReceive
 * @endcond
 * \ingroup QueueManagement
 */
BaseType_t xQueueReceive( QueueHandle_t xQueue,
                          void * const pvBuffer,
                          TickType_t xTicksToWait ) PRIVILEGED_FUNCTION;

is it removed from the Queue??? I see an infant loop.

static void _arduino_event_task(void * arg){
	arduino_event_t *data = NULL;
    for (;;) {
        Serial.println("xQueueReceive");
        if(xQueueReceive(_arduino_event_queue, &data, portMAX_DELAY) == pdTRUE){
            WiFiGenericClass::_eventCallback(data);
            free(data);
            data = NULL;
        }
    }
    vTaskDelete(NULL);
    _arduino_event_task_handle = NULL;
}

I let you decide if it deleted after it has been received... I see the data is released and the callback is completed. but the loop is still there. Don't know if there is an other callback in the make.

[podaen]

I can be wrong, but I think that loop keeps running, and that it never been properly deleted.

static bool _start_network_event_task(){
    Serial.println("_start_network_event_task");
    if(!_arduino_event_group){
        _arduino_event_group = xEventGroupCreate();
        if(!_arduino_event_group){
            log_e("Network Event Group Create Failed!");
            return false;
        }
        xEventGroupSetBits(_arduino_event_group, WIFI_DNS_IDLE_BIT);
    }
    if(!_arduino_event_queue){
    	_arduino_event_queue = xQueueCreate(32, sizeof(arduino_event_t*));
        if(!_arduino_event_queue){
            log_e("Network Event Queue Create Failed!");
            return false;
        }
    }

    esp_err_t err = esp_event_loop_create_default();
    if (err != ESP_OK && err != ESP_ERR_INVALID_STATE) {
    	log_e("esp_event_loop_create_default failed!");
        return err;
    }

    if(!_arduino_event_task_handle){
        xTaskCreateUniversal(_arduino_event_task, "arduino_events", 4096, NULL, ESP_TASKD_EVENT_PRIO - 1, &_arduino_event_task_handle, ARDUINO_EVENT_RUNNING_CORE);
        if(!_arduino_event_task_handle){
            log_e("Network Event Task Start Failed!");
            return false;
        }
    }

    if(esp_event_handler_instance_register(WIFI_EVENT, ESP_EVENT_ANY_ID, &_arduino_event_cb, NULL, NULL)){
        log_e("event_handler_instance_register for WIFI_EVENT Failed!");
        return false;
    }

    if(esp_event_handler_instance_register(IP_EVENT, ESP_EVENT_ANY_ID, &_arduino_event_cb, NULL, NULL)){
        log_e("event_handler_instance_register for IP_EVENT Failed!");
        return false;
    }

    if(esp_event_handler_instance_register(SC_EVENT, ESP_EVENT_ANY_ID, &_arduino_event_cb, NULL, NULL)){
        log_e("event_handler_instance_register for SC_EVENT Failed!");
        return false;
    }

    if(esp_event_handler_instance_register(ETH_EVENT, ESP_EVENT_ANY_ID, &_arduino_event_cb, NULL, NULL)){
        log_e("event_handler_instance_register for ETH_EVENT Failed!");
        return false;
    }

    if(esp_event_handler_instance_register(WIFI_PROV_EVENT, ESP_EVENT_ANY_ID, &_arduino_event_cb, NULL, NULL)){
        log_e("event_handler_instance_register for WIFI_PROV_EVENT Failed!");
        return false;
    }

    return true;
}

But still it is an event call that isn't called that much

Opening port
Port open
VMDPR__start_network_event_task
xQueueReceive
[ 4079][D][WiFiGeneric.cpp:854] _eventCallback(): Arduino Event: 0 - WIFI_READY
xQueueReceive
[ 4166][D][WiFiGeneric.cpp:854] _eventCallback(): Arduino Event: 2 - STA_START
xQueueReceive
[ 6467][D][WiFiGeneric.cpp:854] _eventCallback(): Arduino Event: 4 - STA_CONNECTED
xQueueReceive
[ 6469][D][WiFiGeneric.cpp:854] _eventCallback(): Arduino Event: 7 - STA_GOT_IP
[ 6472][D][WiFiGeneric.cpp:916] _eventCallback(): STA IP: 192.168.1.182, MASK: 255.255.0.0, GW: 192.168.1.1
xQueueReceive
192.168.1.182

I still can't find where the data comes in.

[podaen]

If I delete the task after the data is received I get some realy bad timings.

static void _arduino_event_task(void * arg){
	arduino_event_t *data = NULL;
    for (;;) {
        Serial.println("xQueueReceive");
        if(xQueueReceive(_arduino_event_queue, &data, portMAX_DELAY) == pdTRUE){
            WiFiGenericClass::_eventCallback(data);
            free(data);
            data = NULL;
            vTaskDelete(NULL);
            _arduino_event_task_handle = NULL;
        }
    }
    //vTaskDelete(NULL);
    //_arduino_event_task_handle = NULL;
}

Pingen naar 192.168.1.182 met 512 bytes aan gegevens:
Antwoord van 192.168.1.182: bytes=512 tijd=56 ms TTL=255
Antwoord van 192.168.1.182: bytes=512 tijd=82 ms TTL=255
Antwoord van 192.168.1.182: bytes=512 tijd=121 ms TTL=255
Antwoord van 192.168.1.182: bytes=512 tijd=133 ms TTL=255
Antwoord van 192.168.1.182: bytes=512 tijd=75 ms TTL=255
Antwoord van 192.168.1.182: bytes=512 tijd=90 ms TTL=255
Antwoord van 192.168.1.182: bytes=512 tijd=117 ms TTL=255
Antwoord van 192.168.1.182: bytes=512 tijd=127 ms TTL=255
Antwoord van 192.168.1.182: bytes=512 tijd=58 ms TTL=255
Antwoord van 192.168.1.182: bytes=512 tijd=72 ms TTL=255
Antwoord van 192.168.1.182: bytes=512 tijd=98 ms TTL=255
Antwoord van 192.168.1.182: bytes=512 tijd=121 ms TTL=255
Antwoord van 192.168.1.182: bytes=512 tijd=43 ms TTL=255
Antwoord van 192.168.1.182: bytes=512 tijd=69 ms TTL=255
Antwoord van 192.168.1.182: bytes=512 tijd=90 ms TTL=255
Antwoord van 192.168.1.182: bytes=512 tijd=135 ms TTL=255
Antwoord van 192.168.1.182: bytes=512 tijd=51 ms TTL=255
Antwoord van 192.168.1.182: bytes=512 tijd=65 ms TTL=255
Antwoord van 192.168.1.182: bytes=512 tijd=91 ms TTL=255
Antwoord van 192.168.1.182: bytes=512 tijd=117 ms TTL=255
Antwoord van 192.168.1.182: bytes=512 tijd=41 ms TTL=255
Antwoord van 192.168.1.182: bytes=512 tijd=64 ms TTL=255
Antwoord van 192.168.1.182: bytes=512 tijd=97 ms TTL=255
Antwoord van 192.168.1.182: bytes=512 tijd=140 ms TTL=255
Antwoord van 192.168.1.182: bytes=512 tijd=143 ms TTL=255
Antwoord van 192.168.1.182: bytes=512 tijd=63 ms TTL=255
Antwoord van 192.168.1.182: bytes=512 tijd=71 ms TTL=255
Antwoord van 192.168.1.182: bytes=512 tijd=100 ms TTL=255
Antwoord van 192.168.1.182: bytes=512 tijd=117 ms TTL=255
Antwoord van 192.168.1.182: bytes=512 tijd=45 ms TTL=255
Antwoord van 192.168.1.182: bytes=512 tijd=71 ms TTL=255
Antwoord van 192.168.1.182: bytes=512 tijd=88 ms TTL=255
Antwoord van 192.168.1.182: bytes=512 tijd=125 ms TTL=255
Antwoord van 192.168.1.182: bytes=512 tijd=144 ms TTL=255
Antwoord van 192.168.1.182: bytes=512 tijd=52 ms TTL=255
Antwoord van 192.168.1.182: bytes=512 tijd=72 ms TTL=255
Antwoord van 192.168.1.182: bytes=512 tijd=98 ms TTL=255
Antwoord van 192.168.1.182: bytes=512 tijd=136 ms TTL=255
Antwoord van 192.168.1.182: bytes=512 tijd=47 ms TTL=255
Antwoord van 192.168.1.182: bytes=512 tijd=75 ms TTL=255
Antwoord van 192.168.1.182: bytes=512 tijd=82 ms TTL=255
Antwoord van 192.168.1.182: bytes=512 tijd=210 ms TTL=255
Antwoord van 192.168.1.182: bytes=512 tijd=32 ms TTL=255
Antwoord van 192.168.1.182: bytes=512 tijd=42 ms TTL=255
Antwoord van 192.168.1.182: bytes=512 tijd=67 ms TTL=255
Antwoord van 192.168.1.182: bytes=512 tijd=93 ms TTL=255
Antwoord van 192.168.1.182: bytes=512 tijd=103 ms TTL=255
Antwoord van 192.168.1.182: bytes=512 tijd=141 ms TTL=255
Antwoord van 192.168.1.182: bytes=512 tijd=51 ms TTL=255
Time-out bij opdracht.
Antwoord van 192.168.1.182: bytes=512 tijd=96 ms TTL=255
Antwoord van 192.168.1.182: bytes=512 tijd=114 ms TTL=255
Antwoord van 192.168.1.182: bytes=512 tijd=34 ms TTL=255
Antwoord van 192.168.1.182: bytes=512 tijd=58 ms TTL=255
Antwoord van 192.168.1.182: bytes=512 tijd=85 ms TTL=255
Antwoord van 192.168.1.182: bytes=512 tijd=115 ms TTL=255
Time-out bij opdracht.
Antwoord van 192.168.1.182: bytes=512 tijd=57 ms TTL=255
Antwoord van 192.168.1.182: bytes=512 tijd=82 ms TTL=255
Antwoord van 192.168.1.182: bytes=512 tijd=109 ms TTL=255
Antwoord van 192.168.1.182: bytes=512 tijd=118 ms TTL=255
Antwoord van 192.168.1.182: bytes=512 tijd=50 ms TTL=255
Time-out bij opdracht.

[podaen]

Forgot to set a break

[SuGlider]

@podaen -

Is this issue about ping reaction time?
What is the network topology for this testing? Just a PC + WiFi Router and ESP32 all in WLAN?

[podaen]

yes ping, yes wlan.

[SuGlider]

OK, Ping wil be processed by ESP32 Cores along with all other tasks and peripherals ISRs.
It will fluctuate for sure when the core where LWIP is being processed is busy with something else.

I think that more important than the ping response time is how the main application performance is doing.
For instance, each LOG on serial port consumes a lot of CPU time for instance.
At the end this is just an MCU with very limited resources.
It's hard to evaluate the performance of a Network Aplication based on Ping Time Response from ESP32.

[SuGlider]

I propose a different topology:

Esp32 in AP mode and another in STA mode. One connected to each other.
No Router, no PC.

Ping times are now stored in a array (no DBG printing when getting ping times).

STA pings AP.
After 1.000 pings, the sketch prints results and statistics such as longest time, shortest times, average time, median time, success %, number of packets lost and so on.

This may give you a better and cleaner perspective.

[podaen]

Yeah, it would be a proper way to test it more precice, but hunderd ms for serial monitor once arround the few minutes? According to me it could be done more fluwedly. Normally the pings are really amazing for such little resources.

[podaen]

Esp32 in AP mode and another in STA mode. One connected to each other.
No Router, no PC.

Hmmm, strange... I see delays of 100ms when I ping from my pc to the dns server too. @SuGlider I will try like you advice me. It blows my mind now.

[Jason2866]

The issue is related ONLY to a ESP32. Tested with a ESP32-solo1 and i had never a Ping >15ms. Most was always around 6ms. Not a single timeout.

[podaen]

When pinging with a computer with a high data consumption it causes a delay. That was the reason why it took so long to get there.