High ping on Portenta H7 compared to MKR

[razvanphp]

Not sure if this should belong in ArduinoCore-mbed, but I assume it has more to do with this stack, than with the platform itself?

After migrating our app from MKR WiFi 1010 + ETH shield to Portenta H7 + Vision Shield, we noticed increased and uneven/unstable ping response times.

Here it is how it looks like on MKR:

64 bytes from 172.30.0.2: icmp_seq=1389 ttl=128 time=0.465 ms
64 bytes from 172.30.0.2: icmp_seq=1390 ttl=128 time=0.315 ms
64 bytes from 172.30.0.2: icmp_seq=1391 ttl=128 time=0.503 ms
64 bytes from 172.30.0.2: icmp_seq=1392 ttl=128 time=0.279 ms
64 bytes from 172.30.0.2: icmp_seq=1393 ttl=128 time=0.657 ms
64 bytes from 172.30.0.2: icmp_seq=1394 ttl=128 time=0.403 ms
64 bytes from 172.30.0.2: icmp_seq=1395 ttl=128 time=0.374 ms
64 bytes from 172.30.0.2: icmp_seq=1396 ttl=128 time=0.304 ms
64 bytes from 172.30.0.2: icmp_seq=1397 ttl=128 time=0.430 ms
64 bytes from 172.30.0.2: icmp_seq=1398 ttl=128 time=0.474 ms
64 bytes from 172.30.0.2: icmp_seq=1399 ttl=128 time=0.463 ms
64 bytes from 172.30.0.2: icmp_seq=1400 ttl=128 time=0.386 ms
64 bytes from 172.30.0.2: icmp_seq=1401 ttl=128 time=0.398 ms
64 bytes from 172.30.0.2: icmp_seq=1402 ttl=128 time=0.399 ms
64 bytes from 172.30.0.2: icmp_seq=1403 ttl=128 time=0.322 ms
64 bytes from 172.30.0.2: icmp_seq=1404 ttl=128 time=0.464 ms
64 bytes from 172.30.0.2: icmp_seq=1405 ttl=128 time=0.394 ms
64 bytes from 172.30.0.2: icmp_seq=1406 ttl=128 time=0.417 ms
64 bytes from 172.30.0.2: icmp_seq=1407 ttl=128 time=0.609 ms
64 bytes from 172.30.0.2: icmp_seq=1408 ttl=128 time=0.429 ms
64 bytes from 172.30.0.2: icmp_seq=1409 ttl=128 time=0.534 ms
64 bytes from 172.30.0.2: icmp_seq=1410 ttl=128 time=0.382 ms
64 bytes from 172.30.0.2: icmp_seq=1411 ttl=128 time=0.621 ms
64 bytes from 172.30.0.2: icmp_seq=1412 ttl=128 time=0.339 ms
64 bytes from 172.30.0.2: icmp_seq=1413 ttl=128 time=0.638 ms
64 bytes from 172.30.0.2: icmp_seq=1414 ttl=128 time=0.335 ms
64 bytes from 172.30.0.2: icmp_seq=1415 ttl=128 time=0.410 ms
64 bytes from 172.30.0.2: icmp_seq=1416 ttl=128 time=0.217 ms
64 bytes from 172.30.0.2: icmp_seq=1417 ttl=128 time=0.463 ms
64 bytes from 172.30.0.2: icmp_seq=1418 ttl=128 time=0.372 ms
64 bytes from 172.30.0.2: icmp_seq=1419 ttl=128 time=0.391 ms
64 bytes from 172.30.0.2: icmp_seq=1420 ttl=128 time=0.603 ms
64 bytes from 172.30.0.2: icmp_seq=1421 ttl=128 time=0.300 ms
64 bytes from 172.30.0.2: icmp_seq=1422 ttl=128 time=0.512 ms
64 bytes from 172.30.0.2: icmp_seq=1423 ttl=128 time=0.378 ms
64 bytes from 172.30.0.2: icmp_seq=1424 ttl=128 time=0.509 ms
64 bytes from 172.30.0.2: icmp_seq=1425 ttl=128 time=0.473 ms
64 bytes from 172.30.0.2: icmp_seq=1426 ttl=128 time=0.345 ms
64 bytes from 172.30.0.2: icmp_seq=1427 ttl=128 time=0.344 ms

And here it is on Portenta H7:

64 bytes from 172.30.0.3: icmp_seq=1 ttl=255 time=7.47 ms
64 bytes from 172.30.0.3: icmp_seq=2 ttl=255 time=2.37 ms
64 bytes from 172.30.0.3: icmp_seq=3 ttl=255 time=1.69 ms
64 bytes from 172.30.0.3: icmp_seq=4 ttl=255 time=4.95 ms
64 bytes from 172.30.0.3: icmp_seq=5 ttl=255 time=4.92 ms
64 bytes from 172.30.0.3: icmp_seq=6 ttl=255 time=4.93 ms
64 bytes from 172.30.0.3: icmp_seq=7 ttl=255 time=0.404 ms
64 bytes from 172.30.0.3: icmp_seq=8 ttl=255 time=1.74 ms
64 bytes from 172.30.0.3: icmp_seq=9 ttl=255 time=0.145 ms
64 bytes from 172.30.0.3: icmp_seq=10 ttl=255 time=1.75 ms
64 bytes from 172.30.0.3: icmp_seq=11 ttl=255 time=0.710 ms
64 bytes from 172.30.0.3: icmp_seq=12 ttl=255 time=1.76 ms
64 bytes from 172.30.0.3: icmp_seq=13 ttl=255 time=0.686 ms
64 bytes from 172.30.0.3: icmp_seq=14 ttl=255 time=1.75 ms
64 bytes from 172.30.0.3: icmp_seq=15 ttl=255 time=0.186 ms
64 bytes from 172.30.0.3: icmp_seq=16 ttl=255 time=1.77 ms
64 bytes from 172.30.0.3: icmp_seq=17 ttl=255 time=0.583 ms
64 bytes from 172.30.0.3: icmp_seq=18 ttl=255 time=1.82 ms
64 bytes from 172.30.0.3: icmp_seq=19 ttl=255 time=4.92 ms
64 bytes from 172.30.0.3: icmp_seq=20 ttl=255 time=2.94 ms
64 bytes from 172.30.0.3: icmp_seq=21 ttl=255 time=1.84 ms
64 bytes from 172.30.0.3: icmp_seq=22 ttl=255 time=0.561 ms
64 bytes from 172.30.0.3: icmp_seq=23 ttl=255 time=1.89 ms
64 bytes from 172.30.0.3: icmp_seq=24 ttl=255 time=0.788 ms
64 bytes from 172.30.0.3: icmp_seq=25 ttl=255 time=1.89 ms
64 bytes from 172.30.0.3: icmp_seq=26 ttl=255 time=4.95 ms
64 bytes from 172.30.0.3: icmp_seq=27 ttl=255 time=4.07 ms
64 bytes from 172.30.0.3: icmp_seq=28 ttl=255 time=3.96 ms
64 bytes from 172.30.0.3: icmp_seq=29 ttl=255 time=2.94 ms
64 bytes from 172.30.0.3: icmp_seq=30 ttl=255 time=1.65 ms
64 bytes from 172.30.0.3: icmp_seq=31 ttl=255 time=4.93 ms

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:

#include <PortentaEthernet.h>
#include <Ethernet.h>

EthernetClient ethClient;

byte mac[] = { 0xA8, 0x61, 0x0A, 0xAE, 0x44, 0xE0 };
IPAddress ip(172, 30, 0, 3);

void setup() {
  Ethernet.begin(mac, ip);
}

void loop() {}

Thank you!
R

[razvanphp]

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:

64 bytes from 192.168.10.252: icmp_seq=10 ttl=255 time=0.075 ms
64 bytes from 192.168.10.252: icmp_seq=11 ttl=255 time=0.086 ms
64 bytes from 192.168.10.252: icmp_seq=12 ttl=255 time=0.082 ms
64 bytes from 192.168.10.252: icmp_seq=13 ttl=255 time=0.069 ms
64 bytes from 192.168.10.252: icmp_seq=14 ttl=255 time=0.072 ms
64 bytes from 192.168.10.252: icmp_seq=15 ttl=255 time=0.092 ms
64 bytes from 192.168.10.252: icmp_seq=16 ttl=255 time=0.094 ms
64 bytes from 192.168.10.252: icmp_seq=17 ttl=255 time=0.095 ms
64 bytes from 192.168.10.252: icmp_seq=18 ttl=255 time=0.085 ms
64 bytes from 192.168.10.252: icmp_seq=19 ttl=255 time=0.067 ms
64 bytes from 192.168.10.252: icmp_seq=20 ttl=255 time=0.094 ms
64 bytes from 192.168.10.252: icmp_seq=21 ttl=255 time=0.071 ms
64 bytes from 192.168.10.252: icmp_seq=22 ttl=255 time=0.086 ms
64 bytes from 192.168.10.252: icmp_seq=23 ttl=255 time=0.084 ms
64 bytes from 192.168.10.252: icmp_seq=24 ttl=255 time=0.069 ms
64 bytes from 192.168.10.252: icmp_seq=25 ttl=255 time=0.105 ms
64 bytes from 192.168.10.252: icmp_seq=26 ttl=255 time=0.084 ms
64 bytes from 192.168.10.252: icmp_seq=27 ttl=255 time=0.095 ms

Are there any settings or optimisations that I could try? Seems the issue is not in HW. Thanks!

[JAndrassy]

this has nothing to do with the Ethernet library for W5500

cc: @per1234

[razvanphp]

this has nothing to do with the Ethernet library for W5500

You mean that this repo is only for W5500?

For Portenta I should open an issue here?
https://github.com/arduino/ArduinoCore-mbed/tree/main/libraries/Ethernet/src

[per1234]

this repo is only for W5500?

Yes, the Ethernet library hosted in this repository only provides support for the WIZnet W5100, W5200, and W5500 Ethernet controllers. When you compile a sketch for the Portenta H7 board, the Arduino sketch build system automatically uses that different Ethernet library you linked, which is bundled with the "Arduino Mbed OS Portenta Boards" platform.

For Portenta I should open an issue here?

Yes, to report bugs or request features specific to the Ethernet library used by the Portenta H7, you should submit those to the issue tracker in the arduino/ArduinoCore-mbed repository where that library's codebase is hosted.