Metodologias para teste de desempenho de um link WAN

Question

Temos um par de novos links Ethernet de 1 Gbps de rota diversa entre locais com cerca de 320 km de distância. O 'cliente' é uma nova máquina razoavelmente poderosa (HP DL380 G6, dual E56xx Xeons, 48GB DDR3, par R1 de discos SAS 300GB 10krpm, W2K8R2-x64) e o 'servidor' é uma máquina decente o suficiente (HP BL460c G6 , dual E55xx Xeons, 72GB, par R1 de discos SAS de 10krpm 146GB, HBA FC Emulex de 4 Gbps de porta dupla vinculado a Cisco MDS9509s duplos e HP EVA 8400 dedicado com discos FC de 128 x 450GB 15krpm, RHEL 5.3-x64).

Usando o SFTP do cliente, estamos vendo apenas 40 Kbps de taxa de transferência usando arquivos grandes (> 2 GB). Realizamos testes de servidor para 'outros servidores locais' e vemos cerca de 500Mbps através dos switches locais (Cat 6509s), vamos fazer o mesmo no lado do cliente, mas isso é um dia ou mais de distância.

Que outros métodos de teste você usaria para provar aos provedores de link que o problema é deles?

    

Answer 1

Ajustando um elefante:
Isso pode exigir ajuste, provavelmente não é o problema aqui, como o pQd diz. Esse tipo de link é conhecido como "Long, Fat Pipe" ou Elephant (veja RFC 1072 ). Como esse é um gigabit pipe gordo passando por uma distância (a distância é realmente tempo / latência nesse caso), a janela tcp receive precisa ser grande (veja o Capítulo 1 do TCP / IP Illustrated, Seção de Extensões TCP para fotos).

Para descobrir qual deve ser a janela de recebimento, calcule o produto de atraso de largura de banda:

Bandwidth * Delay = Product

Se houver latência de 10MS, esta calculadora estima que você deseja receber uma janela de cerca de 1,2 MBytes. Podemos fazer o cálculo com a fórmula acima:

echo $(( (1000000.00/.01)/8  )) 
12500000

Assim, você pode querer executar um dump de pacote para ver se a escala da janela tcp (a extensão TCP que permite maior Windows) está acontecendo certo para ajustar isso uma vez que você descobrir o que é o grande problema.

Limite de janela:
Se este é o problema, se você está vinculado ao tamanho da janela sem dimensionamento, esperaria os seguintes resultados, se não houver um dimensionamento de janela e houver uma latência de aproximadamente 200 ms, independentemente do tamanho do canal:

Throughput = Recieve Window/Round Trip Time

Então:

echo $(( 65536/.2 ))
327680 #Bytes/second

Para obter os resultados que você está vendo, basta resolver a latência, que seria:

RTT = RWIN/Throughput

Então (para 40 kBytes / s):

echo $(( 65536.0/40000.0 )) 
1.63 #Seconds of Latency

(Por favor, verifique minha matemática, e estes, claro, não incluem toda a sobrecarga de protocolo / cabeçalho)

    

Answer 2

40kbps é muito baixo [até o ponto que eu suspeitaria de falhas de conversores de mídia / incompatibilidade de duplex [mas você tem gigabit então não há lugar para half duplex!] etc]. deve haver perdas de pacotes ou jitter muito alto envolvido.

iperf é a primeira ferramenta que me vem à mente para medir a taxa de transferência disponível. correr de um lado

iperf -s 

e, por outro:

iperf -t 60 -c 10.11.12.13

então você pode trocar funções de cliente / servidor, usar -d para duplex etc. executar mtr entre as duas máquinas antes do início do teste e ver quais latências / pacotes de perda você tem no link não usado, e como eles mudam durante os dados transferir.

você gostaria de ver: tremulação muito pequena e nenhuma perda de pacotes até que o link esteja saturado a 90 por cento de sua capacidade.

iperf para * nix e win , leia aqui e aqui sobre isso.

mtr para * nix e vitória .

    

Answer 3

O tracepath pode mostrar problemas de roteamento entre os dois sites.

iperf, ttcp e bwping podem fornecer informações úteis.

você sabe como esse link de 1 GB está sendo provisionado? você está fazendo uma ponte ou roteando esse link? Qual é o seu SLA para o link? você poderia ser moldado pelo seu provedor de links?

se você está recebendo apenas 40kbs, então há um problema sério, você tem certeza de que não é um link de 1MB em vez de um link de 1GB / s. Você provavelmente descobrirá que a velocidade do link não é o que você pensa: -)

    

Answer 4

RFC 2544 ou Y.156sam

Estes são testes de rede que são feitos para provar o SLA pela operadora. IPERF e similares não são métodos de teste de rede verificáveis.