Una porta di una X520-DA2 fa solo 1 Gbit/s in iperf3 dopo il passaggio da TrueNAS Core a SCALE 24.10
Lo storage box è passato da Core 13.0-U6.7 a SCALE 24.04 e poi a 24.10, e da allora una porta striscia mentre la sua gemella sulla stessa scheda è perfettamente felice. La scheda 25G si comporta allo stesso modo, ed è quello che mi fa dubitare dei miei stessi occhi.
- Intel X520-DA2 con ottiche SFP+ multimodali Intel, 10G verso lo switch
- Intel XXV710-DA2 con ottiche SFP28 Intel, 25G verso lo stesso switch
- TrueNAS SCALE 24.10 sul NAS (era Core 13.0-U6.7, poi 24.04)
- iperf3 tra il NAS e un client come metro di paragone
Lo stato del link sulla porta lenta sembra esattamente come dovrebbe:
$ 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 client
Già fatto:
- scambiate le ottiche tra le due porte della scheda; la porta lenta è rimasta lenta, quella veloce è rimasta veloce
- confrontato sysctl net.ipv4.tcp_congestion_control su entrambi i lati, stesso valore
- reinseriti entrambi i lati e pulite le ferrule
Tutto quello che è misurabile a livello di link dice 10G e 25G full duplex, e il payload resta comunque bloccato a circa un gigabit. I moduli si stanno degradando, la NIC sta per morire, o sto guardando il livello sbagliato?
Comments 3
Hai già escluso le ottiche da solo: le hai scambiate tra le porte e la lentezza è rimasta con la porta. Quindi lascia stare i moduli e separa i fatti a livello di link dai numeri di throughput, perché rispondono a domande diverse.
Due cose normalmente differiscono tra una porta veloce e una lenta sulla stessa scheda. Guardale insieme:
Se una sta a MTU 1500 e l'altra a 9014, e sono in VLAN diverse, allora il tuo test lento non sta uscendo dalla NIC e tornando indietro, sta passando per il percorso di routing dell'host. Metti un client nella stessa VLAN e subnet della porta lenta e lancia iperf3 -c contro quello. Nessun router nel percorso, nessun mismatch di MTU, niente su cui discutere.
Se il test a VLAN singola ti dà line rate, la porta e il transceiver sono a posto e quello che hai effettivamente misurato è la performance di routing inter-VLAN sull'host, che è dove finisce un buon numero di migrazioni da Core a SCALE: il forwarding tra VLAN è visibilmente peggiore di quanto fosse sotto Core.
Questa è una diagnosi e non proprio una cura. Ne recuperi la maggior parte tenendo i flussi pesanti dentro una sola VLAN, o passando il routing allo switch invece che al NAS. Come minimo ti evita di restituire due moduli SFP+ perfettamente sani.
Prima che qualcuno inizi a tirare fuori le ottiche: cosa dice lo switch di quelle due porte? Velocità negoziata, duplex e i contatori di errore su entrambe. E quale lato fa girare il server iperf3 nel test lento: il tetto resta fermo quando inverti la direzione e spingi dall'altro lato?
Poi posta l'MTU e la VLAN della porta lenta e di quella veloce, una accanto all'altra. Una porta che negozia 10G e muove solo un gigabit di payload è quasi sempre un problema di forwarding o di percorso, non ottico. Se le due porte non stanno nella stessa VLAN, iperf3 sta valutando il tuo router, non il tuo link.
Hardware diverso, stessa forma. Due macchine back to back su schede X520-DA tramite un DAC SFP+, Hyper-V Server Core 2012 R2 da un lato e uno storage box NAS4Free 9.1 dall'altro. Dritto per dritto, quella coppia faceva 8-9 Gbit/s in lettura e scrittura. Nel momento in cui la porta veniva legata a un virtual switch Hyper-V scendeva a qualcosa come 500 Mbit/s, e riprovare le schede sotto Windows Server 2012 R2 e Windows 8.1 non cambiava assolutamente niente.
Non è mai stato dimostrato. L'unica risposta che ho ricevuto chiedeva quali dischi e quale livello RAID stessero dietro a ciascun lato, il che è una domanda giusta, perché lo storage può essere il tetto molto prima che lo sia il percorso 10G. L'abitudine che ne ho tratto: misurare lo stesso link con lo strato extra attaccato e con quello staccato, e contro un RAM disk se riesci a organizzarne uno. Il cavo e le schede non erano il problema neanche lì.