I am using WLED version 0.11.0 on a Wemos D1 Mini. I compiled it on the Arduino IDE because I needed to modify the data pin and relay control pin. When set to ping the device from my computer it results in about 40% timeouts when running the WLED software, I don’t have any MQTT, Blynk or other controls enabled. I upload a different sketch to the D1 Mini and WiFi is rock solid so there is nothing wrong with the device or my network. It seems that the D1 Mini just may not have enough horsepower to properly run this, any advice? Am I doing something wrong? Same behavior whether I am controlling lights or not.
Just an update: I have tried my recompiled code and installed on various different Wemos D1 Mini, D1 Pro, D1 with the same effect. To rule out something in my recompiled code I also installed the ESP8266 binary with essentially the same effect. It definitely drops many pings and even doesn’t respond occasionally to ARP requests which result in destination not reachable messages. Is no one else seeing this behavior?
I had a similar issue with poor ping times (~250 msec) on an ESP32 using E1.31. You might want to try to “Disable WiFi sleep” at the bottom of the WiFi Setup page to see if that improves performance.
I just tried that and it made it worse. For clarity. Checking the “Disable WiFi sleep” box made the wifi performance worse and in fact also seemed to mess up the segment configuration after making the change and pressing “save and connect” button.
Hmm, well that is strange. As far as I know, the checkbox just ensures that the WiFi doesn’t go into sleep mode to save power. How many LEDs are you trying to control with one microcontroller? Are you just using the built-in effects, or are you utilizing E1.31?
I personally have controlled 400 LEDs with one D1 Mini (using built-in effects). I am also controlling two sets of 576 LEDs with two ESP32’s via E1.31.
Also, did you look at the wiki w.r.t. which pins are recommended (if not using D4). This article also has some great info on do/don’t pins:
May be due to not using the recommended pin?
If you use a pin that requires bit-banging, performance will suffer on the strip, or on the wifi when there are many LEDs to keep updated.
If you set the number of configured LEDs to half of whatever you have now, does wifi performance improve?
My configuration is a single string of 100 lights split into 2 segments. 0-50 and 50-100. The Pin I am using is D6 or GPIO12 which is a recommended pin for SPI as far as I know. No matter which pin you choose it will be bit banged on an ESP8266 I believe. I am only using 3 internal effects but even if I don’t have any effects configured or even turned on the performance is poor. I am not using any external connections, it just seems it isn’t able to loop fast enough to keep wifi solid. The Disable Wifi thing above messing up the config was my mistake, didn’t realize that segments were not stored in the cfg.json file and were only part of presets.
I installed the base binary with the recommended pins and same result.
Not sure if this would matter, but your second segment should be 51-100, not 50-100. 50 is already used by the first segment.
Do you have any other WLED controllers working OK?
What kind of AP/router are you using?
I have played with the segments as well and it make no difference, even with a single segment. I have only the one WLED controller but have tried the same software on 5 different boards to rule out a board issue. My APs are Amplifi HD but again I can run other software on the ESP8266 and the wifi performance is rock solid. Same hardware, same APs…I am going to time the loop function using a scope as I really think it is just taking too long to do everything to properly service the wifi/ethernet routines.
Hmm…For some reason, I think I remember reading something about Ubiquiti’s Amplifi and WLED wifi performance issues. I’ll do a little searching to see if I can find it, or verify I’m going crazy. 
I will do the same. I have no less than about 10 other ESP8266 devices running on my network with no wifi performance issues though so I doubt that is the problem.
If that is the case, I agree. I’ll settle for crazy. 
So I reread this thread. You indicate that your getting poor WiFi performance from ping times. The effects that you’re running are all local on the micro-controller, so even if WiFi dropped out why would that affect performance of the micro-controller running local code? Only thing I could think of is that another process is overtaxing the processing capabilities of the board (e.g., WiFi connect tries). Does this make sense to you? Is this micro-controller in a location with poor WiFi performance? Is the Amplifi system trying to get the D1 mini to switch to the 5 GHz band? Just a few thoughts from an apparent crazy person.
To be clear it does not seem to effect the performance of the LEDs, it does affect performance of the web interface and the app interface as it times out many times and this correlates to the ping performance.
Ah, OK. Thanks for the clarification.
My ping times to ESP8266 on a different subnet while WLED is running an effect on 50 LED string.
Thanks for that. The mystery deepens on my side. I only see the issue when running WLED. Thanks!
Reply from 192.168.135.232: bytes=32 time=13ms TTL=128
Request timed out.
Request timed out.
Reply from 192.168.135.232: bytes=32 time=217ms TTL=128
Reply from 192.168.135.232: bytes=32 time=82ms TTL=128
Reply from 192.168.135.232: bytes=32 time=79ms TTL=128
Request timed out.
Reply from 192.168.135.232: bytes=32 time=44ms TTL=128
Reply from 192.168.135.232: bytes=32 time=135ms TTL=128
Reply from 192.168.135.232: bytes=32 time=3ms TTL=128
Reply from 192.168.135.232: bytes=32 time=2ms TTL=128
Request timed out.
Request timed out.
Reply from 192.168.135.232: bytes=32 time=3ms TTL=128
Reply from 192.168.135.232: bytes=32 time=3ms TTL=128
Reply from 192.168.135.232: bytes=32 time=4ms TTL=128
Reply from 192.168.135.232: bytes=32 time=3ms TTL=128
Reply from 192.168.135.232: bytes=32 time=14ms TTL=128
Reply from 192.168.135.232: bytes=32 time=36ms TTL=128
Reply from 192.168.135.232: bytes=32 time=60ms TTL=128
Request timed out.
Reply from 192.168.135.232: bytes=32 time=16ms TTL=128
Ping statistics for 192.168.135.232:
Packets: Sent = 1555, Received = 1195, Lost = 360 (23% loss),
Approximate round trip times in milli-seconds:
Minimum = 2ms, Maximum = 417ms, Average = 37ms
This is what I am currently seeing.
