CodingBox Q&A Ask question

Una porta di una X520-DA2 fa solo 1 Gbit/s in iperf3 dopo il passaggio da TrueNAS Core a SCALE 24.10

Asked Active Viewed 19 AI translation from English
0

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

Accepted answer

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:

ip -d link show enp1s0f0
ip -d link show enp1s0f1

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.

3 Ukrainerxnode71UA Show original (English) AI translation

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.

3 United StateslasernodeUS Show original (English) AI translation

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ì.

3 VietnamdwdmpilotVN Show original (English) AI translation
Log in to comment. Log in