Atualmente estou construindo uma nova iteração do meu roteador DIY - o novo sistema tem um par de portas de 10 GB. Estou executando o Ubuntu 23.04 em um R68S U1
Inicialmente, durante os testes de velocidade com o iperf2 entre um sistema que eu sei que pode suportar velocidades de linha de 10 giga, eu estava obtendo velocidades de 5 giga. Um dos guias da Asus para seus equipamentos sugeriu testar com iperf a 800k
geek@router-t1:~$ iperf -s -w 800k
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 416 KByte (WARNING: requested 781 KByte)
------------------------------------------------------------
[ 1] local 10.0.0.1 port 5001 connected with 10.0.0.2 port 52191
[ ID] Interval Transfer Bandwidth
[ 1] 0.0000-60.0461 sec 35.0 GBytes 5.01 Gbits/sec
Curiosamente, isso indicava que o tamanho da minha janela TCP era menor, e foi exatamente sobre isso que a Asus alertou.
Isso nunca acontece com clientes Windows, apenas com Linux... o que é curioso, mas provavelmente outro problema
Adicionando as seguintes linhas - conforme sugerido aqui
net.core.wmem_max=4194304
net.core.rmem_max=12582912
net.ipv4.tcp_rmem = 4096 87380 4194304
net.ipv4.tcp_wmem = 4096 87380 4194304
resultou no dobro dos benchmarks
geek@router-t1:~$ iperf -s -w 800k -B 10.0.0.1
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 1.53 MByte (WARNING: requested 781 KByte)
------------------------------------------------------------
[ 1] local 10.0.0.1 port 5001 connected with 10.0.0.2 port 57480
[ ID] Interval Transfer Bandwidth
[ 1] 0.0000-60.0443 sec 69.2 GBytes 9.90 Gbits/sec
Eu entendo que isso ajusta o buffer de recebimento do soquete e o tamanho de um buffer para um soquete recém-criado - a IBM tem uma explicação muito boa aqui sobre o que eles fazem aqui
Como eu calcularia o tamanho apropriado para um determinado sistema e por que isso teria um efeito tão dramático?
Para obter rendimento máximo, os tamanhos das janelas TCP devem ser grandes o suficiente para permitir que o remetente "mantenha o canal cheio", o que significa que ele precisa ser capaz de continuar enviando segmentos de tamanho completo tão rápido quanto o link pode suportar, por tempo suficiente para obter um Ack de volta para o primeiro pacote. Esse tempo de confirmação será o tempo de ida e volta (RTT) do caminho da rede, que é o que
ping(8)
mede, mas observe que o RTT medido pelo ping em uma rede ociosa provavelmente será menor do que o RTT que seu remetente TCP vê ao manter um Link de 10 Gbps completo.Normalmente chamamos esse cálculo de “Produto Largura de Banda x Atraso” (BDP). Portanto, multiplique sua largura de banda em bits por segundo e seu RTT em segundos. Isso permite que os segundos sejam cancelados, deixando você com o número de bits que podem precisar estar "em vôo" ("na rede", "no tubo") a qualquer momento, para manter o tubo cheio.
Portanto, usando tempos de ping ociosos típicos de LAN Ethernet com fio de 10 Gbps e 0,3 ms que normalmente vejo em minhas LANs Ethernet, seriam 10.000.000.000 bits/seg x 0,0003 segundos = 3.000.000 bits = cerca de 366 KibiBytes.
Portanto, para uma primeira aproximação, sua janela TCP original de 416 KiByte deveria ter permitido desempenho em velocidade total. Isso indica que minha estimativa de RTT de 0,3 ms foi baixa para a realidade do TCP em seu link de 10 Gbps quando cheio.
Se eu revisar minha estimativa de RTT para 1 ms, obtenho um BDP de 1,2 MiBytes, que está mais alinhado com o tamanho de 1,53 MiByte para o qual sua pilha TCP do Linux escalou automaticamente sua janela em seu exemplo bem-sucedido depois que você ajustou seus sysctls para dar mais espaço para escalar.
Fornecer a cada conexão TCP alguns MebiBytes de RAM para uma janela de recebimento é bom para máquinas pessoais em uma LAN, mas pode ser um problema para servidores ocupados que precisam lidar com centenas ou milhares de conexões TCP simultâneas. Você pode ficar sem RAM muito rapidamente. Essa é parte da razão pela qual a maioria das implementações modernas de TCP possuem algoritmos de escalonamento automático de janela integrados e habilitados por padrão, mas limitados por um sysctl.