there has been already a question about tcp throughput here:
https://esp32.com/viewtopic.php?t=126
however, no one gives a method (either software or hardware) to improve the speed. While someone can get 10Mbyte/sec, My ESP32 wrover-kit still gives around 200KByte/sec!!!!
I test using iperl from newest version of IDF, AP server mode: receive
hope company will have a look and propose a solution
thanks in advance for any idea
TCP throughput: How can speed up
Re: TCP throughput: How can speed up
Besides idf/examples/performance/tcp_perf ( which gives around 1.8Mbit/sec, I used also idfexamples/wifi/iperf) and did as the manual "readme". weirdly, I got ~ 8Mbit/sec!!!. The result is highly different from the "examples/performance/tcp_perf"
could any one give e an explanation and how can I make tcp_perf get the high above speed?
could any one give e an explanation and how can I make tcp_perf get the high above speed?
Re: TCP throughput: How can speed up
I am wondering the same question. Like I am sure many people new to the ESP, you are here for a project or business need and you want to quickly evaluate if the ESP is the part you want or if you should just keep looking. So you run some of the examples and get different results. Iperf makes it look fast. But the quick start examples in say Arduino make it look slow. The unanswered (I have seen multiple posts on this but no answer) question leads some to think the part is buggy or otherwise impractical for their project and they move on.
After reading about this for weeks I have come to the conclusion that the inconsistent results are more likely to occur if you want to keep sending packets. If you just do a short test with one of the quick start examples, it looks fast. But apparently, many applications want to send more data than just a brief burst. And this then leads to the impression that the part is buggy, inconsistent, the user base doesn't know what to do about it, Espressif is silent, etc. All "yellow flags" to move on to another part.
This only happens if you are doing a quick start and you want to send consistent stream of data. Even small but consistent data stream then become a problem and connecting with say Bluetooth looks more attractive. Just wire up a HC-05 ($1.53 on ebay) and you now have consistent, low latency communication.
I think the problem is with the tx/rx buffer size. The quick start example buffer size is too small, and this scares some people away from the part. If you do the iperf example in the IDF-SDK, the sdkconfig file (changed through make menuconfig) has larger buffers and so you get these impressive results (about 20mb/s). But if you do the quick start examples, it sucks and the lack of information explaining why it sucks just appears to be yellow flag and some people just move on.
Not a problem if you don't care about the fringe developers. People whose day jobs are all the things that connect to a processor and not just the processor itself. Things that pay for that processor. These are people who aren't hardcore on uC development and even the IDF examples are too much work. They try the Arduino example, see a problem. ask, people say "its great, look at iperf"), they spend more time than they wanted getting IDF to work (much more than they initially thought when it was just Arduino) and the result seem inconsistent and the explanations like that of some arcane developer experience or a buggy part. This is fine with a new part, sorts out the riff raff, but prices are going to come down for everyone if more people use this part. And this means letting in the unwashed masses. Simple solution for this common question about wi-fi throughput? make the quick start examples consistent with the claims. people come, they try the part out, it does what is says, they stick around and learn more about it. Community grows. prices come down. code library increases.
After reading about this for weeks I have come to the conclusion that the inconsistent results are more likely to occur if you want to keep sending packets. If you just do a short test with one of the quick start examples, it looks fast. But apparently, many applications want to send more data than just a brief burst. And this then leads to the impression that the part is buggy, inconsistent, the user base doesn't know what to do about it, Espressif is silent, etc. All "yellow flags" to move on to another part.
This only happens if you are doing a quick start and you want to send consistent stream of data. Even small but consistent data stream then become a problem and connecting with say Bluetooth looks more attractive. Just wire up a HC-05 ($1.53 on ebay) and you now have consistent, low latency communication.
I think the problem is with the tx/rx buffer size. The quick start example buffer size is too small, and this scares some people away from the part. If you do the iperf example in the IDF-SDK, the sdkconfig file (changed through make menuconfig) has larger buffers and so you get these impressive results (about 20mb/s). But if you do the quick start examples, it sucks and the lack of information explaining why it sucks just appears to be yellow flag and some people just move on.
Not a problem if you don't care about the fringe developers. People whose day jobs are all the things that connect to a processor and not just the processor itself. Things that pay for that processor. These are people who aren't hardcore on uC development and even the IDF examples are too much work. They try the Arduino example, see a problem. ask, people say "its great, look at iperf"), they spend more time than they wanted getting IDF to work (much more than they initially thought when it was just Arduino) and the result seem inconsistent and the explanations like that of some arcane developer experience or a buggy part. This is fine with a new part, sorts out the riff raff, but prices are going to come down for everyone if more people use this part. And this means letting in the unwashed masses. Simple solution for this common question about wi-fi throughput? make the quick start examples consistent with the claims. people come, they try the part out, it does what is says, they stick around and learn more about it. Community grows. prices come down. code library increases.
Re: TCP throughput: How can speed up
kbaud1,
deeply appreciate for your rep.
As you mentioned, we cared the specs of MCU from document only and picked it. Unfortunately, there were a few reviews about performance at that time.
Now, besides throughput, we also face the other problems such as the stability when running bluetooth and wifi simultaneously, I2C module's break without reason,etc.... It really is a tough time because we 've already achieved so switching to another core is similar to giving up all.
about tx/rx buffer, I also modified them following the quick start iperf example (i work on IDF and am able to touch menuconfig), but it still is so. Therefore, I strongly guess that the problem locates at a deeper class or at least, the modification in menuconfig doesnt embrace the root as it is expected
We tried to reach esp by calling and get promises that they will fix those (but not defined time) !!!!
deeply appreciate for your rep.
As you mentioned, we cared the specs of MCU from document only and picked it. Unfortunately, there were a few reviews about performance at that time.
Now, besides throughput, we also face the other problems such as the stability when running bluetooth and wifi simultaneously, I2C module's break without reason,etc.... It really is a tough time because we 've already achieved so switching to another core is similar to giving up all.
about tx/rx buffer, I also modified them following the quick start iperf example (i work on IDF and am able to touch menuconfig), but it still is so. Therefore, I strongly guess that the problem locates at a deeper class or at least, the modification in menuconfig doesnt embrace the root as it is expected
We tried to reach esp by calling and get promises that they will fix those (but not defined time) !!!!
Re: TCP throughput: How can speed up
Hi,
There are a number of LWIP & WiFi configuration settings that trade off memory use vs network throughput. The defaults are a compromise somewhere in the middle, but the iperf example sets a number of these to the "throughput" end:
https://github.com/espressif/esp-idf/bl ... g.defaults
You can copy this file as a brand new "sdkconfig" for your project, to get these values to begin with.
You can read descriptions of each item here, or by highlighting the item and pressing "?" in menuconfig:
http://esp-idf.readthedocs.io/en/latest ... html#wi-fi
http://esp-idf.readthedocs.io/en/latest ... .html#lwip
There's no "secret sauce" in the iperf code, the source code is all there and it uses the same WiFi libraries as the rest of ESP-IDF.
Regarding throughput of a particular application, like most things with performance tuning the devil is in the details: What is the data transfer pattern? What else is the app doing? What CPU cores are in use on the ESP32? What AP is in use? What is the other end of the TCP connection doing? etc, etc.
Taking Wireshark packet captures on the server can sometimes help see what's happening: if there are problems with window size or dropped packets, etc.
If you can share your code then there may also be some suggestions we can make.
There are a number of LWIP & WiFi configuration settings that trade off memory use vs network throughput. The defaults are a compromise somewhere in the middle, but the iperf example sets a number of these to the "throughput" end:
https://github.com/espressif/esp-idf/bl ... g.defaults
You can copy this file as a brand new "sdkconfig" for your project, to get these values to begin with.
You can read descriptions of each item here, or by highlighting the item and pressing "?" in menuconfig:
http://esp-idf.readthedocs.io/en/latest ... html#wi-fi
http://esp-idf.readthedocs.io/en/latest ... .html#lwip
There's no "secret sauce" in the iperf code, the source code is all there and it uses the same WiFi libraries as the rest of ESP-IDF.
Regarding throughput of a particular application, like most things with performance tuning the devil is in the details: What is the data transfer pattern? What else is the app doing? What CPU cores are in use on the ESP32? What AP is in use? What is the other end of the TCP connection doing? etc, etc.
Taking Wireshark packet captures on the server can sometimes help see what's happening: if there are problems with window size or dropped packets, etc.
If you can share your code then there may also be some suggestions we can make.
Re: TCP throughput: How can speed up
Dear,
I use tcp_perf test from idf( example/performance) without modification and send continuously data to another laptop(access into the AP wifi created by esp32) and receive by Hercules(terminal)
my board is ESP-wrover-kit(black)
I use tcp_perf test from idf( example/performance) without modification and send continuously data to another laptop(access into the AP wifi created by esp32) and receive by Hercules(terminal)
my board is ESP-wrover-kit(black)
Who is online
Users browsing this forum: Google [Bot] and 105 guests