Eén poort van een X520-DA2 doet in iperf3 nog maar 1 Gbit/s na de overstap van TrueNAS Core naar SCALE 24.10
De storagebox ging van Core 13.0-U6.7 naar SCALE 24.04 en vervolgens naar 24.10, en sindsdien kruipt één poort vooruit terwijl zijn tweelingpoort op dezelfde kaart het prima doet. De 25G-kaart gedraagt zich hetzelfde, en dat is wat me aan mijn eigen ogen laat twijfelen.
- Intel X520-DA2 met Intel multimode SFP+-optiek, 10G naar de switch
- Intel XXV710-DA2 met Intel SFP28-optiek, 25G naar dezelfde switch
- TrueNAS SCALE 24.10 op de NAS (was Core 13.0-U6.7, daarna 24.04)
- iperf3 tussen de NAS en een client als meetlat
De linkstatus op de trage poort ziet er precies uit zoals het hoort:
$ 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 clientAl gedaan:
- de optiek tussen de twee poorten van de kaart omgewisseld; de trage poort bleef traag, de snelle bleef snel
- sysctl net.ipv4.tcp_congestion_control aan beide kanten vergeleken, dezelfde waarde
- beide kanten opnieuw ingestoken en de ferrules schoongemaakt
Alles wat op de linklaag te meten is, zegt 10G en 25G full duplex, en de payload blijft steken op ruwweg een gigabit. Degraderen de modules, gaat de NIC eraan, of kijk ik naar de verkeerde laag?
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
Je hebt de optiek zelf al uitgesloten: je hebt ze tussen poorten omgewisseld en de traagheid bleef bij de poort. Laat de modules dus met rust en scheid linklaag-feiten van doorvoercijfers, want die beantwoorden verschillende vragen.
Twee dingen verschillen normaal gesproken tussen een snelle en een trage poort op dezelfde kaart. Bekijk ze samen:
Als de ene op MTU 1500 zit en de andere op 9014, en ze in verschillende VLAN's zitten, dan gaat jouw trage test niet de NIC uit en weer terug, maar door het routeringspad van de host. Zet een client in hetzelfde VLAN en subnet als de trage poort en draai iperf3 -c daartegen. Geen router in het pad, geen MTU-mismatch, niets om over te discussiëren.
Geeft de single-VLAN-test je line rate, dan zijn de poort en de transceiver in orde en heb je in werkelijkheid de inter-VLAN-routeringsprestaties van de host gemeten, en dat is precies waar een flink deel van de overstappen van Core naar SCALE op uitkomt: forwarding tussen VLAN's is merkbaar slechter dan onder Core.
Dat is een diagnose en niet echt een remedie. Je krijgt het grootste deel terug door de zware flows binnen één VLAN te houden, of door de routering aan de switch over te laten in plaats van aan de NAS. Op zijn minst voorkomt het dat je twee prima werkende SFP+-modules retourneert.
Voordat iemand optiek gaat lostrekken: wat zegt de switch over die twee poorten? Onderhandelde snelheid, duplex en de foutentellers op beide. En welke kant draait de iperf3-server in de trage test - blijft het plafond staan als je de run omdraait en vanaf de andere kant duwt?
Post daarna de MTU en het VLAN van de trage poort en van de snelle, naast elkaar. Een poort die 10G onderhandelt en maar een gigabit aan payload verplaatst, is bijna altijd een forwarding- of padprobleem, geen optisch probleem. Zitten de twee poorten niet in hetzelfde VLAN, dan beoordeelt iperf3 jouw router, niet jouw link.
Andere hardware, zelfde patroon. Twee dozen back-to-back op X520-DA-kaarten via een SFP+ DAC, aan de ene kant Hyper-V Server Core 2012 R2, aan de andere een NAS4Free 9.1 storagebox. Rechtstreeks haalde dat paar 8-9 Gbit/s bij lezen en schrijven. Op het moment dat de poort aan een Hyper-V virtuele switch werd gekoppeld, zakte het naar zoiets als 500 Mbit/s, en opnieuw testen van de kaarten onder Windows Server 2012 R2 en Windows 8.1 veranderde helemaal niets.
Het is nooit bewezen. De ene reactie die ik kreeg, vroeg welke schijven en welk RAID-niveau achter elk uiteinde zaten, wat een eerlijke vraag is, want de storage kan het plafond zijn lang voordat het 10G-pad dat is. De gewoonte die ik eraan overhield: dezelfde link meten met de extra laag erbij en zonder, en tegen een RAM-disk als je die kunt regelen. De kabel en de kaarten waren daar ook niet het probleem.