Controle de congestionamento TCP para redes 10GbE -> 1GbE de baixa latência?

11

Eu tenho um servidor com uma conexão de 10 GbE para um switch e 10 clientes, cada um com uma conexão de 1 GbE para o mesmo switch.

Executando o nuttcp em paralelo em cada um dos clientes, posso enviar 10 fluxos de dados TCP para o servidor simultaneamente, próximo à velocidade do fio (ou seja, apenas a 100 megabytes por segundo dos 10 clientes simultaneamente).

No entanto, quando inverto a direção e envio dados do servidor para os clientes - ou seja, 10 fluxos TCP, um indo para cada cliente - as retransmissões TCP disparam e o desempenho cai para 30, 20 ou até 10 megabytes por segundo por cliente. Quero aumentar esses números, porque esse padrão de tráfego é representativo de certos aplicativos importantes para mim.

Eu verifiquei que meu servidor é capaz de saturar um link de 10GbE realizando o mesmo experimento em uma conexão de 10GbE a um servidor semelhante. Eu verifiquei que não há erros em nenhuma das minhas portas.

Finalmente, quando clico (limite) à força o tamanho da janela TCP do receptor, posso obter uma largura de banda um pouco maior (30-40 megabytes / s); e se eu apertá-lo extremamente baixo, posso zerar as retransmissões (com a largura de banda ridiculamente baixa).

Portanto, estou razoavelmente confiante de que estou substituindo os buffers no meu switch, resultando em perda de pacotes devido ao congestionamento. No entanto, eu pensei que o controle de congestionamento do TCP deveria lidar com isso muito bem, eventualmente estabilizando em algo acima de 50% da velocidade do fio.

Portanto, minha primeira pergunta é muito simples: qual algoritmo de controle de congestionamento TCP seria melhor para minha situação? Há uma tonelada deles disponíveis, mas eles parecem ser direcionados principalmente para redes com perdas ou redes de alta latência e largura de banda alta ou redes sem fio ... Nenhuma delas se aplica à minha situação.

Segunda pergunta: Há mais alguma coisa que eu possa tentar?

linux networking tcp Nemo
fonte
1
Seria útil saber qual modelo de switch. Switches diferentes lidam com enfileiramento de maneiras diferentes e ajudariam a restringir uma solução.
scottm32768
2
Switches diferentes também têm tamanhos de buffer diferentes, portanto, conhecer o modelo do switch ajudaria a eliminar problemas de hardware do seu problema.
Ct_fink 20/03/2013
1
Além disso, os modelos de NIC, drivers, versão Linux, kernel, distribuição etc. Minhas respostas para uma placa de rede Myricom ou Solarflare com um Cisco 4900M seriam diferentes de um switch Dell Powerconnect e placas de rede Intel.
ewwhite

Respostas:

2

  1. Você deseja um algoritmo em que o tamanho da janela não seja drasticamente reduzido quando houver uma queda de pacotes. É a queda drástica no tamanho da janela que resulta na queda repentina no rendimento com o tráfego TCP.

  2. Se seu switch e seu servidor suportam controle de fluxo, tente ativar o controle de fluxo. O quão bem isso funciona depende quase inteiramente do silício e firmware do Switch. Basicamente, o switch detectará o congestionamento de saída na porta conectada a um cliente, determinará a origem dos pacotes e enviará quadros de controle de fluxo pela porta de entrada (ou seja, de volta ao servidor). Se o servidor entender os quadros de controle de fluxo, reduzirá a velocidade de transmissão. Se tudo funcionar bem, você obterá uma taxa de transferência ideal com praticamente zero número de pacotes ocorrendo no buffer de saída do comutador.

wookie919
fonte