Uma porta de um X520-DA2 só faz 1 Gbit/s no iperf3 depois da migração de TrueNAS Core para SCALE 24.10
A caixa de armazenamento foi do Core 13.0-U6.7 para o SCALE 24.04 e depois para o 24.10, e desde então uma porta está rastejando enquanto a gêmea dela na mesma placa está perfeitamente feliz. A placa 25G se comporta do mesmo jeito, o que é o que me faz duvidar dos meus próprios olhos.
- Intel X520-DA2 com óptica SFP+ multimodo Intel, 10G até o switch
- Intel XXV710-DA2 com óptica SFP28 Intel, 25G até o mesmo switch
- TrueNAS SCALE 24.10 no NAS (era Core 13.0-U6.7, depois 24.04)
- iperf3 entre o NAS e um cliente como referência
O estado do link na porta lenta parece exatamente como deveria:
$ 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 clientJá feito:
- troquei a óptica entre as duas portas da placa; a porta lenta continuou lenta, a rápida continuou rápida
- comparei o sysctl net.ipv4.tcp_congestion_control nas duas pontas, mesmo valor
- reencaixei as duas pontas e limpei as ferrules
Tudo o que é mensurável na camada de link diz 10G e 25G full duplex, e o payload continua travado em mais ou menos um gigabit. Os módulos estão degradando, a placa está no fim da vida, ou estou olhando para a camada errada?
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
Você mesmo já descartou a óptica: trocou entre as portas e a lentidão ficou com a porta. Então deixe os módulos quietos e separe os fatos da camada de link dos números de throughput, porque eles respondem perguntas diferentes.
Duas coisas normalmente diferem entre uma porta rápida e uma lenta na mesma placa. Olhe as duas juntas:
Se uma está em MTU 1500 e a outra em 9014, e elas estão em VLANs diferentes, então o seu teste lento não está saindo da placa e voltando, está passando pelo caminho de roteamento do host. Coloque um cliente na mesma VLAN e sub-rede da porta lenta e rode iperf3 -c contra ele. Sem roteador no caminho, sem incompatibilidade de MTU, nada para discutir.
Se o teste em uma única VLAN te der a taxa plena, a porta e o transceptor estão bons, e o que você mediu de fato foi o desempenho de roteamento entre VLANs no host, que é onde boa parte das migrações de Core para SCALE acaba: o encaminhamento entre VLANs fica visivelmente pior do que era no Core.
Isso é um diagnóstico, não bem uma cura. Você recupera a maior parte mantendo os fluxos pesados dentro de uma única VLAN, ou passando o roteamento para o switch em vez do NAS. No mínimo, isso evita que você devolva dois módulos SFP+ perfeitamente bons.
Antes de qualquer um sair arrancando óptica: o que o switch diz sobre essas duas portas? Velocidade negociada, duplex e os contadores de erro nas duas. E qual ponta roda o servidor iperf3 no teste lento - o teto se mantém quando você inverte o sentido e empurra tráfego do outro lado?
Depois poste o MTU e a VLAN da porta lenta e da rápida, lado a lado. Uma porta que negocia 10G e só move um gigabit de payload é, quase sempre, um problema de encaminhamento ou de caminho, não óptico. Se as duas portas não estiverem na mesma VLAN, o iperf3 está avaliando o seu roteador, não o seu link.
Hardware diferente, mesmo formato. Duas caixas back to back em placas X520-DA por um DAC SFP+, Hyper-V Server Core 2012 R2 de um lado e uma caixa de armazenamento NAS4Free 9.1 do outro. Direto, esse par fazia 8-9 Gbit/s lendo e escrevendo. No momento em que a porta foi associada a um switch virtual do Hyper-V, caiu para algo como 500 Mbit/s, e retestar as placas sob Windows Server 2012 R2 e Windows 8.1 não mudou nada.
Nunca foi provado. A única resposta que recebi perguntou quais discos e qual nível de RAID estava atrás de cada ponta, o que é uma pergunta justa, porque o armazenamento pode ser o teto bem antes do caminho de 10G ser. O hábito que ficou disso: medir o mesmo link com a camada extra presente e sem ela, e contra um RAM disk se der para arranjar um. O cabo e as placas também não eram o problema ali.