esp_wifi_repeater
esp_wifi_repeater copied to clipboard
martin-ger
ESP8266 NAT Router: Very low throughput
First of all, thank you for your contributions and projects.
I implemented the NAT router in several ESP8266 (three ESP-01 and one NodeMCU), but I saw the same problem: a throuput of approximately 0.7 Mb / s (Speedtest) in an Internet of approximately 9.35 Mb / s. Sometimes I got a good transfer rate of approximately 5.8 - 6 Mb / s but after a reset the same problem happens again. I've tried it with various networks (Internet of 9Mb / s, an android AP from LTE of 15 Mb / s) and the same thing always happens. I modified the clock speed from 80 to 160Mhz but it doesn't work. Do you think it could be a problem in the firmware? Thank you a lot for the answer (and apologies for my english.) Best regards.
Roman.
Other measurements have shown, that the performance can be much better. Problems may occur with buffer space: if too many packets come in at the same time, the repeater has to drop packets. In a TCP session this will cause, timeout and retransmission which reduces thoughput drastically. Could you have a look into the debug output on the serial console?
"NAT table full" means: too many connections at the same time (or in the last seconds). Currently there is limit of 512 entires in that table and I already drop NAT-entries earlier than the RFC suggests. Under "normal" load this rarely happens. Increasing that by a factor of 2 or 4 would be possible, but requires a recompilation of open-lwip.
"LmacRxBlk:1" means: no more WiFi receive buffer. Simply too much load, it cannot send out quickly enough. Currently, I don't know, where to increase that number, but it won't really solve that problem, as limited buffering doesn't really fight permanent overload.
So: yes, there are limitations, when you only have 48KB of RAM. My (and many users) experience is: with "normal" client activities it works acceptable and for IoT devices it is nearly perfect.
I'm wondering if it would be possible to avoid these "overload" situations by deliberately throttling client connections? For example, if you could rate-limit each client to say 500kbps, would that have any impact on reducing these problems?
If so I think it's easier for a client to work with a consistent (if low) amount of bandwidth, although I don't know enough about how this works yet to know if doing this would have any bearing on addressing these issues.
Thanks for answering, Martin. On the serial LOG only appeared "LmacRxBlk: 1" (too much load) but for now it is working correctly. I will analyze the log if the BW is reduced again. Regards!
Throttling clients is not that easy. There are two options on the network layer (where we are):
- dropping packets, if the limit is reached. That is what my basic bit rate limiter does (for the traffic of all clients). But this is nearly the same effect on TCP connections as the implicit dropping caused be "LmacRxBlk: 1".
- delaying packet delivery: one could think of storing (the first or all packets) above the limit and forwarding them in the next time slot. This would slow down TCP, but not cause timeouts and retransmissions when the slots are short enough. But this requires buffer space in a situation, when buffers are tight anyway and a some additional time-outs in IP. Both seems to be not an ideal solution.
I met the same problem here. Is it possible to add an extra 23lc1024 SPI RAM and get better performance?
Don't think, that this will make a major improvement. How fast can this RAM bei? Also lwip Buffet-Managemen hast to bei re-written.
As @devyte mentioned in https://github.com/martin-ger/esp_wifi_repeater/issues/40#issuecomment-366356636_ this might be a lwip1.4 issue.
There is a similar project for ESP32 which uses the newer SDK (idf) and also newer lwip. I tried it on ESP8266 (using the new FreeRTOS SDK which supports idf style) and could successfully compile and run it on a NodeMCU, but unfortunately there is no internet connection, even though the ESP8266 connects to the router.
More details: https://github.com/jonask1337/esp-idf-nat-example/issues/18
Interesting issue. I to am seeing this with attempting to to http ota via the nat repeater to ESP32 remote devices. Im wonder if changing some of the parameters in LWIP might help such as tcp_wnd and tcp_mss...
or perhaps changing the wifi mode to 11b, and/or wifi rate to 1mb? P
Update: I changed the LWIP version I am using on my sensor devices (ESP32) to low memory version. https://docs.platformio.org/en/latest/platforms/espressif8266.html#lwip-variant
I can do ESP http OTA via the Nat repeater now without the time-outs I was getting before. I still see a few "LmacRxBlk:1" on the Nat debug. but it works! P
@Cloolalang: Can you share your code? Or even better merge into this repo here?
