The ESP8266 is supposed to offload a system host controller from networking tasks. And therefore the chip acts as a network interface card for an embedded system.
When choosing a chip for networking, you would typically look into two aspects of it:
- Interface for host controller and speed
- Networking performance
So here we take a look at how well the ESP8266 performs when it is configured as a server in station mode and serves data through a capable TP-LINK router to a typical desktop computer.
ESP8266 wifi server speed results
We performed two tests, one using a single download thread and the other using multiple simultaneous downloads. “Download” here means downloading data from the ESP8266 server via a router. The router and PC are capable of handling over 50 mbps easily and are not a bottleneck by any means.
The data being served for download way just a dummy data array in the ESP8266. Two tests were performed.
Single socket download speed
In the single download test, we tried to download a single file from the ESP8266 server. The results look something like this:
The ESP8266 can serve data via WiFi at over 7 mbps if the conditions are reasonably good.
The 7 mbps performance was measured by downloading this from ESP8266. Note: It is 7 mbits/s, and not mbytes/s!
Multiple socket download speed
The ESP8266 seems to handle data transfer more efficiently when the buffers can be served by multiple sockets. It has something to do with the internal buffer management code, as far as we can figure it out. If you know any better, do leave a comment below!
In the stats shown below, the ESP8266 server was made to deliver data to 4 download threads, and the effective data rate seemed to go up. This does validate the fact that tweaking LwIP library a little might achieve a data rate much higher than just 7 mbps for a single thread.
ESP8266 server data over WiFi at over 13 mbps for multiple simultaneous downloads.
This is what the download looks like in the download manager. Note that the file names are the same, but the ESP8266 test program does not differentiate file names (it serves dummy data anyway).
The test source code
The test source code is internal and so it has not been attached here.
However, the code simply runs the hardware resources as efficiently as possible in a normal SDK application and assumes that the buffer in the heap is filled in between data transmit callbacks. This is definitely possible in a practical application using dual buffer, if not a single one.
so the code is internal but if someone knows a better way please be a good lad and share yours right ?
This data and analysis make for good reference point when considering possible applications. Thank you for the effort you put into this.
Guess this means the code looks like an infant wrote it :~}}}
Haha it actually does, callback based code and written just for the purpose of one-time measurement, so not the best code to refer to.