Início / server / Perguntas / 1168239
Accepted
nh2
Asked: 2024-11-28 06:41:02 +0800 CST

Velocidades de upload lentas do Windows em uma única conexão TCP, provavelmente devido à reordenação de pacotes de placas de rede Intel 82599ES (ixgbe) de 10 Gbit/s

  • 772

Entre os servidores, windows-in-Finland <-> linux-in-Germanyestou enfrentando um upload 100x mais lento que o download ( windows -> linuxé 100x mais lento que windows <- linux).

Detalhes e pesquisas existentes

Inicialmente, observei esse problema com clientes Windows em todo o mundo e percebi que também posso reproduzi-lo em ambientes de data center controlados.

Para reproduzir o problema, estou usando o provedor de datacenter Hetzner, com a Windowsmáquina na Finlândia (servidor dedicado, Windows Server 2019), fazendo upload para ambos:

  • Linux Hetzner dedicado Alemanha: lento
  • Linux Hetzner Cloud VM Alemanha: rápido

Ambos estão no mesmo parque de datacenter e, portanto, ambos têm 37 ms pingda máquina Windows. Enquanto a conexão entre a Finlândia e a Alemanha geralmente está na rede privada da Hetzner, ela está atualmente sendo redirecionada por meio de rotas públicas de Internet devido à interrupção do cabo submarino C-LION1 2024 do Mar Báltico ( mensagem de status da Hetzner sobre isso ), então a conexão "simula" o uso de rotas e peerings normais de Internet pública.

Estou medindo com iperf3, windows <- linux:

C:\Users\Administrator\Downloads\iperf3.17.1_64\iperf3.17.1_64>iperf3.exe -c linux-germany-dedicated.examle.com

Connecting to host linux-germany-dedicated.examle.com, port 5201
[  5] local 192.0.2.1 port 62234 connected to 192.0.2.2 port 5201
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec  15.8 MBytes   132 Mbits/sec
[  5]   1.00-2.00   sec  1.88 MBytes  15.7 Mbits/sec
[  5]   2.00-3.00   sec  1.38 MBytes  11.5 Mbits/sec
[  5]   3.00-4.00   sec  1.75 MBytes  14.7 Mbits/sec
[  5]   4.00-5.00   sec  2.25 MBytes  18.9 Mbits/sec
[  5]   5.00-6.00   sec  2.88 MBytes  24.1 Mbits/sec
[  5]   6.00-7.00   sec  3.25 MBytes  27.3 Mbits/sec
[  5]   7.00-8.00   sec  3.38 MBytes  28.3 Mbits/sec
[  5]   8.00-9.00   sec  2.75 MBytes  23.1 Mbits/sec
[  5]   9.00-10.00  sec  1.25 MBytes  10.5 Mbits/sec

Mais iperf3observações:

  • A outra direção (adicionando -R) iperf3é muito mais rápida, a ~900 Mbit/s. (Observe que os lados do Linux estão usando o controle de congestionamento BBR, o que provavelmente ajuda nessa direção.)
  • Ao fazer download com 30 conexões ( iperf3com -P 30), a conexão de 1 Gbit/s é atingida no máximo, sugerindo que o problema é a taxa de transferência de upload de uma única conexão de upload TCP .
  • Ao substituir a máquina Windows por uma Linux na Finlândia, ambas as direções atingem o máximo de 1 Gbit/s de conexão. Isso me leva a concluir que o envolvimento do Windows é a falha .
  • Observe que há um artigo da Microsoft alegando que iperf3é o melhor para medições de alto desempenho no Windows. Isso não é relevante para esta questão porque se aplica apenas a conexões >= ~10 Gbit/s, e o fato de que iperf3 em várias máquinas Windows/Linux no mesmo datacenter prova que a velocidade de 1 Gbit/s é facilmente atingível iperf3em ambas as direções.

Em 2021, o Dropbox lançou um artigo Aumentando a velocidade de upload do Dropbox e melhorando a pilha TCP do Windows , que aponta o tratamento incorreto (incompleto) do Windows de retransmissões TCP; a Microsoft publicou Melhorias algorítmicas aumentam o desempenho do TCP na Internet junto com isso.

Isso parece explicar em grande parte, e o Wireguard lento, mas apenas para upload do Windows, mostra uma solução potencial, ou seja, alterar o número de filas RSS ( Receive Side Scaling ) para 1:

ethtool -L eth0 combined 1

Isso muda de 16(16 threads no meu servidor Linux dedicado) para 1 e aumenta a velocidade de upload do iperf3 convergente de 10.5para 330Mbit/s .

Isso é bom, mas deveria ser 1000 Mbit/s.

Especialmente estranho: Ao testar windows -> linux-Hetzner-Cloudem vez de windows -> Hetzner-dedicated, observo velocidades de upload perfeitas:

C:\Users\Administrator\Downloads\iperf3.17.1_64\iperf3.17.1_64>iperf3.exe -c linux-germany-hcloud.example.com

Connecting to host linux-germany-hcloud.example.com, port 5201
[  5] local 192.0.2.1 port 55615 connected to 192.0.2.3 port 5201
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec   108 MBytes   903 Mbits/sec
[  5]   1.00-2.00   sec   112 MBytes   942 Mbits/sec
...
[  5]   9.00-10.00  sec   112 MBytes   942 Mbits/sec

Isso é estranho, porque a máquina de nuvem tem especificações muito mais baixas. Ela tem 8 núcleos virtuais, mas sua ethtool -lsaída já é padrão Combined: 1porque, sendo uma VM, ela não suporta RSS de forma alguma:

root@linux-germany-hcloud ~ # ethtool -x enp1s0

RX flow hash indirection table for enp1s0 with 1 RX ring(s):
Operation not supported
RSS hash key:
Operation not supported
RSS hash function:
    toeplitz: on
    xor: off
    crc32: off

Então, de alguma forma, a máquina mais fraca não tem o problema. Talvez haja alguma coisa inteligente de hardware NIC acontecendo na máquina dedicada que cria o problema? O que poderia ser?

Eu já tentei desabilitar o TCP Segment Offloading ( ethtool -K eth0 tso off), mas isso não afeta os resultados. O recurso que causou o problema no artigo do Dropbox ( flow-director-atr) não está disponível na minha NIC, então não pode ser isso.

Pergunta

O que pode explicar o gargalo adicional de 3x no upload entre os dois servidores Linux?

Como posso obter uploads rápidos apenas do Windows?

Mais informações sobre o meio ambiente

  • Ambas as máquinas Linux usam a mesma versão Linux 6.6.33 x86_64e os mesmos sysctls (garantidos via NixOS), que são: 
    net.core.default_qdisc=fq
net.core.rmem_max=1073741824
net.core.wmem_max=1073741824
net.ipv4.conf.all.forwarding=0
net.ipv4.conf.net0.proxy_arp=0
net.ipv4.ping_group_range=0 2147483647
net.ipv4.tcp_congestion_control=bbr
net.ipv4.tcp_rmem=4096 87380 1073741824
net.ipv4.tcp_wmem=4096 87380 1073741824
  • Servidor Windows 2019Version 1809 (OS Build 17763.6293)

Editar 1

Descobri que consigo upload de 950 Mbit/s do Windows para outras máquinas dedicadas da Hetzner. As máquinas dedicadas para as quais o upload é lento têm em comum o fato de terem placas de rede Intel de 10 Gbit/s; de lspci:

01:00.0 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01)

lsmod | grep ixgbesugere que o ixgbedriver seja usado aqui. ixgbetambém é mencionado no artigo do Dropbox acima . O artigo "Por que o Flow Director causa reordenação de pacotes?" que eles vinculam menciona Intel 82599especificamente. Também encontrei este tópico e1000-devel onde alguém menciona o problema em 2011, mas nenhuma solução é apresentada.

Ao usar o cartão de 1 Gbit Intel Corporation I210 Gigabit Network Connection (rev 03)presente no mesmo modelo de servidor, o problema desaparece e obtenho 950 Mbit/s.

Então parece haver algo específico sobre 82599ES/ ixgbeque causa o problema.

Edição 2: Intel Flow Directore tentar fora da árvoreixgbe

Uma pesquisa no Google intel disable flowdirectorproduz https://access.redhat.com/solutions/528603 mencionando Intel 82599.

Ajuda:

O Intel Flow Director é um recurso de driver e NIC da Intel que fornece direção inteligente e programável de tráfego de rede semelhante (ou seja, um "fluxo") para filas de recebimento específicas.

Por padrão, o Flow Director opera no modo ATR (Application Targeted Receive). Isso executa hash regular no estilo RSS quando tráfego não visto anteriormente é recebido. No entanto, quando o tráfego é transmitido, a tupla (ou "fluxo") desse tráfego é inserida na tabela de hash de recebimento. O tráfego futuro recebido na mesma tupla será recebido no núcleo que o transmitiu. O processo de envio e recebimento pode então ser fixado no mesmo núcleo que a fila de recebimento para melhor afinidade de cache da CPU.

Observe que a pesquisa da comunidade mostrou que o ATR pode causar tráfego TCP Out-of-Order quando processos são migrados entre CPUs . É melhor fixar explicitamente processos em CPUs ao usar o modo ATR.

O FlowDirector é mencionado no artigo do Dropbox, assim como o ATR.

A "pesquisa comunitária" mencionada é o mesmo artigo "Por que o Flow Director causa reordenação de pacotes?" ao qual o Dropbox se refere.

Fazendo o sugerido

ethtool -K net0 ntuple on

melhora a velocidade de 20 Mbit/s para 130 Mbit/s (com o padrão ethtool -L net0 combined 16). Executá-lo por mais tempo ( iperf3 --time 30) faz com que ele caia para 80 Mbit/s após 16 segundos. Usar ntuple onjunto com combined 16não melhora mais.

Portanto, esta não é uma solução completa.

Testando a options ixgbe FdirMode=0abordagem em seguida.

Sobre ram256g-1:

rmmod ixgbe; modprobe ixgbe FdirMode=0; sleep 2; ifconfig net0 94.130.221.7/26 ; ip route add 192.0.2.2 dev net0 proto static scope link ; ip route add default via 192.0.2.2 dev net0 proto static ; echo done

dmesgmostra

ixgbe: unknown parameter 'FdirMode' ignored

Isso apesar de https://www.kernel.org/doc/Documentation/networking/ixgbe.txt documentá-lo:

FdirMode
--------
Valid Range: 0-2 (0=off, 1=ATR, 2=Perfect filter mode)
Default Value: 1

  Flow Director filtering modes.

Então 0=offparece ainda mais desejável que os outros dois, que supostamente são os que ntuple on/offalternam entre eles.

https://access.redhat.com/solutions/330503 diz

A Intel optou por expor algumas configurações como um parâmetro de módulo em seu driver SourceForge, no entanto, o kernel Linux upstream tem uma política de não expor um recurso como uma opção de módulo quando ele pode ser configurado de maneiras já disponíveis, então você só verá alguns parâmetros de módulo em drivers Intel fora da árvore do kernel Linux upstream.

A Red Hat segue os métodos do kernel upstream, então essas opções não estarão na versão RHEL do driver, mas a mesma coisa pode ser feita com ethtool(e sem) uma recarga de módulo.

Isso sugere que isso 0=offnão é realmente possível.

Ou talvez funcione com modprobe.dopções, mas não com o modprobecomando?

Código relevante:

Mas parece que https://github.com/intel/ethernet-linux-ixgbe ainda está sendo desenvolvido ativamente e suporta todas as opções antigas. Também suporta FdirPballoco que nunca existiu em torvalds/linux. Isso é descrito em: https://forum.proxmox.com/threads/pve-kernel-4-10-17-1-wrong-ixgbe-driver.35868/#post-175787 Também relacionado: https://www.phoronix.com/news/Intel-IGB-IXGBE-Firmware-Update Talvez eu deva tentar construir e carregar isso?

Desse driver, FDirModetambém foi removido:

De https://lists.osuosl.org/pipermail/intel-wired-lan/Week-of-Mon-20160919/006629.html :

ethtool -K ethX ntuple on

Isso habilitará o modo "filtro perfeito", mas ainda não há filtros, então os pacotes recebidos retornarão ao RSS.

Testado

ethtool -K net0 ntuple on
ethtool --config-ntuple net0 flow-type tcp4 src-ip 192.0.2.1 action 1

Não melhorou a velocidade.

Também descobri que a velocidade no Linux 6.3.1parece ser de 90 Mbit/s, enquanto no 6.11.3.

Compilando o out-of-tree ethernet-linux-ixgbeno Hetzner Rescue System Linux (old)que tem 6.3.1(ainda não há lançamento para Linux 6.11):

wget https://github.com/intel/ethernet-linux-ixgbe/releases/download/v5.21.5/ixgbe-5.21.5.tar.gz
tar xaf *.tar.gz
cd ixgbe-*/src && make -j

# because disconnecting the ethernet below will hang all commands
# from the Rescue Mode's NFS mount if not already loaded into RAM
ethtool --help
timeout 1 iperf3 -s
dmesg | grep -i fdir

modinfo /root/ixgbe-*/src/ixgbe.ko  # shows all desired options

rmmod ixgbe; insmod /root/ixgbe-*/src/ixgbe.ko; sleep 2; ifconfig eth1 94.130.221.7/26 ; ip route add 192.0.2.2 dev eth1 scope link ; ip route add default via 192.0.2.2 dev eth1 ; echo done

iperf3 -s

Este driver fornece 450 Mbit/s mais sólidos imediatamente.

rmmod ixgbe; insmod /root/ixgbe-*/src/ixgbe.ko FdirPballoc=3; sleep 2; ifconfig eth1 94.130.221.7/26 ; ip route add 192.0.2.2 dev eth1 scope link ; ip route add default via 192.0.2.2 dev eth1 ; echo done

dmesg | grep -i fdir

iperf3 -s

Não traz nenhuma melhoria.

Experimente também:

AtrSampleRate

Um valor de 0 indica que o ATR deve ser desabilitado e nenhuma amostra será coletada.

rmmod ixgbe; insmod /root/ixgbe-*/src/ixgbe.ko AtrSampleRate=0; sleep 2; ifconfig eth1 94.130.221.7/26 ; ip route add 192.0.2.2 dev eth1 scope link ; ip route add default via 192.0.2.2 dev eth1 ; echo done

dmesg | grep -i atrsample

iperf3 -s

Não traz nenhuma melhoria.

ethtool -L net0 combined 1aqui também não traz nenhuma melhoria, e

ethtool -K eth1 ntuple on
ethtool -L eth1 combined 12  # needed, otherwise the out-of-tree ixgbe driver complains with `rmgr: Cannot insert RX class rule: Invalid argument` when `combined 1` is set
ethtool --config-ntuple eth1 flow-type tcp4 src-ip 192.0.2.1 action 1

também não traz nenhuma melhoria.

Edição 3: NIC alterado

Alterei a NIC do servidor Linux de Intel 82599ES para Intel X710, que usa o i40edriver Linux.

O problema persistiu.

Suspeito que seja porque o X710 também suporta o Intel Flow Director.

A mitigação parcial ethtool -L eth0 combined 1tem o mesmo efeito que para o 82599ES.

O comando

ethtool --set-priv-flags eth0 flow-director-atr off

(o que é possível i40e, mas não ixgbe) mencionado pelo Dropbox como solução alternativa só alcançou a mesma aceleração que ethtool -L eth0 combined 1(em torno de 400 Mbit/s).

Curiosamente, Hetzner relatou que as máquinas Hetzner Cloud também são equipadas com Intel X710 , mas não apresentam o problema.

linux-networking

1 respostas

  1. Best Answer

    Parece que encontrei uma solução para obter velocidade máxima ( ressalvas abaixo):

    ethtool -L eth0 combined 1
sysctl -w net.ipv4.tcp_sack=0

    Esse

    • desabilita o Intel FlowDirector na NIC na medida em que define uma única fila
    • desabilita o suporte TCP SACKdo kernel Linux

    Eu já tinha tentado a primeira linha antes (ela resultou em um problema moderado), mas desabilitar os SACKs com a segunda linha resolveu completamente o problema para mim, produzindo velocidade de upload de gigabit total na máquina Windows.

    Cada linha sozinha não produz uma melhoria, mas combinadas elas corrigem o problema.

    Isso corrige o problema nos servidores Intel X710 e Intel 82599ES.

    Advertência:

    Acredito que um efeito colateral de desabilitar SACKs é que, se houver perda de pacotes, a velocidade da conexão cai temporariamente mais do que com SACKs habilitados. No entanto, ela se recupera em poucos segundos e, em média, observei uploads bem-sucedidos de velocidade de gigabit total do Windows Server 2019 com essas configurações. Testarei mais na situação do Windows-10-pela-Internet em breve, pois só testei Windows-Server-2019-HEL1 -> Linux-FSN1 até agora.

    Editar: Agora confirmei que isso sysctl -w net.ipv4.tcp_sack=0é prejudicial em conexões WAN de longo alcance que têm perda de pacotes. Assim que alguma perda de pacotes acontece, isso faz a velocidade da conexão cair muito.

    Portanto, fazer a abordagem de velocidade máxima com ambas as configurações é recomendado apenas em conexões onde você sabe que a perda de pacotes é baixa . Se você estiver recebendo da Internet geral, é melhor usar apenas

    ethtool -L eth0 combined 1

    e manter sysctl -w net.ipv4.tcp_sack=1. Isso será mais confiável pela Internet.

    Faz algum sentido que desabilitar SACKs tenha algum efeito, já que o artigo do Dropbox (e a declaração citada da Microsoft) também menciona SACKs.

    Ainda não entendo o que causa meu

    As máquinas Hetzner Cloud também são equipadas com Intel X710, mas não apresentam o problema

    observação. Definir net.ipv4.tcp_sackem seus hosts VM não deve ter efeito porque o convidado Linux deve estar no controle do TCP, não da máquina host; o convidado tem o tcp_sack=1padrão e ainda assim funciona. Talvez haja mais configurações de NIC que podem atingir o mesmo efeito que desabilitar SACKs no kernel que eu ainda não descobri, ou talvez dispositivos ao longo do caminho de rede de servidores dedicados não consigam lidar bem com SACKs, e esses dispositivos não existam ao longo do caminho de rede de máquinas Hetzner Cloud.

    Este artigo menciona problemas de equipamentos de rede com SACK, mas menciona principalmente paralisações completas da conexão, em vez de lentidão:

    Quando desligar o TCP SACK?

    Também observei que o Windows 11 (testei o 23H2) tem esse problema corrigido. De acordo com o artigo da Microsoft na pergunta, o Windows Server 2022 também tem isso corrigido.

    • 0

relate perguntas