☰

Versão curta

tag-icon • tag-icon ethernet throughput
Versão curta

Versão curta

Minha rede doméstica é gigabit puro, com dispositivos que suportam frames jumbo de até pelo menos ~ 9.000 bytes. Aumentar a configuração do quadro jumbo MTU no Synology para 6.000 (bytes) aumenta o desempenho (gravação de 810 Mbps e leitura de 945 Mbps). Definir o valor como 7000 destrói apenas o desempenho de leitura (que diminui até 4Mbps); o desempenho de gravação permanece rápido.

Isso é inesperado porque a maioria dos problemas de jumbo frame não tem uma direcionalidade associada e normalmente são tudo ou nada (os pacotes são descartados em um switch, não importa de onde vieram). Não parece haverqualquerA fragmentação de IP está acontecendo, mas a camada TCP está realmente infeliz. O que poderia causar esse comportamento assimétrico/instável e como posso corrigi-lo para suportar o MTU completo de 9.000 bytes que todo o meu equipamento deve suportar?

Versão longa

Estas são minhas anotações editadas, feitas enquanto tentava descobrir isso.

Cliente

Controlador da família Realtek PCIe GBE RTL8167
Jumbo Frame: 9 KB MTU

$ netsh interface ipv4 show subinterfaces
   MTU  MediaSenseState   Bytes In  Bytes Out  Interface
------  ---------------  ---------  ---------  -------------
  9198                1   32501506   11275394  Local Area Connection

(parece que 9198 não inclui o cabeçalho Ethernet de 14 bytes)

$ ping -l 1500 -f 192.168.1.84

(observado com o Wireshark rodando no Cliente; todos os tamanhos são tamanhos de bytes de conexão)
[9213, ∞] não enviado pelo host (requer fragmentação)
[9019, 9212] enviado, mas sem resposta
[9015, 9018] resposta IP fragmentada
[42, 9014 ] IP não fragmentado
[0, 41] ? (incapaz de gerar porque cabeçalhos eth+IP+ICMP = 14+20+8 = 42 bytes)

Roteador (parte do switch)

Asus RT-AC68U - Firmware 3.0.0.4.378_4585
Habilitar Jumbo Frame: "Ativar"
Não consigo descobrir qual tamanho de quadro jumbo ele realmente suporta, parece ser pelo menos 9000

Ele fragmenta as solicitações de ping do cliente em 1514 bytes (mas fazer ping no roteador pode estar acionando o comportamento do roteador WAN em vez do comportamento do switch LAN?)

Switch não gerenciado

TP-LINK TL-SG1008D
Jumbo Frames (folhas de especificações): 9 KB (o site diz 15 KB, mas parece um dispositivo diferente)

Servidor

Synology DS1815 + - DSM 5.2-5565 Atualização 1
Jumbo Frame: 9000

Pacotes de leitura de arquivos do Synology para o cliente
Tamanho: a maioria tem 9.014 bytes (em ambas as direções)
IP Flags: Não fragmenta
Wireshark descoberto: TCP Retransmissão espúria, TCP Segmento anterior não capturado, TCP fora de ordem, TCP Retransmissão rápida e pacotes normais (9.014 bytes)
SMB2 - comprimento de leitura da resposta de leitura de pacotes do protocolo NetBIOS: 65.536 (~8 segmentos TCP)

$ ifconfig
bond0     Link encap:Ethernet  HWaddr --:FF
          inet addr:192.168.1.84  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addrs: --/64 Scope:Link, --/64 Scope:Global, --/64 Scope:Global
          UP BROADCAST RUNNING MASTER MULTICAST  MTU:9000  Metric:1
          RX packets:lots errors:85 dropped:0 overruns:0 frame:85
          TX packets:lots errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:237 GiB  TX bytes:117 GiB

eth2      Link encap:Ethernet  HWaddr --:00
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:9000  Metric:1
          RX packets:lots errors:19 dropped:0 overruns:0 frame:19
          TX packets:lots errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:236 GiB  TX bytes:83 GiB

eth3      Link encap:Ethernet  HWaddr --FF
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:9000  Metric:1
          RX packets:lots errors:66 dropped:0 overruns:0 frame:66
          TX packets:lots errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1 GiB  TX bytes:33 GiB

eth2 e eth3 são unidos usando Adaptive Load Balancing (sem suporte de switch)

$ ping -c 5 -s 1500 192.168.1.82

(observado com o Wireshark rodando no Cliente; todos os tamanhos são tamanhos de bytes de conexão)
[9019, ∞] solicitação enviada, resposta enviada, resposta não recebida
[9015, 9018] solicitação IP fragmentada (provavelmente fragmentada pela Synology, o ping do busybox não tem um opção sem fragmento, então é difícil dizer)
[60, 9014] IP não fragmentado
[0, 59] ? (não é possível gerar porque o ping do busybox coloca no mínimo 18 bytes mais os cabeçalhos de 42 bytes)

Dados diversos

  • Alterar o MTU do cliente para 8 KB não ajudou
  • A velocidade de leitura do servidor cai drasticamente ao alterar o MTU do servidor de 6.000 (ótimo, 945 Mbps) para 7.000 (péssimo, 4 Mbps)
  • A velocidade de gravação do servidor basicamente não é afetada em todas as configurações de MTU do servidor (sempre entre 700 e 825 Mbps)
  • O Synology possui uma rede vinculada (2 das 4 portas)
  • Os cabos são todos Cat6 ou Cat5e

Responder1

Atualize o Firmware

Na minha experiência, a Synology corrige muitos problemas em cada versão de firmware e aquele que você está executando tem quase quatro anos. Não li as notas de lançamento, mas parece haver muitas oportunidades para um bug do quadro Jumbo ter sido corrigido desde então.

Teste com uma conexão direta

Conecte sua máquina de teste diretamente ao Synology (atribua IPs estáticos na mesma sub-rede) com novos cabos patch e execute novamente seus testes. Isso eliminará o cabeamento e os switches, bem como quaisquer outros problemas de equipamento e configuração. Se o problema persistir, execute os testes em outro computador. Se ainda permanecer é certamente o NAS.

Se o problema desaparecer durante o teste de conexão direta, tente substituir primeiro o switch e depois o cabeamento. Você não mostrou as conexões, então presumo apenas o TPLINK entre a máquina de teste e o NAS.

informação relacionada