O desempenho de leitura da Synology diminui com os Jumbo Frames acima de 6000


12

Versão curta

Minha rede doméstica é pura gigabit com dispositivos que suportam quadros jumbo de até pelo menos ~ 9000 bytes. Aumentar a configuração do jumbo frame MTU na Synology para 6000 (bytes) aumenta o desempenho (gravação de 810Mbps e leitura de 945Mbps). Definir o valor para 7000 destrói apenas o desempenho de leitura (que diminui até 4 Mbps); o desempenho de gravação permanece rápido.

Isso é inesperado, porque a maioria dos problemas de quadros gigantes não tem uma direcionalidade associada a eles e geralmente é tudo ou nada (os pacotes são descartados em um comutador, não importa de onde eles vieram). Não parece haver nenhuma fragmentação de IP, mas a camada TCP é realmente infeliz. O que poderia causar esse comportamento assimétrico / escamoso e como posso corrigi-lo para suportar a MTU de 9000 bytes completa que todo o meu equipamento deve suportar?


Versão longa

Estas são minhas anotações editadas, feitas ao tentar descobrir isso.

Cliente

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

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

(aparece 9198 não inclui o cabeçalho ethernet de 14 bytes)

$ ping -l 1500 -f 192.168.1.84

(observado com o Wireshark em execução no cliente; todos os tamanhos são de bytes de fio)
[9213, ∞] não enviado pelo host (exigiria fragmentação)
[9019, 9212] enviado, mas sem resposta
[9015, 9018] resposta de IP fragmentado
[42, 9014 ] IP não fragmentado
[0, 41]? (não é possível gerar, pois os cabeçalhos eth + IP + ICMP = 14 + 20 + 8 = 42 bytes)

Roteador (parte do switch)

Asus RT-AC68U - Firmware 3.0.0.4.378_4585
Ativar quadro jumbo: "Ativar"
Não é possível descobrir qual o tamanho do quadro jumbo que ele realmente suporta, parece ter pelo menos 9000

Ele fragmenta as solicitações de ping do Cliente em 1514 bytes (mas executar o ping no roteador pode estar provocando o comportamento do roteador WAN em vez do comportamento do comutador da LAN?)

Switch não gerenciado

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

Servidor

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

Pacotes de leitura de arquivo da Synology para o
tamanho do cliente : a maioria tem 9014 bytes (em ambas as direções)
Sinalizadores IP: não fragmenta o
Wireshark descoberto: retransmissão espúria TCP, segmento anterior TCP não capturado, TCP fora de ordem, retransmissão rápida TCP, e pacotes normais (9014 bytes) pacotes
de protocolo SMB2 sobre NetBIOS ler resposta de leitura comprimento de leitura: 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 ligados usando o Adaptive Load Balancing (sem suporte para comutador)

$ ping -c 5 -s 1500 192.168.1.82

(observado com o Wireshark em execução no cliente; todos os tamanhos são de bytes de fio)
[9019, ∞] solicitação enviada, resposta enviada, resposta não recebida
[9015, 9018] solicitação de IP fragmentada (provavelmente fragmentada pela Synology, o busybox ping não tem um opção sem fragmento, por isso é 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 de um penhasco ao alterar o MTU do servidor de 6000 (ótimo, 945Mbps) para 7000 (terrível, 4Mbps)
  • A velocidade de gravação do servidor basicamente não é afetada em todas as configurações da MTU do servidor (sempre entre 700 e 825 Mbps)
  • O Synology possui uma rede ligada (2 das 4 portas)
  • Os cabos são todos Cat6 ou Cat5e

Você precisa registrar um tíquete de suporte com sinologia. Como não tenho experiência com sinologia, não sei se há configurações avançadas nas quais você pode aumentar o tamanho do buffer de memória, mas é provavelmente isso que é necessário. Pessoalmente, normalmente ganho 920mbits e não uso quadros gigantes em nada. Basta ter um comutador de rede não gerenciado genérico.
cybernard

Respostas:


2

Atualize o firmware

Na minha experiência, o Synology corrige muitos problemas em cada versão de firmware e a que você está executando tem quase quatro anos. Não li as notas de versão, mas parece haver muitas oportunidades para que um bug do Jumbo frame tenha 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 de correção 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 seus testes com outro computador. Se ainda permanece, é certamente o NAS.

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

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.