Por que o ssh teria um desempenho mais lento que o iperf3?

Question

Estou frustrado com o que parece ser o cliente / servidor openssh com um máximo de ~ 1,03 gigabits / s, enquanto o iperf3 pode suportar 7,03 gigabits / s facilmente sobre o mesmo link ponto a ponto.

• Forçando o Nagle ,
• usando o nc como um sxy ProxyCommand ,
• [desativando a compactação] ( link ,
• forçando cifras específicas ,

nada disso tem qualquer efeito;

• carga de cpu está abaixo de 70% (de 2400% no total) nas duas caixas durante os testes de teste iperf e de transporte ssh,
• não há dispositivos de bloco envolvidos

Eu apenas não entendo, é ssh simplesmente incapaz de 10gbe? As cifras ou hashing estão me atrasando? Alguém codificou um limite de gigabit na fonte do cliente openssl? Eu terei que abrir 8+ conexões ssh independentes para lançar dados através deste pipe na velocidade da linha?

Como visto abaixo, os minúsculos sinais verdes são cat /dev/zero | ssh target 'cat >/dev/null' ; o blob roxo / laranja é iperf3 sobre o encaminhamento de porta ssh, os blips altos são regulares iperf3

Algumas estatísticas;

• iperf3 sobre o link dedicado: 7.11Gbits / s

  (Eu suspeito que o uso inadequado da fibra tenha reduzido isso do seu desempenho original de 9 Gbit novo, se vi)

• iperf3 sobre link dedicado (mtu = 9000): 7,55 Gbits / s

• iperf3 sobre o gbe lan: 941Mbits / s
• iperf3 sobre ssh no link direto: 1,03 Gbits / s

• iperf3 sobre ssh em lan gigabit: 941Mbits / s

  (Então, o ssh está usando a rota certa, e ainda é um pouco mais rápido que o gbe regular para usar)

• iperf3 sobre ssh com ProxyCommand nc: 1.1Gbit / s

  (outro ganho muito muito magro)

• iperf3 sobre ssh com ProxyCommand nc (mtu = 9000): 1.01Gbit / s

  (o mtu parece ter classificado a velocidade do link neste caso)

Answer 1

Os quase 7Gbps são aparentemente um valor falso porque é apenas um pico máximo (os "blips") e não uma taxa de transferência sustentada. Isso pode acontecer por causa das maneiras como o software de rede estima a velocidade de transferência (um pacote pequeno que não ocupa toda a sua banda pode chegar mais rapidamente). De fato, você tem uma média de 200Mbps na mesma linha da leitura de 7Gbps. Tente com uma transferência sustentada de um arquivo adequadamente grande, digamos > 1 GB

    

Answer 2

Parece que o SSH é incapaz de fazer transferências mais rápidas, de qualquer forma, para uma única instância. Eu finalmente percebi que deveria executar o teste em loopback (no loopback 4.10.0 linux pode sustentar 12Gbits / s) e ssh para loopback ainda só executou perto de 125 ~ 135Mbits / s; Mesmo assim, o sistema de arquivos ext4 em um ssd pode apenas carregar até ~ 30-50 Mbits / s; para transferências grandes, decidi estabelecer um link fisicamente seguro e usar o dd sobre o netcat; quais afunilamentos na taxa de transferência da matriz de disco, não no sistema de arquivos ou no protocolo de transferência. Eu também estava habilitado para obter aria2 para trabalhar com o sftp, então eu desisti de transferências paralelas do cliente ssh. Parece que há um longo caminho a percorrer ... ~