Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WiFi slow down when pushing it hard. #8292

Closed
6 tasks done
sblantipodi opened this issue Aug 25, 2021 · 6 comments
Closed
6 tasks done

WiFi slow down when pushing it hard. #8292

sblantipodi opened this issue Aug 25, 2021 · 6 comments
Assignees

Comments

@sblantipodi
Copy link

Basic Infos

  • This issue complies with the issue POLICY doc.
  • I have read the documentation at readthedocs and the issue is not addressed there.
  • I have tested that the issue is present in current master branch (aka latest git).
  • I have searched the issue tracker for a similar issue.
  • If there is a stack dump, I have decoded it. -> No stuck dump since there is no error
  • I have filled out all fields below.

Platform

  • Hardware: [ESP8286 device]
  • Core Version: 3.0.2
  • Development Env: Platformio
  • Operating System: Windows/Ubuntu

Settings in IDE

  • Module: Wemos D1 mini
  • Flash Mode: PlatformIO default
  • Flash Size: 4MB
  • Flash Frequency: [40Mhz]
  • CPU Frequency: 160MHz
  • Upload Using: OTA and Serial
  • Upload Speed: 115200

Problem Description

Hi all,
I am experiencing strange WiFi slow down after some time the ESP has been booted.

My ESP8266 is connected to WiFi with the standard code you can find on your examples and is receiving UDP messages with the code posted below.

UDP stream happens at 60 msg per seconds and it seems that ESP8266 can handle that stream for minutes but sometimes, randomly after a lot of minutes, ESP8266 is not able to handle 60 msg per second anymore and it drop its capability to 30 msg per second and then to 2 or 3 message per second.

I searched for something that can cause heap fragmentation in my code but there is no part of the code that can cause severe heap fragmentation. No String class used, params are passed by reference, no global vars, all variables has short live in their scope...

I have a special command in my code that forces the ESP to disconnect from the WiFi and reconnect to it.
If I disconnect the ESP from the wifi with
WiFi.disconnect();
and then reconnect, the slow down is solved completely until the next time it happen.

I have checked the free heap when the problem happen and it does not change, while streaming at full speed the free heap is around 24Kb, when the problem happen the free heap is still at 24Kb.

Here you can find a very stripped code to reproduce the problem.

Easyest code possible to reproduce the problem

#include <ArduinoJson.h>
#include <ESP8266WiFi.h>
#include <ESP8266mDNS.h>
#include <WiFiUdp.h>
#include <FastLED.h>
#include <NeoPixelBus.h>
#include <NeoPixelAnimator.h>

const char *ssid = "XXX";
const char *password = "XXX";
#define serialRate 500000
#define NUM_LEDS 95
#define PIN 2
#define UDP_PORT 4210
WiFiUDP UDP;
const uint16_t UDP_MAX_BUFFER_SIZE = 4096;
char packet[UDP_MAX_BUFFER_SIZE];
uint8_t col = 0;
float framerateCounter = 0;
float framerate = 0;

NeoPixelBus<NeoGrbFeature, NeoEsp8266Uart1800KbpsMethod> *ledsUART = NULL;

WiFiClient espClient;

void setup_wifi() {
  delay(10);
  // We start by connecting to a WiFi network
  Serial.println();
  Serial.print("Connecting to ");
  Serial.println(ssid);
  WiFi.mode(WIFI_STA);
  WiFi.begin(ssid, password);
  while (WiFi.status() != WL_CONNECTED) {
    delay(500);
    Serial.print(".");
  }
  Serial.println("WiFi connected");
  Serial.print("IP Address: ");
  Serial.println(WiFi.localIP());
  // NeoPixelBus init
  Serial.println("Using UART");
  if (ledsUART != NULL) {
    delete ledsUART;
  }
  ledsUART = new NeoPixelBus<NeoGrbFeature, NeoEsp8266Uart1800KbpsMethod>(NUM_LEDS, PIN);
  if (ledsUART == NULL) {
    Serial.println("OUT OF MEMORY");
  }
  while (!Serial); // wait for serial attach
  Serial.println();
  Serial.println("Initializing...");
  Serial.flush();
  ledsUART->Begin();
  ledsUART->Show();
  // UDP init
  UDP.begin(UDP_PORT);
  Serial.print("Listening on UDP port ");
  Serial.println(UDP_PORT);

}

void setup() {
  Serial.begin(serialRate);
  setup_wifi();
}

void ledShow() {
  ledsUART->Show();
}

void setPixelColor(uint16_t index, uint8_t r, uint8_t g, uint8_t b) {
  ledsUART->SetPixelColor(index, RgbColor(r, g, b));
}

void setColor(uint8_t inR, uint8_t inG, uint8_t inB) {
  for (uint8_t i = 0; i < NUM_LEDS; i++) {
    setPixelColor(i, inR, inG, inB);
  }
  ledShow();
}

void loop() {
  if (WiFi.status() != WL_CONNECTED) {
    delay(1);
    Serial.print("WIFI Disconnected. Attempting reconnection.");
    setup_wifi();
    return;
  }
  uint16_t packetSize = UDP.parsePacket();
  // As you can see here, the received packet is not used for semplicity but if it is received fast enough it should create a breath effect
  if (packetSize > 20 && UDP.read(packet, packetSize) == packetSize) {
    packet[packetSize] = '\0';
    if (col > 125) {
      col = 0;
    }
    col++;
    setColor(0, col, col);
    framerateCounter++;
  }
  EVERY_N_SECONDS(10) {
    framerate = framerateCounter > 0 ? framerateCounter / 10 : 0;
    framerateCounter = 0;
    Serial.printf("framerate:%f\n", framerate);
  }
}

Debug Messages

No debug msg because there is no error, only a very very strange slow down.

  Serial.println(ESP.getFreeHeap());
  Serial.println(ESP.getHeapFragmentation());
  Serial.println(ESP.getMaxFreeBlockSize());

those lines returns respectively:

  • 26208
  • 2
  • 25728
    those values are more or less the same for the entire execution of the program, even during the slown down problem.

Max heap fragmentation value is 4. So heap fragmentation, should not be the cause.

Software used to send UDP packet

I have a java software that sends the UDP packet but for simplicity I'm testing with the well known
https://packetsender.com

image

The string I am sending is something like this:

255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232,255,253,0,243,232
@d-a-v d-a-v self-assigned this Aug 25, 2021
@sblantipodi
Copy link
Author

@d-a-v thanks for taking time to assign this issue.
if you need some extra infos, I'm here ready to answer and to try to troubleshoot the problem. thank you very much.

I add some more bits...
It could take 2 minutes or two hours to reproduce. The problem often happen in the first 30 minutes...
If it could help, I disabled all the firewalls, ddos protection, QoS on my router, it's a good Asus AX56U.

Thank you very much.

@Jason2866
Copy link
Contributor

We have often users in Tasmota Discord having wifi connect / disconnect problems with Asus and Ubiquiti routers. Other router brands does make no problems. It seems it is related.

@TD-er
Copy link
Contributor

TD-er commented Aug 31, 2021

Your code does only handle UDP packets when the WiFi status shows it is connected.
However, it is a known bug that this state does not always reflect the actual state.

Can you test in your setup to handle UDP packets when available, regardless the connected state?
Just don't try to send packets, only receiving.

@sblantipodi
Copy link
Author

sblantipodi commented Aug 31, 2021

@TD-er thank you all for the answers, really appreciated it since I'm spending a lot of time behind this issue.
tried it but the slow down problems remains.

what I described in this issue is not a disconnection problem but a slow down one.
ESP remains connected but at a very slow speed.

PS: I have even disconnection problems that happen from time to time but not so often and I confirm that I still can't detect disconnections if not with some workaround, but this is another story.

When the slow down problem happen I'm sure that it is connected since I can still read some messages from UDP or TCP...

@TD-er
Copy link
Contributor

TD-er commented Sep 1, 2021

What happens if you send a ping (from any host in your network) to the ESP while testing this?

@sblantipodi
Copy link
Author

hi guys, after two weeks or swearing I finally discovered what was my problems of the ESP8266 slow down.

it was the damn router.

An Asus AX56U gigabit ethernet that runs well my gigabit internet.
After the latest firmware upgrade something broke, I tried reverting to the old firmware but that something remained broken.

After a full wipe of the router and a manually reconfiguration now it works like a charm, like before.
Thank you all for the support and sorry if I opened an issue on something that isn't your problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants