MicroPython Forum (Archive)

I have been having problems with wifi latency sometimes dropping 10-20 seconds. I am sending packets every 100 milliseconds, and more than 500 is considered "time out" I have tried several images with different compiler settings, including official images. Is it known that wifi is not working at its potential?

First I changed my access point settings in hostapd.conf. I lowered dtim_period=1 and this made a big difference for the esp32 despite not really affecting other devices. I wonder if the esp32 would not need this and could work with slower beacons (lower sleep power) if the driver were modified?

I found with tcp sockets and low through put of 100-200 bytes/s, the driver gets "stuck" and sometimes read (nonblocking) gives no data for 20-30 seconds, then all the data arrives (none is lost). I reduced the number of wifi buffers in menuconfig and this seemed to help this problem but it is still there, and can get stuck up to 10 seconds even with the minimum number of buffers of 2 (0 dynamic)

The data is stuck long enough that after 2 seconds it's faster to reset wifi and reconnect which leads to making new sockets, eventually os error 23 occurs and I have to reset the processor before I can make any more sockets. socket.close() apparently does not fully relinquish them.

When I close the tcp socket from the remote, no exception is thrown so that micropython code is aware of broken connections. I am forced to timeout on data. send and recv don't work properly for detecting broken connections either. I found uselect.poll does not produce socket error and hangup events.

Using udp sockets did not reduce latency but at least the connection never gets "stuck" so I am forced to use udp sockets where normally tcp sockets would also work ok. Despite this, sometimes even udp packets are delayed by over a second.

Any suggestions for micropython settings or in general what can be done to get low latency low bandwidth wifi working?

WiFi running on bare metal doesn't provide a reliable low-latency connection. See this doc. In my experience, even under "next room" conditions, numerous (~ once an hour) outages occur. PC operating systems hide this, giving the impression that WiFi is more stable than actually is the case.

I suspect that there are multiple issues you may be facing. I've been running an MQTT reliability test for 2-1/2 weeks now that sends an MQTT message round-trip over a TLS connection. So far it has logged 50 reconnections and exchanged over 2 million round-trip messages. I see a couple of round-trip times over 5 seconds every hour or two. Here's how it looks (light blue line): From what I can tell the two sources of problems are the wifi link (rf stuff) and memory constraints.
If there is interference or another problem at the wifi level (for example, deciding to switch to a higher data rate and not getting packets through anymore) then there will be delays caused by lost packets. You're then at the mercy of the wifi layer fixing stuff, for example by switching to a lower data rate, and the TCP layer fixing stuff by retransmitting. As Peter mentioned, laptops and phones have more cycles and memory and react faster to this.
In addition, MicroPython snatches most of the memory leaving just a minimum to the ESP-IDF. I suspect that most of the 50 reconnections I've seen in my test are due to esp-idf running out of memory. E.g., when there are RF problems it may need more memory to retransmit packets or to process an incoming burst. That's a suspicion right now, but I have very definitely debugged scenarios where wifi drops completely and is then reconnected from scratch all due to running out of memory. I want to restart my reliability test with a version that leaves more memory to esp-idf to confirm whether my suspicion is correct or not.

tve wrote: ↑

Mon Jun 22, 2020 4:40 pm

...I have very definitely debugged scenarios where wifi drops completely and is then reconnected from scratch all due to running out of memory. I want to restart my reliability test with a version that leaves more memory to esp-idf to confirm whether my suspicion is correct or not.

That is a very significant observation. Good luck with getting to the bottom of that.

Do I take it that it has run for 2.5 weeks without a crash/WDT reboot?

pythoncoder wrote: ↑

Wed Jun 24, 2020 11:04 am

Do I take it that it has run for 2.5 weeks without a crash/WDT reboot?

Yup, uptime on both the reliability test baord and my weather station (which has much more activity but was last reprogrammed a day later) has been perfect so far.

Impressive. My board crashes every day but maybe it's due to bad spiram but I never went looking for the reason using the stacktrace..