arduino / arduino/ArduinoCore-mbed

Ethernet: High ping on Portenta H7 compared to MKR Shield

Open
#955 17 comments 0 reactions 0 assignees View on GitHub
Dominant language
C
Stars
411
Forks
225
PR merge metrics
No merged PRs in 30d

Description

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:

```text
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:

```text
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:

```cpp
#include
#include

EthernetClient ethClient;

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

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

void loop() {}
```

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 we could try in LwIP? Seems the issue is not in HW.

Thank you!
R

PS: opened initially in https://github.com/arduino-libraries/Ethernet/issues/275

Contributor guide

No contributing guide indexed for this repository

Research direction

Start with the minimal PortentaEthernet/Ethernet sketch shown in the issue and reproduce the ping results on ArduinoCore-mbed, then compare them with the reported MicroPython behavior. Inspect the Arduino Ethernet and LwIP settings involved; done means identifying a supported change or confirmed cause that produces stable sub-millisecond responses without userland code.

Written by the indexing model from the issue text.

Assessment

Tech stack
c, cpp
Domain
embedded-iot, networking, performance
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.