Eu encontrei a solução para o problema. Tudo o que precisei fazer foi desligar o descarregamento de segmentação na placa de rede:
ethtool -K eth0 gso off tso off
Isso resolveu o problema para mim. Aparentemente é bastante comum.
Ontem recebi uma nova e brilhante conexão VDSL2 em casa! É especificado a 100Mbit / 10Mbit e parece entregar muito perto da marca.
Agora, eu tenho uma caixa do Debian squeeze linux atuando como um NAS e roteador doméstico. Está rodando o shorewall, com NAT e tc habilitados. Eu também tenho uma estação de trabalho OSX conectada através de um switch ao referido roteador linux:
Estação de trabalho OSX < - > Mudar < - > Roteador Debian < - > Modem VDSL2 < - > Internet < - > Servidor
Eu fiz testes contra o meu servidor rápido na internet:
No roteador Linux, TCP :
$ iperf -c server -p 3333
------------------------------------------------------------
Client connecting to server, TCP port 3333
TCP window size: 23.5 KByte (default)
------------------------------------------------------------
[ 3] local xxx.yyy.bbb.ccc port 41982 connected with xxx.yyy.bbb.ccc port 3333
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 2.89 MBytes 2.42 Mbits/sec
No acima, é onde está o problema. O uplink deve ter ~ 10Mbit, não 2.4Mbit. Abaixo, você pode ver que o UDP está funcionando bem.
No roteador Linux, UDP :
$ iperf -u -c server -p 60008 -b 9M
------------------------------------------------------------
Client connecting to server, UDP port 60008
Sending 1470 byte datagrams
UDP buffer size: 1.00 MByte (default)
------------------------------------------------------------
[ 3] local xxx.yyy.bbb.ccc port 56484 connected with xxx.yyy.bbb.ccc port 60008
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 10.7 MBytes 9.00 Mbits/sec
[ 3] Sent 7658 datagrams
[ 3] Server Report:
[ 3] 0.0-10.0 sec 10.7 MBytes 9.00 Mbits/sec 0.251 ms 0/ 7657 (0%)
[ 3] 0.0-10.0 sec 1 datagrams received out-of-order
E na estação de trabalho OSX (atrás de NAT) TCP :
$ iperf -c server -p 3333
------------------------------------------------------------
Client connecting to server, TCP port 3333
TCP window size: 65.0 KByte (default)
------------------------------------------------------------
[ 5] local 192.168.9.141 port 54388 connected with xxx.yyy.bbb.ccc port 3333
[ ID] Interval Transfer Bandwidth
[ 5] 0.0-10.0 sec 13.2 MBytes 11.1 Mbits/sec
O OSX atrás do roteador linux parece não ser afetado pelos problemas no roteador linux. Como isso pode acontecer? O UDP também funciona bem.
E na estação de trabalho OSX (atrás de NAT) UDP :
$ iperf -u -c server -p 60008 -b 9M
------------------------------------------------------------
Client connecting to server, UDP port 60008
Sending 1470 byte datagrams
UDP buffer size: 9.00 KByte (default)
------------------------------------------------------------
[ 5] local 192.168.9.141 port 64588 connected with xxx.yyy.bbb.ccc port 60008
[ ID] Interval Transfer Bandwidth
[ 5] 0.0-10.0 sec 10.7 MBytes 9.00 Mbits/sec
[ 5] Sent 7658 datagrams
[ 5] Server Report:
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 5] 0.0-10.0 sec 10.7 MBytes 9.00 Mbits/sec 0.133 ms 0/ 7658 (0%)
Como você pode ver, a caixa linux está presa no TCP de saída de 2.5Mbit / s. O UDP funciona bem e a estação de trabalho atrás do roteador funciona bem.
Para simplificar a situação, modifiquei meu Shorewall TC para um nível muito básico. Eu também tentei desligar o TC da parede de terra sem nenhum efeito. :
tcdevices:
#INTERFACE IN-BANDWITH OUT-BANDWIDTH
eth0 - 12000kbit
tcclasses:
#INTERFACE MARK RATE CEIL PRIORITY OPTIONS
eth0 1 full full 1 default
tcrules:
#MARK SOURCE DEST PROTO PORT(S) CLIENT USER
1:F 0.0.0.0/0 0.0.0.0/0 icmp echo-request
1:F 0.0.0.0/0 0.0.0.0/0 icmp echo-reply
Você tem alguma idéia de onde o problema pode estar? A única coisa não padrão que estou executando no Debian é um kernel 3.2.0 de backports. A caixa é uma poderosa máquina Xeon com muita RAM e placas de rede Intel. Todos os testes foram feitos em um curto espaço de tempo com praticamente nenhum outro tráfego de rede. E repetido várias vezes. Onde eu poderia começar a depurar?
Alguns pontos:
1) O TCP pode demorar um pouco até atingir a velocidade máxima - tanto em termos de encontrar o tamanho de janela apropriado em fluxos mais longos quanto no tempo de configuração em fluxos mais curtos (isto é, 1,5 x RTT fazendo handshakes com TCP vs início imediato com UDP). 10 megabytes não são muito dados. Conforme você empurra em direção à marca 1G, você deve ver a velocidade média do TCP melhorar.
2.) Mesmo quando totalmente otimizado, há um trade-off entre confiabilidade e desempenho. O TCP pode ser excessivamente sensível a microbursts mesmo em perfeitas condições de laboratório. Atropelar uma configuração de DSL (não importa quão rápido) estará potencialmente expondo o fluxo de tráfego a quantidades variáveis de buffer, atraso de serialização, etc. Mais uma vez, isso tende a ficar acima da média em fluxos mais longos. O UDP (especialmente em benchmarks de desempenho) transmitirá o máximo que puder, sem levar em conta a perda de pacotes, o estouro de buffer, etc.
Portanto, a ideia com janelas TCP é que, se estiver funcionando perfeitamente, chegaremos a uma situação em que há uma quantidade ideal de tráfego em andamento com a menor porcentagem possível de sobrecarga (ou seja, confirmações, cabeçalhos TCP etc.). De fato, a quantidade de tráfego em trânsito deve permitir uma quantidade constante de largura de banda - até mesmo os reconhecimentos estão fluindo. O desempenho do TCP se aproximará assintoticamente de uma transmissão aberta de dados.
O UDP, em contraste, é uma transmissão aberta de dados ...
Agora - a diferença de desempenho entre as várias plataformas será função da implementação específica do TCP, bem como de como o próprio sistema está priorizando o processamento de I / O e protocolo. Pode haver um ajuste ou dois que trarão os dois valores para uma melhor paridade. O tamanho da amostra ainda será um problema. Quanto mais testes e quanto maior o tamanho, mais precisos serão os resultados.