Un port d'un X520-DA2 ne fait que 1 Gbit/s en iperf3 après le passage de TrueNAS Core à SCALE 24.10
Le boîtier de stockage est passé de Core 13.0-U6.7 à SCALE 24.04 puis à 24.10, et depuis un port rampe pendant que son jumeau sur la même carte est parfaitement content. La carte 25G se comporte de la même façon, ce qui me fait douter de mes propres yeux.
- Intel X520-DA2 avec des optiques SFP+ multimode Intel, 10G vers le switch
- Intel XXV710-DA2 avec des optiques SFP28 Intel, 25G vers le même switch
- TrueNAS SCALE 24.10 sur le NAS (c'était Core 13.0-U6.7, puis 24.04)
- iperf3 entre le NAS et un client comme référence
L'état du lien sur le port lent a l'air exactement comme il devrait :
$ ethtool enp1s0f0 | grep -E 'Speed|Duplex|Link detected'
Speed: 10000Mb/s
Duplex: Full
Link detected: yes
$ iperf3 -c 192.168.3.2
# parks itself around 1 Gbit/s for the whole run
# the second port of the same card does line rate against its own clientDéjà fait :
- échangé les optiques entre les deux ports de la carte ; le port lent est resté lent, le rapide est resté rapide
- comparé sysctl net.ipv4.tcp_congestion_control aux deux extrémités, même valeur
- réinséré les deux extrémités et nettoyé les ferrules
Tout ce qui est mesurable au niveau de la couche liaison indique du 10G et du 25G full duplex, et le débit utile reste coincé autour du gigabit. Les modules se dégradent-ils, la carte réseau est-elle en train de lâcher, ou est-ce que je regarde la mauvaise couche ?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 3
Vous avez déjà écarté vous-même les optiques : vous les avez échangées entre ports et la lenteur est restée avec le port. Donc laissez les modules tranquilles et séparez les faits de la couche liaison des chiffres de débit, parce qu'ils répondent à des questions différentes.
Deux choses diffèrent normalement entre un port rapide et un port lent sur la même carte. Regardez-les ensemble :
Si l'un est à MTU 1500 et l'autre à 9014, et qu'ils sont dans des VLAN différents, alors votre test lent ne sort pas de la carte réseau pour y revenir, il passe par le chemin de routage de l'hôte. Mettez un client dans le même VLAN et le même sous-réseau que le port lent et lancez iperf3 -c contre celui-ci. Aucun routeur sur le chemin, aucune incohérence de MTU, rien à débattre.
Si le test à VLAN unique donne le débit de ligne, le port et le transceiver vont bien et ce que vous avez réellement mesuré est la performance du routage inter-VLAN sur l'hôte, ce qui est là où atterrit un bon nombre de migrations de Core vers SCALE : le forwarding entre VLAN est visiblement pire que sous Core.
C'est un diagnostic et pas vraiment un remède. Vous en récupérez la majeure partie en gardant les flux lourds à l'intérieur d'un seul VLAN, ou en confiant le routage au switch plutôt qu'au NAS. Au minimum, ça vous évite de renvoyer deux modules SFP+ parfaitement bons.
Avant que quiconque ne commence à retirer des optiques : que dit le switch sur ces deux ports ? Vitesse négociée, duplex et les compteurs d'erreurs des deux. Et quelle extrémité fait tourner le serveur iperf3 dans le test lent - le plafond reste-t-il en place quand vous inversez le sens et poussez depuis l'autre côté ?
Puis postez le MTU et le VLAN du port lent et du rapide, côte à côte. Un port qui négocie 10G et ne bouge qu'un gigabit de charge utile est un problème de forwarding ou de chemin dans presque tous les cas, pas un problème optique. Si les deux ports ne sont pas dans le même VLAN, iperf3 note votre routeur, pas votre lien.
Matériel différent, même forme. Deux boîtiers dos à dos sur des cartes X520-DA via un DAC SFP+, Hyper-V Server Core 2012 R2 d'un côté et un boîtier de stockage NAS4Free 9.1 de l'autre. En direct, cette paire faisait 8-9 Gbit/s en lecture et écriture. Au moment où le port a été rattaché à un switch virtuel Hyper-V, ça a chuté à quelque chose comme 500 Mbit/s, et retester les cartes sous Windows Server 2012 R2 et Windows 8.1 n'a rien changé du tout.
Ça n'a jamais été prouvé. La seule réponse que j'ai eue demandait quels disques et quel niveau de RAID se trouvaient derrière chaque extrémité, ce qui est une question légitime, parce que le stockage peut être le plafond bien avant que le chemin 10G ne le soit. L'habitude que j'en ai tirée : mesurer le même lien avec la couche supplémentaire attachée et sans elle, et contre un disque RAM si vous pouvez en arranger un. Le câble et les cartes n'étaient pas le problème là non plus.