-
-
Notifications
You must be signed in to change notification settings - Fork 212
Ethernet: High ping on Portenta H7 compared to MKR Shield #955
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
anybody any idea? I tried increasing some values in
|
@razvanphp are you getting the same results using WiFi? or WiFi is working good? If it is i would say the root cause is probably at lower level than LwIP. |
Hi! I just completed rewriting the entire STM32H7 ethernet driver in Mbed. I think there's a good chance it will solve this issue, as the existing one was held together with the digital equivalent of glue and duct tape. PR here: mbed-ce/mbed-os#438 |
Did you managed to get better latency with the new driver? Any idea if I can test your branch before mbed merges it? Not sure how Arduino layer plays on top of mbed, now that mbed is deprecated officially. |
What board(s) do you have? Currrntly Mbed can be built directly (no arduino) for Portenta H7 and Giga. I also have a WIP version of this arduino core based on Mbed CE, I can try to set it up to work for Portenta |
Portenta H7. I could replace some files on my machine and clear the cache, it should load it on a fresh build, if it is compatible with arduino ETH API that is built on-top. Would love to test it. Thank you! |
Yeah if you manually apply my patch, it should work. Also I will work on preparing a version of the mbed ce arduino core for you. |
Good news! I was able to prepare a Portenta release of the Mbed CE arduino core. Still have more checking to do, but I was able to confirm that it at least boots, flashes code, and can talk over Ethernet. Please give it a try if you have a chance! https://github.com/mbed-ce/ArduinoCore-mbed-ce/releases/tag/v1.2.0 If everything works, this should be a drop in replacement for the regular Arduino code that is compatible with the same code. |
I tried to flash your release today, but the basic demo code from this issue with static IP does not make the interface come up, it does not respond to ping. It seems it's using the correct folder/version for the flash:
... I guess it's using the wrong Ethernet lib/folder. Any ideas? PS: Thank again for working on this! |
Ah I see the issue, I had not enabled building the Ethernet library in my version of the core so it was falling back to the default one (which relies on the external chip). That's why PortentaEthernet.h was missing. I just pushed a new release of the core that has this library. Checked it with your code and was able to ping!
|
nice, it seems to work way better than the original mbed implementation! Still, I can see some spikes in reponse time (seems you have them too), which are very strange, given that the sketch is empty and nothing else is being processed than Ethernet packets. Would it be possible to still tune the LWIP stack params / buffers for better performance?
|
Hmm, it's tough because I'm not sure where the spikes in response time are happening -- they could be in the Ethernet driver, or in the IP stack somewhere. Might have to dig into this later. |
I think, to debug this further, you could try adding lines inside Mbed like
This would let you print the absolute time where network packet events happen. Like, the first places you could add that would be here (for Rx) and here (for Tx). That would print one timestamp when a packet is received, and another when a packet is sent. If you see that there is a largeish delay between Rx and Tx timestamps, that indicates the delay is likely in the LwIP stack or another higher layer. If you see that there is a small delay between receiving the ping and sending the response, that suggests the Ethernet driver is at fault because the upper layer stack responded quickly to the ping. This does require recompiling the core, but that is thankfully way easier in my version (no monster shell scripts!). You can even build and flash the Ethernet examples directly from CMake, if you want to sidestep the Arduino IDE. (e.g. Another option to dig into this would be using something like SEGGER SystemView, if you have a J-Link probe available. That would let you visualize all the context switches involved in receiving the packet and would be a much quicker way to track this down. A while back I made a plugin to add it to Mbed, which you could add in to the Arduino core project. It would require a bit of build system hacking though because the CMake files in that repo are set up for my older mbed-cmake project. |
Unfortunately I do not have SEGGER SystemView / J-Link, so I can only test holistically with pings. Can we first try to add similar conf values (buffers, memory, etc) with micropython to LWIP stack? I could not find those in your Arduino core build, what values do they have? defaults? Do I have to recompile mbed to change them as well? ArduinoCore-mbed/variants/PORTENTA_H7_M7/mbed_config.h Lines 204 to 244 in f7ff411
|
Yes, you'd have to recompile Mbed to change those I'm afraid. In Mbed, that config file is here, and it's currently largely driven by JSON options from here. You could likely just add all those defines at the end of the file to override the Mbed ones, though not sure if that would cause other issues. |
I managed to compile it, but I've got mixed results:, I had those at the beginning:
Then I added "\n" at the end of printf and started getting all pings after 9ms:
Then I removed the new line again and ping is 1.6 ms in average, with spikes to 95 ms that can be seen in between those events too:
What does this suggest? Can you please also check it locally? Thank you! PS: do you think |
After migrating our app from MKR WiFi 1010 + ETH shield --> Portenta H7 + Vision Shield, we noticed increased and uneven/unstable ping response times.
Here it is how it looks like on MKR:
And here it is on Portenta H7:
I suspect this is impacting our app's performance, since we need sub ms processing of the data received over ethernet, but not sure how to approach this problem.
Userland code is basically inexistent, as I'm testing just with this:
Initially I though this is because MKR ETH Shield uses W5500 chipset with a built-in hardware TCP/IP stack, while Portenta H7 uses LAN8742AI, an Ethernet PHY that requires a software TCP/IP stack like LwIP.
But today I tried to flash the exact same board with micropython and ping times look perfect:
Are there any settings or optimisations that we could try in LwIP? Seems the issue is not in HW.
Thank you!
R
PS: opened initially in arduino-libraries/Ethernet#275
The text was updated successfully, but these errors were encountered: