🛠 Benchmark Ethernet iperf3 : mesurer le piège 10/100 vs gigabit

Objectifs

Passer de la théorie à la preuve : mesurer le débit réel du port Ethernet de ta PINE A64 avec iperf3 et documenter le piège historique du Kickstarter — les acheteurs de la version de base qui découvraient ~11 Mo/s en attendant du gigabit. Tu apprendras à (1) vérifier la vitesse négociée, (2) mesurer le débit applicatif, (3) prouver que le port est l'EMAC interne du SoC, et (4) reconnaître le problème d'alimentation du PHY (rail DC1SW « vcc-phy ») qui rend le lien instable sur les device trees mal corrigés.

Matériel

• 1 × PINE A64 ou A64+ sous Armbian (sudo apt install iperf3 ethtool)
• 1 × PC de bureau sur le même LAN (serveur iperf3)
• Câble Ethernet Cat5e minimum, switch gigabit (sinon c'est le switch qui plafonne)
• Console série ou SSH (attention : le SSH rame pendant le benchmark d'une carte 10/100 — c'est normal)

Code complet

# Côté PC (serveur) :
iperf3 -s

# Côté Pine64 (client, 20 s) :
iperf3 -c 192.168.1.10 -t 20

# Interprétation :
#   PINE A64 de base (RTL8201, RMII)   : plafond ~94 Mbit/s  (10/100)
#   PINE A64+        (RTL8211, RGMII)  : jusqu'à ~600+ Mbit/s (gigabit)

# Vitesse négociée et état du lien :
sudo ethtool eth0 | grep -E 'Speed|Link'

# Prouver que c'est l'EMAC interne (pas un NIC USB) :
ls -l /sys/class/net/eth0/device      # -> .../1c30000.ethernet

# Lien instable ? Le noyau mainline impose un délai d'alimentation du PHY :
#   regulator-enable-ramp-delay sur DC1SW/vcc-phy — commentaire du DTS :
#   « Ethernet PHY needs 30ms to properly power up and some more to initialize »
dmesg | grep -iE 'eth|phy|link'

Vérification attendue

Sur une carte de base, iperf3 plafonne vers 94 Mbit/s — la ligne « sender » tourne autour de 11 Mo/s : c'est la signature du PHY RTL8201 10/100, pas un défaut. Sur une A64+, on dépasse largement les 100 Mbit/s (600+ Mbit/s attendus en gigabit). Le lien sysfs 1c30000.ethernet confirme le contrôleur EMAC intégré : la rumeur d'un « gigabit via USB2 » sur cette carte n'est confirmée par aucun schéma ni device tree — les deux variantes partent bien de l'EMAC interne, seul le PHY change (RMII vs RGMII).

Erreurs fréquentes

• Accuser la carte d'être morte parce qu'elle plafonne à 94 Mbit/s : vérifier d'abord compatible et ethtool Speed — la version de base est documentée 10/100.
• Benchmarker à travers un switch 100 Mbit/s ou un CPL médiocre : le maillon faible est rarement la carte ; tester en direct carte↔PC si possible.
• SSH qui gèle pendant iperf3 sur la carte de base : le trafic de test sature le lien 10/100 — travailler en console série pendant la mesure.
• Lien qui ne monte pas ou tombe par intermittence : le rail d'alimentation du PHY (DC1SW « vcc-phy ») exige un ramp d'environ 100 ms ; les DT sans le correctif regulator-enable-ramp-delay du mainline montrent des liens up chancelants. Utiliser une image à jour.
• Confondre Mbit/s et Mo/s : 94 Mbit/s ≈ 11,3 Mo/s — les chiffres d'iperf3 et de free/dd ne sont pas dans les mêmes unités.
• Oublier la RAM sur les mesures CPU-intensives : le modèle 512 MB sature bien plus vite ; ses distributions supportées sont d'ailleurs limitées à Arch/Debian.