ESP32 Forum

Has anyone tried to use lan8720 to connect to the Internet? I hadthree problems



(1) When using lan8720 for iperf test, the speed is only 60 Mbits / sec, which can not reach 100 Mbits / sec. Is it due to the insufficient performance of esp32? Here are the test results




(2) When LAN 8720 is used for TCP or iperf TCP test, it will occasionally reports errors:
OR
, and then the network will be disconnected. After I reset LAN8720, it will return to normal ,All functions are normal (esp32 don't restarted).I want to ask why LAN8720 will Ethernet link down OR insufficient TX buffer size?thanks.



(3) After the lan8720 is powered on, it will always output the clock signal to the GPIO 0 pin, which causes the esp32 to start to the flash download mode. Is there a solution?

Lots of people use the LAN8720 for Ethernet (not sure how the Internet is special though) e.g.
https://www.esp32.com/viewtopic.php?t=9607

(3) After the lan8720 is powered on, it will always output the clock signal to the GPIO 0 pin....
The basic principles are shown here https://raw.githubusercontent.com/OLIME ... _Rev_F.pdf albeit for an 8710.

It sounds as if you have a problem with your hardware. I have read more than one post on this subject and have seen issues first hand!

You need to supply some code to help analyse your performance issue(s). It could be hardware. I have not worked that low on the ESP32 Ethernet & so could not say. The ESP32 IDF does tend to slow things down in many other areas. I have noted that the ESP is not as fast as some processors but then you tend to pay more for CPUs with multiple DMA channels or transfer segments (e.g. circular buffer of DMA requests).
I wonder though if ESP32 speed will matter that much when sending over the internet.

@chdwjzd Out of curiosity why is 100 Mbits / sec so important? I mean the ESP32 cannot even process that much information anyways.

I guess it all adds up.
I cannot answer for the poster but webpage download speed has been an issue for me.
A small/medium webpage might be 2 or 3MB say (just check out the size of bootstrap!).
That's 0.24 seconds @100Mbps or 0.5 seconds @50Mbps, 1 second @25Mhz.
Actually it would take much longer as typically the webpage would be made up of multiple files and so there would be gaps between the ESP32 HTTP server's processing of each request. So whilst raw bandwidth is not the killer factor it can tip you past acceptable.

Also 100Mbps is only 3M words/S. The ESP32 can run at 240MHz with dual processors so that could allow around 160 operations per 32 bit word, which is quite a lot of CPU grunt.

PeterR wrote: Also 100Mbps is only 3M words/S. The ESP32 can run at 240MHz with dual processors so that could allow around 160 operations per 32 bit word, which is quite a lot of CPU grunt.

Those math has nothing to do with real life. Lets summarize it:
- 1 task, like http server task, can run on just 1 core at the same time, so even if you would like to perform parallel reading from sd card/flash to have 2 tasks running, it is not possible, because you just have to know in front what file to process and have data prepared
- even if you would like to cache files in PSRAM, which is limited to about 4MB, you still have about 40-80MHz SPI to read/write PSRAM,
- if you take all above into account, and add SPI and freertos overhead, its not possible to even close to 100Mbit/s, assuming esp32 will do nothing more than serving website.

Now another question, about iperf. I am not saying above will be impacting iperf benchmark test, and honestly i didnt work with eth on esp32 yet, so i cant answer OP question, but i am also curious why 100Mbit is important. Increasing RX/TX buffers should help a bit to get better results.

1 task, like http server task, can run on just 1 core at the same time, so even if you would like to perform parallel reading from sd card/flash to have 2 tasks running, it is not possible, because you just have to know in front what file to process and have data prepared

The OP did not mandate the ESP HTTP task. I could use Lwip direct pbuf (& Lwip's own http server) which I have done before on a coop low latency loop. Lots faster.

- 1 task, like http server task, can run on just 1 core at the same time, so even if you would like to perform parallel reading from sd card/flash to have 2 tasks running, it is not possible, because you just have to know in front what file to process and have data prepared

That's what I said. File selection & so latency will kill more than bps. But you could avoid with a monolithic website or to a lesser extent a coop loop.

even if you would like to cache files in PSRAM, which is limited to about 4MB, you still have about 40-80MHz SPI to read/write PSRAM,

Not sure what your point is:
(1) I can serve >>>GB @ close to 100Mbps using (say) 32KB of RAM e.g. double buffering (producer/consumer pattern). If its a calculated output then SPI does not come into this. If static/file serve then see below....
On an Mx or a processor with a circular DMA request buffer I can keep that stream going. I think the ESP only has a single DMA request so then I have latency on each request, see below.
Doubt with with ESP-IDF though. I would guess 20uS gap between packets (UDP because TCP will not get anywhere near 100Mbps because of ACK & buffer constraints) so 40uS every 12Mbp maybe 400uS in a second down time? Lets say 1mS. You would have to work really really hard on the drivers though.
(2) Regarding serving a 3MB website then sure the website would be in flash but @80MHz and QSPI I could buffer into DRAM from core 2 etc.

Those math has nothing to do with real life.

The maths is correct (no figure given on latency granted). You just need to think how to apply & then be prepared to do a lot of typing. I have done iNET-X streams on Mx processors and faced similar hurdles. But I used Lwip on cooperative schedule & maybe the Mx DMA channels were a little better than ESP!

I think we are agreed that he is not going to get anywhere near 100Mbps without serious effort though (& also 100Mbps is impossible without a DMA request circular buffer (avoids latency between req1 & req2) which IJDK if the ESP has)!