WiFiWebServer latency

BW16
1

Hello.
Just started investigating what BW16 is about, managed to make it work instantly!

For now I have only one concern - latency.

Using WiFiWebServer example, I modified it just a bit for the response to be:

  client.println("HTTP/1.1 200 OK");
  client.println("Content-Type: text/plain");
  client.println("Connection: close");  // the connection will be closed after completion of the response
  client.println();
  client.println(text);

Using postman, I started to send requests to the mcu. Using 5.8G LAN.
Usual latency is around 40-50ms. Sometimes it becomes something around 150ms.

The questions are the following: is it the best we can get? What do these 150ms spikes mean?

Having some esp32 experience in the same field, I tried to disable all the powersafe modes, all the sleep modes and so on. No success. Noting changed no matter what.

The most promising function was

wifi_disable_powersave();

but still no changes detected.

For now I don’t care about power consumption much, so would appreciate any advice in terms of how to make it as stable and responsive as possible. Thanks.

2

Hi @nyancat

I am not familiar with postman, can you provide more details on this and how you are testing and measuring?

3

Postman is a software to debug requests. Used in web development often.

It gives such an output.

image
image778×486 24.5 KB

According to my notes about testing esp32 a while ago, measuring the same way, minimal total latency was 19ms.

Btw, using curl in linux console, it shows around 26ms

image
image1230×144 16.7 KB

Lets compare these numbers relatively to each other 16ms and 40-50ms.

So with esp32 it was possible to receive the response it 2-3 times faster.

So I would like someone to share his experience about speeding it up.

With esp32 it was about disabling powersave in multiple ways and increasing clock frequency.

What options could be there with with BW16? The only thing I found is

wifi_disable_powersave();

which does not change anything.

4

Ok, so first thing to mention: I managed to decrease the latency to 20-something ms by disabling postman default headers that i don’t actually need.

image
image1476×392 27.9 KB

But there is a much more interesting thing that I noticed:

image
image2590×742 169 KB

After commenting out these printf lines I managed to decrease the latency up to 10ms!

And I don’t see any options to avoid unwanted serial output which takes a lot of time! Please let me know if there are any options to disable these debug messages without modifying the libs.

Ok. I returned those 2 printf()s and created a basic script with a loop that sends curl requests (100 requests with 50ms delay) :

image
image196×816 18.7 KB

Talking about this screenshot:

First request in a series takes much more time. After the first one it is pretty stable. If I restart the loop right after the previous execution gets finished - it keeps being stable. If I make a 5s pause - again the first request takes much more time.
Is MCU sleeping or something if not receiving requests for a while? Is it possible to make it stably responsive no matter when was the last time it received a request?

Again as described above, with esp32 I managed to avoid spikes and minimise the latency by disabling powersave, but not with BW16 :frowning:

At the same time I should mention that after running a 1000 requests - no packages lost, comparing to esp32 where I constantly have around 3/1000 lost.

Also BW16 does not heat at all, especially comparing with esp32 which becomes ultimately hot pretty fast no matter which esp32 module I use.

None are the current BW16 issues are critical for me, but still would be really nice to deal with these small problems never to think about them again.

And sorry if I’m using the wrong terms, I’m not a huge expert.

5

I would suggest looking through the Powersave and WiFi chapters of AN0400 Application Note.

What you are describing sounds like the WiFi powersave feature to me, where WiFi drops into a low power state when there is no data transmission going on. Thus the first transmission will take more time as it waits for WiFi to return to normal.

image
image793×422 35.3 KB

However, wifi_disable_powersave(); should turn off this feature.
Another possibility is FreeRTOS tickless mode, which puts the processor into a low power state when there are no tasks running. You might want to look into this aspect.

Regarding the printf lines, if you do not wish to change the code, increasing the Serial port baud rate to the max of 2M baud should help to reduce the time spent on waiting for UART transmission.

1 Like