tera-feira, 28 de agosto de 2012

Teste de Performance de Rede com Iperf

http://www.esli-nux.com/2012/08/teste-de-performance-de-rede-com-iperf.html Troubleshooting, Throughput, testes de conectividade e transmisso de pacotes em rede com Software Livre/Open Source

Sumrio
Base de Conhecimento Rede Local e o trfego de informaes O que Possveis situaes de uso O Bsico - Executando como Server No Windows No GNU/Linux O Bsico o Cliente No Windows No Linux Utilizando UDP Argumentando... Mais Opes Opes gerais -f, --format -i, --interval n -l, --len N -m, --print_mss -o, --output <arquivo> -p, --port n -u, --udp -x, --reportexclude -y, --reportstyle C -w, --window n -B, --bind <host> -M, --mss n -N, --nodelay -V, --IPv6Version Opes para o cliente -P , --parallel -T, --ttl -n, --num -t, --time -d, --dualtest -r, --tradeoff -L, --listenport -b, --bandwidth -F, --fileinput <name> -I, --stdin Opes para o Servidor -s, --server -U, --single_udp -D, --daemon Interface Grfica em JAVA Concluso Minha rede est lenta, e agora?? Download e Links

Base de Conhecimento
O TCP o protocolo da camada de transporte orientado conexo, que oferece um servio confivel. Frequentemente aparece como parte da pilha TCP/IP da arquitetura Internet, mas um protocolo de propsito geral que pode ser adaptado para ser usado com uma variedade de sistemas. O protocolo UDP restringido a portas e sockets, e transmite os dados de forma no orientada conexo. Ele nada mais do que uma interface para o protocolo IP. Esse protocolo substitui o protocolo TCP quando a transferncia de dados no precisa estar submetida a servios como controle de fluxo. A funo bsica do UDP servir de multiplexador ou demultiplexador para o trfego de informaes do IP. Assim como o TCP, trabalha com portas que orientam adequadamente o trfego de informao a cada aplicao de nvel superior. O UDP fornece os servios de broadcast e multicast, permitindo que um nico cliente envie pacotes para vrios outros na rede. O UDP uma escolha adequada para fluxos de dados em tempo real, especialmente aqueles que admitem perda ou corrompimento de parte de seu contedo, tais como vdeos ou voz. Aplicaes sensveis a atrasos na rede, mas poucos sensveis a perdas de pacotes, como jogos de computadores, tambm podem se utilizar do UDP. As garantias de TCP envolvem retransmisso e espera de dados, como consequncia, intensificam os efeitos de uma alta latncia de rede. Algum tratamento de erro pode ser adicionado, mas geralmente aplicaes multicast tambm admitem perda de parte dos pacotes ou fazem retransmisses constantes (tal como o ocorre no protocolo DHCP). O UDP no perde tempo com criao ou destruio de conexes. Durante uma conexo, o UDP troca apenas 2 pacotes, enquanto no TCP esse nmero superior a 10. Embora o processamento dos pacotes UDP seja realmente mais rpido, quando as garantias de confiabilidade e ordenao so necessrias, pouco provvel que uma implementao em UDP obter resultados melhores do que o uso direto do TCP. Em primeiro lugar, corre-se o risco de que uma implementao ingnua feita em UDP seja menos eficiente do que os algoritmos j testados e otimizados presentes no TCP. Em segundo lugar, boa parte do protocolo TCP, nos principais sistemas operacionais, opera em modo ncleo, tendo portanto uma execuo mais privilegiada do que um protocolo de aplicao teria. Finalmente, vlido lembrar que muitas placas de rede j possuem o TCP programado em seu firmware o que permite, por exemplo, o clculo de checksum por hardware. Por isso, o protocolo UDP no deveria ser utilizado para fluxos de bytes confiveis, tais como a transferncia de arquivos. Como exemplo, podemos citar o protocolo TFTP, exceo a essa regra, que foi feito redes locais, de alta confiabilidade. Na internet, seu desempenho muito inferior ao sua verso confivel, o protocolo FTP. De uma forma bem simplificada, A principal diferena entre ambos, que o tcp orientado a conexo, ou seja, antes de enviar os dados feito uma comunicao entre remetente e destinatrio, cria-se um canal de comunicao, ento transmitido os dados... J o udp no orientado a conexo, portanto os dados so enviados sem ter a certeza de que o receptor recebeu os dados... Isto mostra alguns pontos conclusivos entre TCP e UDP, o primeiro mais seguro, onde h um tratamento sobre perdas e conexo, j o segundo mais rpido e com melhor aplicabilidade em determinadas situaes (as vezes necessrias). Aplicativos que usam TCP: Telnet, FTP, SMTP, SSH, HTTP,... Aplicativos que usam UDP: SNMP, TFTP, RPC, DHCP,... O TCP, tal como o UDP, usa o IP para a entrega dos datagramas rede, e os pontos de acesso aplicao so identificados por portas acessadas por multiplexao, tal como acontece com o UDP, o que permite mltiplas ligaes em cada host. As portas podem ser associadas com uma aplicao (Processo). O IP trata o pacote TCP como dados e no interpreta qualquer contedo da mensagem do TCP, sendo que os dados TCP viajam pela rede em datagramas IP. Os roteadores que interligam as redes apenas verificam o cabealho IP, quando fazem o envio dos datagramas. O TCP no destino interpreta as mensagem do protocolo TCP.

Rede Local e o trfego de informaes

Nas comunicaes que ocorrem em redes locais Ethernet o endereo IP no diretamente usado na comunicao, ele serve apenas para se descobrir o MAC Address, que de fato o endereo que importa nas comunicaes locais. Essa descoberta feita atravs de um protocolo de rede chamado Address Resolution Protocol (ARP). De forma resumida, o switch fica responsvel por registrar cada interface MAC dos hosts conectados e enviar os pacotes aos hosts de destinos, no caso de um hub, ele no possui este mapeamento de MAC address, o pacote enviado a todas as maquinas. Jitter definida como a medida de variao do atraso entre os pacotes de dados. Observa-se ainda que uma variao de atraso elevada produz uma recepo no regular dos pacotes. Logo, uma das formas de minimizar a variao de atraso a utilizao de buffer, o qual armazena os dados medida que eles chegam e os encaminha para a aplicao seguindo uma mesma cadncia. Buffer uma regio de memria temporria utilizada para escrita e leitura de dados. Normalmente so utilizados quando existe uma diferena entre a taxa em que os dados so recebidos e a taxa em que eles podem ser processados, ou no caso em que essas taxas so variveis.

O que
O Jperf consiste em um software de anlise de performance de banda e clculo de perda de datagramas na rede, cria fluxo de dados sob TCP e UDP e permite medir e analisar o desempenho da rede. Ele mantido pela Universidade de Illinois. O Iperf um software livre, do tipo client/server desenvolvido pelo National Laboratory for Applied Network Research (NLANR), escrito em C++ e sua ltima verso a 2.0.5, disponibilizada em Julho/2010 (nota: h um projeto onde desenvolve-se a continuao de um novo iperf, atualmente a verso 3.0-beta4).

uma ferramenta multi-plataforma que pode ser executada atravs de qualquer tipo de rede (falo sobre topologias, infraestrutura, meios, etc...) e exibir resultados de desempenho padro com nveis em comum entre essas diferentes redes, assim, ele pode ser usado para a comparao de equipamentos de rede com e sem fio e tecnologias de uma maneira imparcial. Com o Iperf podemos testar/medir o throughput da rede, serve como ferramenta de apoio para outros testes em rede, simulao de conectividade, situao/diagnstico da situao do cabeamento (para certificar sua rede em relao a atividade e transmisso de dados, identificar segmentos da rede com falhas...). A funo exercida pelo Iperf tambm alcanada utilizando alguns softwares no linux com propositos de network tools, como scanners, sniffers e outros de monitoramento. O diferencial que nesses aplicativos o administrador teria pouca informao (como um simples ping) ou, num software mais robusto, teria que peneirar a informao desejada dentro de uma inundao de logs gerados, o Iperf justamente a aplicao que ir dar a informao desejada. Outros softwares semelhantes ao Iperf so: ttcp (test tcp) e bwping. Veja no final do tutorial os links para downloads, verses do iperf e jperf alm de outros links ;-)

Instalao no GNU/Linux: Depois de ter baixado o aplicativo descompacte e compile. root@server ~ # tar -zxvf iperf-2.0.5.tar.gz root@server ~ # cd iperf-2.0.5 root@server ~ # ./configure ; make ; make install

Seu funcionamento simples, na configurao padro, o cliente passar a enviar trfego TCP para o servidor por 10 segundos, e em seguida mostrar a quantidade dados transferida (MBytes) e a velocidade atingida (Mbits/s). Deve haver no minimo duas maquinas com o Iperf em sua rede. Uma ser executada como servidor a outra como cliente. Por padro o iperf usar a porta TCP 5001, certifique-se que no h nenhum tipo de firewall bloqueando esta porta (tanto nas maquinas cliente/servidor) ou na rede.

Possveis situaes de uso

Bem, aqui a coisa complica ;-) Podemos criar alguns ambientes simulando possveis situaes para o uso do iperf, mas pode ficar meio confuso, pois os resultados obtidos em softwares mais complexos so mais aproveitveis e fceis de se adquirir do que com o iperf, para qualquer administrador de rede. O primeiro caso utilizado por mim (e sempre aconselho a utilizarem), a utilizao para fins acadmicos (lembra que ele mantido por uma Universidade??), o iperf uma tima ferramenta para ensino. Leva o aluno a usar um sistema operacional, testar numa rede real, ao invs de simuladores de rede com softwares complexos para ministrar contedos simples. Inserindo em um ambiente corporativo: Como provar para um superior dentro da empresa que um determinado segmento da rede, uma sala, andar precisa de uma nova infraestrutura de rede, novos cabeamentos, que precisa de melhorias?? Voc no vai levar um diretor para ficar vendo canaletas, cabos utp empoeirados, racks e guias?? No mundo corporativo ningum sabe a diferena entre fibra ptica e coxial, o que importa sos nmeros, o impacto financeiro que causa na receita, na margem... Com o iperf voc coloca o iperf server num ponto em comum (um servidor da rede, firewall, dmz, qualquer ponto onde todos os hosts devem acessar), e executa os testes com o iperf cliente a partir de um ponto de rede bom e outro a partir do local onde com certeza problemtico. Voc ter contedo suficiente para produzir uma boa documentao (seguindo todos os processos gerenciais, administrativos, e bla-bla-bla), obviamente com argumentos e teorias/normas de cabeamento estruturado e vrios outros textos bonitos e acadmicos em sua documentao, o iperf entra como ponto chave (cereja do bolo) concluindo e comprovando tudo, sem possibilidades de dvidas (dica: diretores querem ver grficos, imagens e cores, dificilmente ir ler sua documentao, mas voc comprovar que parte da rede compromete o funcionamento da comunicao, que no final das contas afeta o faturamento). Para quem no de TI, textos (mesmo que simples) so horrveis (por preconceito e preguia, j acham que no vo entender o que est escrito). Com isto, o sucesso de um projeto aprovado so grficos e imagens bem colocadas e o esclarecimento de como afeta no faturamento (infelizmente a maioria entende TI como gastos e despesas, e profissional de redes como um pica-fio). Um terceiro e ltimo bom exemplo, digamos que voc topou fazer uma pequena rede num escritrio, como um bom estudante/profissional de redes, voc fez tudo pelas normas, bonitinho,amento estruturado, um mini-rack de parede, canaletas, keystone,... No final, como as boas empresas de infraestrutura, voc entrega toda a documentao de como fez, por que fez, o que usou, como/onde/por que... Para certificar sua rede, mostrar todo o poder de transmisso e conexo, nada como uns bons logs do iperf, screenshots, e se a pessoa pagar a vista, adiantado e com uns trocados para o cafezinho, voc faz testes ao vivo, em cores, e mostrando ao seu cliente que cada centavo investido valeu ;-). Claro, pensei em 3 situaes bem distintas e fceis de se encontrar por a, mas h vrios outros ambientes onde podemos inserir o iperf com muito sucesso (se voc usou-o com sucesso e retornos positivos, d um feedback)...

O Bsico - Executando como Server

No Windows
Via linha de comando (Iniciar > Executar > digite cmd) entre na pasta onde o Iperf foi salvo (neste exemplo coloquei dentro de uma pasta chamada iperf em Arquivo de programas). Ao acessar a pasta onde est o iperf (use o comando dir para ter certeza, ele vai listar o que h dentro da pasta). Para iniciar o iperf como servidor apenas digite: iperf s.

C:\ Arquivos de programas\Iperf > iperf s

O iperf ser iniciado como servidor e est aguardando conexes dos clientes (lembre-se da porta padro).

No GNU/Linux
Considerando que a porta TCP 5001 esteja habilitada, entre com o comando abaixo em um terminal para o Iperf subir como o servidor: root@server ~ # iperf

Aparecer a seguinte resposta: root@server ~ # iperf -s -----------------------------------------------------------Server listening on TCP port 5001 TCP window size: 85.3 KByte (default) ------------------------------------------------------------

Aps executar o iperf como servidor, mantenha a janela do terminal aberta. Caso queira certificar-se que a porta est aberta e recebendo conexes, digite seguinte comando em outro terminal: root@server ~ # nmap 127.0.0.1 -p 5001 | grep 5001

O nmap ir responder da seguinte forma: root@server ~ # nmap 127.0.0.1 -p 5001 | grep 5001 5001/tcp open commplex-link

Nesta resposta do nmap h a seguinte informao: PORTA(5001/tcp) STATUS(open) e SERVIO (commplex-link) Neste comando que inseri, apenas pedi para que o nmap desse um Ol na minha maquina (127.0.0.1 ou localhost) na porta especificada (-p 5001). O resto foi apenas enfeite, a continuao ( | grep 5001 ) faz com que apenas seja exibido a linha onde contm este nmero (5001). Verifique tambm que aps realizar este comando com o nmap, no terminal onde est rodando o servidor iperf, ele deu uma movimentada: [ 4] local 127.0.0.1 port 5001 connected with 127.0.0.1 port 44382 [ ID] Interval Transfer Bandwidth [ 4] 0.0- 0.0 sec 0.00 Bytes 0.00 bits/sec

O Bsico o Cliente
No Windows
Numa segunda maquina, navegue pelo prompt at a pasta onde est executvel do iperf, digite o comando para execut-lo como cliente:

C:\Program Files\Iperf > iperf c IP.DO.IPERF.SERVER

No Linux
Para executar no Linux, basta digitar o comando, pois o iperf foi instalado no linux (esta a diferena entre a verso do Windows e do Linux, no Windows no h instalao, sendo que voc deve navegar pelo prompt at a pasta onde est o executvel). Neste exemplo iremos considerar que 172.22.254.254 seja o endereo ip de nosso servidor Iperf, e o cliente est sendo executado numa maquina com ip 172.22.0.1, a sada do comando seria algo parecido como:

Neste exemplo acima, foi transferido 114 MBytes em 95,2 Mbits/sec. Na maquina cliente, por linha de comando, digitando iperf c e o IP do Iperf Server. Isto o suficiente para que o Iperf envie trfego TCP do client para o server durante 10 segundo (essa a configurao padro). Aps 10 segundos as informaes so mostradas, como na imagem acima. Neste exemplo, em 10 segundos foram transferidos 114 MBytes, atingindo a velocidade de mdia de 95,2 Mbits/sec (normal em uma rede 100 Mbits). Note que no server tambm so mostradas as estatsticas.

Utilizando UDP
Outra opo adicionar o argumento u nos dois lados (server e client) para que o teste seja efetuado com pacotes UDP. Na inicializao do Servidor: root@server ~ # iperf -s -u

No Windows:

C:\Program Files\Iperf> iperf -s u

Como flag no cliente para informa-lo da utilizao do protocolo UDP: root@client~ # iperf -c 192.168.0.1 -u

No Windows:

C:\Program Files\Iperf> iperf c 10.10.8.75 u

Usando esta opo (UDP), no final da transmisso de pacotes, quando so exibidas as estatsticas no server, aparecem mais trs itens: Jitter, nmero total de pacotes transmitidos e pacotes perdidos.

Nos mesmos 10 segundos utilizados anteriormente, tivemos 0,018 milissegundos de jitter e nenhum pacote perdido, de 893 transmitidos. Observe que a transferncia de dados foi menor, porque a taxa de transferncia padro UDP no Iperf de 1 Mbps. Se voc quiser aumentar a banda utilize a opo b do lado cliente: root@client~ # iperf c 10.10.8.75 b 70M No exemplo acima ser tranferido 70 Mbits/sec. Este opo funciona para o modo UDP apenas.

Argumentando... Mais Opes

Alm das opes j citadas, o Iperf ainda oferece outros argumentos, que podem ser utilizados de acordo com sua necessidade. As flags so inseridas como a maioria dos aplicativos em modo texto para GNU/Linux, seguindo a linha: Para iniciar como servidor utilizando por padro o protocolo TCP:

iperf -s [ opes ]

Para iniciar o cliente, indica-se o ip do servidor:

iperf -c ip.do.iperf.server [ opes ]

Para iniciar como servidor utilizando UDP:

iperf -s -u [ opes ]

Para iniciar o cliente, alm ip do servidor, qdeve usar a flag indicando o uso de UDP:

iperf -c -u ip.do.iperf.server [ opes ]

Se o servidor foi iniciado apenas com o padro (-s), ou seja, usando o TCP, o cliente obrigatoriamente vai ser executado tambm como TCP. Caso o servido foi iniciado usando a flag -u (para UDP), o cliente dever usar -u em todos os testes. No possvel iniciar o servidor como UDP e rodar testes no cliente como TCP ou vice-versa.

Opes gerais
As opes gerais so flags que podem ser utilizadas tanto no servidor quanto no cliente.

-f, --format
o formato com que ser exibido as informaes, como Kbits, Mbits, Gbits, KBytes, Mbytes, Gbytes,... No exemplo abaixo, executei o cliente com -f Mbytes (caso queira, --format MBytes), ele ir me reportar as informaes em Mbytes. As informaes que estaro sendo mostradas no servidor, continuam com o formato padro (exibindo taxas de transferncias em Mbits).

-i, --interval n
Por padro, o iperf (tanto cliente como o servidor) iro realizar os testes durante 10 segundos e depois exibir o resultado para voc. A flag -i N ir fazer com que o iperf exiba o status do teste a cada N intervalo de tempo que voc definir. No meu exemplo, indiquei 1 segundo (-i 1), ou seja, a cada 1 segundo durante o teste, o iperf mostrar o status das transmisses.

-l, --len N
Com a flag -l voc define (em B, KB ou MB) o tamanho do buffer, no exemplo abaixo (o servidor estava sendo executado como UDP, flag -u), inseri o nmero 9999, como no coloquei nenhuma letra indicativa aps (B, KB ou MB), ele defin e como sendo Bytes.

-m, --print_mss
Exibe o tamanho mximo do segmento (MTU - TCP/IP header).

-o, --output <arquivo>

Redireciona as mensagens e logs do iperf (que por padro so exibidos ao concluir os testes) pra um arquivo, basta indicar o nome do mesmo.

-p, --port n
Indica a porta a ser utilizada. Por padro o iperf usa a 5001. Usando iperf -s -p 8080 o servidor ficar escutando conexes na porta 8080, e nos clientes voc dever usar a flag para indicar a porta em que o cliente enviar os pacotes (exemplo, iperf -c x.x.x.x -p 8080).

-u, --udp
Utiliza o protocolo UDP, ao invs do padro TCP. Caso v utiliz-lo, todos os iperfs (o servidor e os clientes) devem usar esta flag.

-x, --reportexclude
A flag -x seguida de uma ou mais das letras: C D M S V Faz com que o iperf omita alguma informao. A letra C omitir informao de conexo, D dados, M multicast, S de configuraes/opes, V de informaes do servidor. No exemplo abaixo, utilizei -x CMSV, ou seja, o iperf s me mostrou informaes relativas aos dados (o quanto foi transmido, em qual taxa de velocidade). Esta uma excelente flag, pois com ela voc extrai exatamente a informao necessria, excluindo de seu relatrio final dados que no sero teis.

-y, --reportstyle C
Com a flag -y, o iperf exibir as informaes no formato CVS (separados por virgula).

-w, --window n
Com TCP opo voc determina o tamanho do socket buffer (ou TCP window size).

-B, --bind <host>

bind to <host>, an interface or multicast address

-M, --mss n
Configura o tamanho mximo de cada segmento de pacote TCP (MTU - 40 bytes)

-N, --nodelay
Desabilita o delay para transmisses TCP

-V, --IPv6Version
Configurao para uso do IPv6.

Opes para o cliente

As opes a seguir so de exclusividade da maquina em que estar rodando o cliente do iperf.

-P , --parallel
Simula a carga de transmisso de um nmero N de clientes em paralelo. No exemplo abaixo, indiquei o nmero 7, ou seja, o iperf enviar conexes como se fossem 7 maquinas com iperfs clientes enviando transmisses ao mesmo servidor.

-T, --ttl
O famoso time-to-live, neste caso para multicast ( o valor default 1)

-n, --num
Nmero de byte para transmisso (inseri um nmero de em seguida as letras do formato, por exemplo -n 35 KB).

-t, --time
Tempo de transmisso dos testes (o valor default 10 segundos). No exemplo abaixo, inseri o -t 15 para fazer testes por 15 segundos, juntamente com a flag -i 1 para que o iperf exiba um status a cada 1 segundo (ao invs de apenas ficar esperando, como o padro), tambm inseri o argumento para exibir os dados em Mbytes, por final, o u, pois na ocasio estava rodando o servidor como udp. No final fica a seguinte linha de comando: iperf -c x.x.x.x -i 1 -t 15 -f Mbytes -u

-d, --dualtest
Apesar do Iperf enviar trfego no sentido Client > Server por padro, podemos configur-lo para que o teste seja executado nos dois sentidos simultaneamente. Para isto, execute o Iperf Server da mesma forma (iperf s) e do lado cliente, apenas adicione o argumento d. root@client ~ # iperf -c 192.168.0.1 -d Verifique no exemplo abaixo que o iperf exibe as duas saidas:

Observe que desta vez temos duas linhas, sendo que em um sentido a transferncia atingiu 94,2 Mbits/s e no outro 35,7 Mbits/s. Se somarmos as duas temos 129,9 Mbits/s (abaixo dos 200 Mbits/s nominal de uma rede full duplex).

-r, --tradeoff
Realiza o teste nos dois sentidos, servidor cliente, semelhante ao argumento anterior (-d), porm neste os testes nos so feitos simultneos, mas individualmente.

-L, --listenport
Indica a porta que ser utilizada para receber os testes bidirecionais descritos acima (-d e -r)

-b, --bandwidth
#[KM] for UDP, bandwidth to send at in bits/sec (default 1 Mbit/sec, implies -u) -b Especifica a banda a ser utilizada (bandwith)

-F, --fileinput <name>

Inseri algum arquivo para ser transmitido como forma de dados.

-I, --stdin
Inseri um arquivo para transmitir como entrada padro (stdin)

Opes para o Servidor

Alm das Opes Gerais, que podem ser utilizadas tanto no servidor quanto no cliente, o servidor possui algumas (na verdade, apenas 2)opes exclusivas:

-s, --server
Iniciar o iperf como servidor (nem conto isto como uma opo...)

-U, --single_udp
Inicia como UDP (ao invs de TCP para as transmisses como padro)

-D, --daemon
Inicia o servidor como um daemon.

Interface Grfica em JAVA

Junto com o iperf, est disponibilizado para download o pacote jperf, justamente uma interface grfica em Java. Realizando o download do pacote e descompactado-o, haver o jperf.bat (para execut-lo em Windows) e o pacote jperf.sh para executar em Linux. Este arquivo sh apenas o comando para executar o jperf.jar com os parmetros e flags necessrias para a maquina virtual java iniciar a aplicao (comigo funcionou perfeitamente tanto no SunJava Runtime quanto no OpenJDK, mas prefiro o OpenJDK..). Na imagem abaixo est a tela inicial quando executamos o jperf.

Logo de inicio, o jperf mostra o campo iperf command, informando qual o comando em modo texto que ser executado ao voc escolher as opes no modo grfico.

Logo abaixo, o modo em que o iperf ser executado: Servidor ou Cliente. Veja que habilitando uma das opes, ficar disponvel configuraes que vemos anteriormente como flags. Por exemplo Parallel Streams(opo -P em linha de comando). Note que alterando as opes, automaticamente a caixa command exibe como fica as opes que voc escolheu em modo linha de comando.

Ao lado esquerdo da janela, h as opes de configurao relativas as configuraes de transmisso, pacotes, envio, entre outras. Esto divididas em 3 blocos:

Lembrando, tudo que h nos 3 blocos do lado esquerdo so as flags que apresentei anteriormente em modo de linha de comando (bloco da camada de transporte, aplicao e IP), basta prestar ateno ao nome dos botes que voc perceber o que cada boto da interface grfica faz, como por exemplo: No bloco Transport Layer h os botes para ativar TCP ou UDP, ao ativ-los, abaixo habilitado as configuraes de tamanho de buffer, pacotes, formato (em kbytes, mbytes,...) e caixa para inserir os valores. No bloco Application Layer, h opo para o formato de sada das informaes, intervalo para reportar o status dos testes, modo de teste (dual simultneo ou individual)... No lado direito, h a exibio dos relatrios/logs/resultados dos testes... Estes so mostrados em duas formas: Em log, exatamente igual ao mostrado em linha de comando. Mas em grficos, que o ponto mais interessante desta interface ;-)

Abaixo da rea preta (exibio do grfico), temos o campo output onde ser mostrado a sada que temos ao usar o iperf em modo de linha de comando, alm da opo de salvar os resultados.

Lembrete: tanto os blocos a esquerda quanto a reas do grfico e do log so redimensionveis (no caso dos blocos, voc oculta-os), permitindo assim que voc tenha maior foco ao que deseja extrair do iperf e de seus testes. (veja exemplos e explicaes abaixo): Abaixo temos duas imagens, a primeira trata-se do Jperf sendo executado como servidor, na segunda est o cliente. No cliente (veja o campo onde mostra o comando) foi configurado para usar a opo Parallel Stream -P que envia um nmero X de conexes simultaneas, no nosso caso, 10 conexes. Veja que tanto no cliente quanto no servidor, cada conexo possui uma cor diferente, que diferencia o comportamento de cada linha no grfico da primeira imagem (servidor) onde mostrado a relao de cada conexo (cada cor) com tamanho/velocidade/tempo/largura de banda/atraso. Obs.: Ambos esto sendo rodados em Debian, usando o OpenJDK (num deles, tive problemas ao usar o Java Sun), curiosidade: Na vspera de natal as 00hrs e 12Min ;-)

Concluso
Este pequeno tutorial/Manual e How-to desenvolvi atravs de 1 ms (Dezembro/2011 a Janeiro/2012) pesquisando e testando o software iperf e sua interface grfica. A principal fonte de informaes (como qualquer programa no Linux) foi sua Man-page e o seu site oficial (como qualquer outra coisa, procure sempre quem fez, depois procure quem usa, rsrsss). Obviamente tive como referencia tambm vrios outros sites, a maioria em Ingls, pois h falta de material do Iperf/Jperf em portugus (isto tambm foi uma das coisas que me motivaram a desenvolver este material).

Tive 4 ambientes de rede para testar o iperf:

No primeiro, uma simples rede virtualizada para ter conscincia do software em questo. A maquina virtual e a hospedeira eram Linux. Num segundo ambiente de testes,usei duas maquinas fsicas (um pc e um notebook), ambos com placa de rede em Mbits, mas ligados entre s por um cabo crossover (mal crimpado) ligado em um utp (ambos cat5e) atravs de uma emenda (dessas de plstico sem-vergonha vendidas em lojas como se fosse emenda profissional). No terceiro ambiente, mostrei o iperf a um colega/profissional (PEIP Informtica) e testamos o jperf numa rede cabeada (megabit) com 100% das maquinas Windows. Por final, realizei alguns testes em minha pequena rede que tenho em casa, onde todos os equipamentos funcionam em gigabit (switch e interface das maquinas) com pach-cords cat.6 (certificados, de uma respeitada marca do ramo de network). As screenshots neste manual referem-se a todos esses testes realizados, no testei-o em wirelless, mas seria interessante mostrar a diferena entre cabeado e sem fio numa mesma rede (pois wirelless possui uma boa incidncia de perda de pacotes e problemas com a velocidade real/nominal devido a interferncias,...).

Minha rede est lenta, e agora??

Existe pontos na qual deve-se tomar muito cuidado ao formalizar concluses pelos logs e resultados do iperf: Sistema Operacional: O sistema em que est executando o iperf pode conter problemas com rede, como vrus ou conflitos de programas instalados ou atualizaes, demorar para processar pacotes, firewall/antivrus ativados com sistemas de deteco instalados,... Rede: Sua rede pode conter switches gerenciveis que bloqueiam determinados pacotes/protocolos ou conexes, analisadores e IDS's que podem aumentar o tempo de transmisso, controle de banda, VLAN, etc... (recomendo que conhea bem a rede antes de usar o iperf, algo nela pode afetar os resultados do iperf). Ento, antes de pensar em sua rede, faa o teste em vrios hosts diferentes, no s hardware diferente, mas Sistema operacional tambm. Testou em vrios hosts, verificou as informaes acima e continua lento??? A partir daqui inicia-se um trabalho mais profundo onde voc ir utilizar sniffers, portscan e outras ferramentas mais avanadas no Linux para identificar os motivos de sua rede estar lenta. Para isso, DICA: comece sua investigao seguindo a tabela OSI (checando os itens em sua rede e em seus hosts a partir da camada 1 da tabela OSI at chagar na 7). Geralmente lentido em rede causada por cabos mal crimpados, plugs rj45 com aquela travinha quebrada, placas de rede defeituosa, cabos UTP danificados ou velhos (tanto os pach-cords quanto os usandos em backbone,

manobra em switch ou pach panel), redes feitas por eletricistas ou amiguinhos pseudo-tecnicos que cobram barato (sem seguir regras e normas bsicas de rede, como a curvatura do cabo, distncia de geradores de interferncias, entre muitas outras...), produtos de m qualidade, cascateamento ou loopback de switch, etc...

Aps verificar tudo isto, v subindo na camada OSI, outras coisas que so comuns achar por a, servidores emitindo muito broadcast, servios que geram pacotes excessivos e desnecessrios na rede, servidores e switchs mal configurados, etc... Esta etapa, foge dos poderes do iperf, da vai de seus conhecimentos, estudo do que est funcionando na rede e suas particularidades, utilizao de sniffers e portscans, entre muitos outros aspectos. Veremos isto num futuro tutorial, correto? Vamos ver....

Download e Links:
Site Oficial: http://iperf.sourceforge.net/ Projeto do Iperf 3.0 (atualmente beta na verso 4) http://code.google.com/p/iperf/ Os programas semelhantes mencionados no inicio do tutorial: TTCP: http://www.pcausa.com/Utilities/pcattcp.htm BWPing: http://bwping.sourceforge.net/
Consideraes

Alm da rede, o poder de processamento das mquinas utilizadas e a utilizao da CPU e Memria das mesmas tambm influenciam no resultado; Cuidado ao gerar trfego em uma rede em produo; Para voc ter parmetros de comparao, aconselhvel fazer um teste ponto a ponto, com dois computadores conectados atravs de cabo crossover. Depois testar usando a rede; Quando usando UDP voc pode especificar a banda mxima possvel, 1000M, por exemplo. Faa o teste e verifique se hoje perda de pacote. Se houver, repita o teste diminuindo a banda para 900M e verifique novamente. Repita o processo at chegar a um ponto em que no haja perda de pacote;

Lembre-se que o resultado mostra o resultado obtido naquele momento. Um segundo depois, em um novo teste, o resultado pode ser outro;

At a prxima.

Using jperf to check network performance

By Scott Reeves February 21, 2012, 9:19 AM PST

Takeaway: Scott Reeves explains how to use the GUI version of iperf for network monitoring and testing. In my last post, I talked about using iperf to look at network performance. This post looks at using a close relation of iperf called jperf. Jperf is actually a GUI front end to the iperf application. (Jperf is downloadable from the sourceforge site.)

Installing jperf is very simple; simply download and unzip it to the directory you want to run it from. It has a jperf.bat file and a jperf.sh file; as I run jperf on a Linux host, I use the jperf.sh file. Running the jperf.sh file produces the GUI as shown in Figure A (click to enlarge images).

Jperf can be run as a server or as a client. One of the handy aspects of using jperf is that to run it, you click a button called run iperf. Jperf will then display the iperf command it is running in the background. There are sections for application layer options and transport layer options. This post looks at the transport layer options. As Figure A shows, there are a number of TCP parameters that can be modified. A few explanatory notes are in order to explain these parameters. The Mean Segment Size (MSS) gives the option to change the amount of data in each frame. In terms of transmission, it is less than the MTU of the card. The Window size denotes how many packets can be sent before an acknowledgement is required. The Buffer length is the amount of traffic that can be queued for transmission. These three parameters can all be adjusted, depending on what you want to test. Figure B is the result of a run using the default TCP parameters.

There is a setting I have used for this run called Num Connections. This allows you to define how many connections are allowed to the server; here it is set to five. For this run, four actual connections were made. As can be seen, jperf draws and updates the graph as each transmission is received. The output window below the graph provides the numbers used to draw the graph. This output can be saved if you want to use some other graphing program such as Libre Office Calc. The second run was done using UDP, using the default parameters. The results are as shown inFigure C.

Again, the number of connections allowed is five. Here the output for bandwidth and jitter are shown. As can be seen in both the graphs, four connections were made to the server. The average throughput is somewhat higher for UDP than for TCP. This is because UDP does not acknowledge whether a frame is received or not. Hence, UDP will send out the frames as fast as it receives them. The second graph shows the jitter, again for all four users. In this case the highest value for the jitter is around 2.5 ms, which is acceptable for most UDP applications. As for TCP, you can save the output as a text file.

Jperf provides a handy GUI option for iperf. A nice feature is being able to re-use the iperf command line strings if you want to so some scripting for the purpose of monitoring, data gathering or testing.

Use jperf and Wireshark for troubleshooting network issues

By Scott Reeves September 5, 2012, 6:00 AM PDT

Takeaway: Scott Reeves explains how to use jperf to simulate a TCP or UDP connection and then use Wireshark to analyze the traffic in order to help pinpoint network issues. In a previous post on jperf, I wrote about using jperf to check network performance. In a later post, I mentioned using filters on Wireshark to analyze traffic. Combining jperf with Wireshark gives you (respectively) a tool to simulate network traffic and a tool to probe and capture what is taking place on the network whilst the simulation is running. This post gives a short example on how to use both tools. First a brief recap: jperf needs two computers: one to act as the server and one as the client. The server end can be setup as per Figure A.

Figure A

Click on images to enlarge.

You can change the parameters once youve had a few run-throughs, but for the purpose of this example, well leave them as they are. In this case we want to check on TCP throughput. This simulates perhaps an ftp connection, or an http page load. On the client laptop (which, in this case, was a Linux netbook) jperf ran for 10 seconds (the default). A Wireshark capture session was also started just prior to the jperf transmission. Figure B shows the jperf screen from the client side. In this case, the server IP address was192.168.250.2. Figure C shows the actual capture.

Figure B

Figure C

Note the TCP three-way handshake starts in line 29 of this capture. The relevant parts of the three-way handshake have been circled. After the connection is established, the data starts to flow from line 35. In this case, 1514 byte frames are being used. We can also see the source and the destination IP. Note that this connection is simulating a TCP connection, rather than a UDP connection. A nice feature of Wireshark is that you can highlight a frame going to the server, then click on the Statistics menu, go down to TCP stream graph , and then throughput. This is shown in Figure D. Figure D

This will produce a graph of the throughput, as shown in Figure E.

Figure E

The drawback is that you cannot save this graph, other than by taking a screenshot. However, there is another option. You can go into the Statistics menu and select IO Graph. See also Figure F. Figure F

For this example we are only interested in TCP packets. We therefore apply a filter so that only TCP packets are graphed. The graph and the filter are shown in Figure G. This graph shows the number of TCP packets sent every 0.1 seconds.

Figure G

We can use this to provide an estimate of throughput. In this case, we can see that the throughput is relatively constant over the period of transmission. One word of warning: Wireshark was designed more with network troubleshooting in mind, so the graphing functions are designed more to assist in pinpointing a problem than in providing graphs for general use. This post has looked briefly at a combination of jperf and Wireshark. Jperf can be used to simulate a TCP connection (such as ftp) or a UDP connection (such as VoIP). Wireshark can be used to check on the frames that are being sent over the network by the simulation.

Measuring Network Performance - Jperf

Jperf, Iperf
WED, 23 APR 2008 09:00 DOUG REID

Free and openly available, Iperf is a command line tool useful for measuring network performance. In mylast post, I introduced some basic command line instructions to run Iperf between two endpoints and showed how the tool can be used to generate and measure both TCP and UDP performance. This time, I'll discuss Iperf's graphical cousin: Jperf. Jperf, as shown below, is a free Java-based GUI tool that performs all the functions as Iperf, available for download here. For those who prefer graphical output and point and click functionality, Jperf is certainly welcome! Installation is a breeze, it is simply a matter of downloading the file and decompressing it. Additionally, make sure you've installed Java and edit your firewall settings, as discussed previously.

Figure 1: Jperf screenshot

Using Jperf between two endpoints is as simple as choosing Server mode on one endpoint and Client mode on the other. You'll enter the URL or IP of the Server on the endpoint in Client mode. Finally, you'll click the Run Iperf! button which I've circled in diagram above on the Server and on the Client to perform a test. Jperf is just a frontend to Iperf, so it performs the same tests and is interoperable with Iperf. You can even run Jperf as one end point and Iperf on the other. Notice that clicking various options in the graphical Jperf produces the Iperf command line sequence on the top of the display, also circled in the diagram above. TCP is the commonly-used Layer 4 protocol for network applications like HTTP, FTP and SMTP. TCP manages an application's network performance by controlling how much data is sent in each packet (MSS), how many packets are sent before receiving an acknowledgment (Window Size) and how much memory is allocated to send and receive traffic flow buffers (Buffer Length). TCP is like a shipping company defining how much weight can be loaded in each box, how many boxes go on each truck and how many boxes can sit in the loading docks at either end. There are numerous other capabilities and features to Iperf/Jperf. For example, we can adjust the values in Jperf for Buffer Length, Window Size and MSS and see the impact the changes have on throughput. Adjusting these values is as simple as selecting the parameter in the GUI, and using the up/down arrows to adjust the values as I've circled below.

Figure 2: Jperf TCP Settings

As stated on the Iperf website, "the most fundamental tuning issue for TCP is TCP Window Size, which controls how much data can be in the network at any one point." A reader commented on my last blog (Thanks!) that changing the TCP Window Size from

the default value of 8KByte to 64KByte over a Gigabit LAN showed nearly a 3x increase in throughput. Interestingly, throughput gains with higher Window Sizes can be seen even over remote network connections. On a recent business trip, I used Jperf to experiment with various TCP Window Size settings from a hotel network to my home LAN, producing Table 1 below. I adjusted the Window Size on my laptop using values of 1, 4, 8(=default), 16, 32, 56 and 64KBytes, and ran each test 3 times. All throughput results below are in Kbps.

Table 1: Jperf Remote Throughput test results

As you can see, I had varying, but lower throughput using Window Sizes from 1-8 KBytes, ranging from 696-751 Kbps. However, increasing the Window Size to 16, 32, 56 and 64KBytes produced increasing throughput, peaking at 2168 Kbps with a Window Size of 64 KBytes. There are situations where reducing Window Size may also improve TCP throughput. Since TCP is a reliable protocol, it will retransmit lost data. On a slower network with more retransmissions due to packet loss, throughput may improve by sending smaller amounts of data between acknowledgments, which will minimize retransmissions. In addition to adjusting Window Size, MSS and Buffer Length values can also be adjusted, and their effects on TCP throughput can be observed. I'll leave details on these options to a future blog. However, I do want to touch on the issue of units of measurement and how to normalize data between those units. Storage and throughput are measured differently. Storage and file sizes are measured in bytes (1 byte = 8 bits) and commonly use binary units, with K indicating 1,024 (=2^10), M indicating 1,048,576 (=2^20), and G indicating 1,073,741,824 (=2^30). Network throughput is measured in bits and commonly use metric units, or what is known as an SI unit (SI is French for International System of Units), with K indicating 1,000 (=10^3), M indicating 1,000,000 (=10^6), and G indicating 1,000,000,000 (=10^9). So let's say you're trying to optimize your network for file transfer capability, and want to estimate how long file transfers will take per Gigabyte of data. Using Jperf, you can measure your expected throughput in kilobits per second. Let's say your expected throughput is 2168 kilobits per second as measured in the above table using 64K Window Sizes. First, convert Gigabytes to bits. 1 Gigabyte is 2^30 bytes, and each byte is 8 bits, so 2^30*8 coverts Gigabytes to bits. Then, divide by the throughput rate in bits to get the total seconds it will take to transfer each Gigabyte. The math looks like this: ((2^30)*8)/(1/2168000)= 3962 seconds, or over 66 minutes per Gigabyte! If "doing the math" isn't your deal, then Jperf's throughput measurements can be adjusted from bits to bytes per second by selecting the desired unit in a drop-down list as shown in Figure 3. For example, measuring network performance in kilobytes per second would eliminate converting bytes to bits and simplify the above equation.

Figure 3: Adjusting Jperf output format

The gist of this post was to demonstrate the use of Jperf to measure network performance. Measuring network performance isn't all that difficult, as I've shown with both Iperf and Jperf. As I've stated in various product reviews, it is useful to have objective measurements to evaluate or benchmark a network. If you're considering adding a new router or switch to your network, do before and after tests to objectively determine the impact the new device has on your LAN. If you don't see improvement, you might want to check your configurations and consider the value of the device you just installed. If you do see improvement, Jperf test results can provide numerical evidence of the positive impact you just had on your LAN! In the last post of this series, I'll look at how tweaking other iperf/jperf parameters can affect performance.

Measuring Network Performance - Jperf and TCP, Part 2

Jperf, Iperf
WED, 30 APR 2008 07:00 DOUG REID

Having introduced Iperf and Jperf, as well as covering details on TCP throughput tests by adjusting Window Size values, it's time to complete this series with comments on adjusting MSS and Buffer Length values. I'm also going to touch on using the results of Jperf testing to make changes to a PC to improve network performance.

Buffer Length
Buffers are memory allocated to network interfaces to store and queue packets prior to being transmitted or as they're received. Adjusting Buffer Length can have an impact on TCP throughput as it affects network utilization. A Buffer Length that is too small may result in underutilization of the network due to the system waiting for packets to transmit, while too large of a Buffer Length can add network delay as the buffers are filled and emptied. I ran Jperf TCP throughput tests with various Buffer Lengths remotely over a WAN connection (Table 1), as well as over my LAN (Table 2). I adjusted the Buffer Length on my laptop using values of 4, 8(=default), 16, 32, 64, 128, 512KBytes, and ran each test 3 times and calculated an average value. All throughput results below are in Kbits/sec. Buffer Length (Bytes) - WAN Testing Trial 1 4K 1184 8K 1241 16K 2674 32K 2302 64K 2721 128K 2813 512K 2719

2 3 AVG

1274 1275 1244

1501 1520 1420

2651 2438 2587

2802 2821 2641

2808 2803 2777

2817 2713 2781

2722 2734 2725

Table 1: Buffer Length Test - WAN

Buffer Length (Bytes) - LAN Testing Trial 1 2 3 AVG 4K 136514 130702 140195 135804 8K 176469 170338 175848 174218 16K 217341 209606 222288 216412 32K 275592 277556 278472 277207 64K 276823 274919 277922 276555 128K 278079 279231 275462 277591 512K 279335 278498 278917 278917

Table 2: Buffer Length Test - LAN

As you can see, throughput improves both over a WAN connection and over my LAN as Buffer Lengths increase above the default value of 8KB, reaching peak performance at 32-64K. However, Buffer Lengths above 64k didn't seem to produce any significant gains.

MSS
MSS, or maximum segment size, defines how much data is sent in each packet. In my discussion a couple months back on Jumbo Frames, I noted "the payload at Layer 4 is the MSS, or maximum segment size, and is typically 1460 bytes. Add the TCP/IP header of 40 bytes and we have the Layer 3MTU, or maximum transmission unit of 1500 bytes". As I concluded in my Jumbo Frame discussion, increasing payload size can have positive impact over Gigabit or faster networks, assuming all endpoints, routers, and switch(es) in the transmission path are Jumbo Frame enabled. Note that even though your NIC may run at Gigabit speed, it may not support Jumbo Frames. For example, both my laptop and desktop PCs have Gigabit NICs, yet my laptop's Gigabit NIC doesn't have options for larger frame sizes. Below, you can see the Control Panel Network Interface configurations available for my laptop (left) and desktop (right). Further, you can see the Jumbo Frame option (circled) on the right doesn't exist on my laptop. Without Jumbo Frame capability, my Gigabit capable laptop is limited to an MSS of 1460 bytes.

Jumbo NIC controls

With only 1 endpoint that supports Jumbo Frames, running Jperf tests with larger MSS sizes won't work on my network, as the frames sent in the tests would be fragmented to the smallest max supported frame size of my endpoints, which is 1460. If you're running multiple PCs on a LAN that support Jumbo Frames and the switch between them supports Jumbo Frames, enable Jumbo Frame support on all three and try increasing the MSS size in Jperf up to 9k to see the impact on throughput. As demonstrated in my previous post, running Jperf tests with different values is as simple as point and click to change a test value. We'd love to see your results, please feel free to post them to this blog.

Windows Registry
With the results from Jperf testing providing optimal parameters for TCP throughput, it is possible to intelligently modify configurations on the actual devices, such as the PCs and Servers that are sending and receiving TCP data flows. Most PC and Server Operating Systems automatically manage TCP and UDP parameters. Still, adjusting these parameter can improve performance. For a Windows XP PC, adjusting TCP transmission parameters is done via the Windows Registry. Note, working with the Registry is a potentially dangerous activity! Making a mistake in the Registry can crash a PC! With that said, if you take a few precautions, such as back up the Registry, and work step by step, editing the Registry isn't difficult. Microsoft has a nice guide for backing up and restoring both an XP and Vista Registry, located here. It's always a good practice to backup files before changing them, so making a Registry backup is certainly advisable. I also recommend printing Microsoft's restore process, that way you've got hard copy in the event of a problem. Finally, I recommend creating a Windows restore point before you edit the Registry, giving you a current good fall-back point. Accessing the Registry is by clicking Start-Run and typing regedit, or from the command line by typingregedit. TCP/IP settings are in the directory listed asHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters. Below is a screen shot of my registry directory. As you can see, the TCP Window Size is an adjustable parameter.

Windows Registry TCP/IP Parameters

Making changes to a registry value is done via this Registry Editor tool. To make Registry changes, change the value, in hexadecimal, to the desired new value. Due to the risks associated with changing the registry, I strongly recommend you refer to a guide such as Microsoft's guide for changing TCP registry values on an XP PC here. Using this guide, though, we see the values entered for TCP Window Size are hexadecimal values. Thus, to increase the TCP Window Size on my XP PC to 64K, I would change the registry value to 0xffff, which is the hexadecimal equivalent of 64k. The bottom line here is it is possible to improve network throughput through the use of free software and adjusting existing values on network devices. Jperf is a powerful, yet openly available network measurement tool to help identify optimal values for networked PCs and Servers. These optimal values can then be applied to a network computer via the Control Panel or Registry, resulting in better network performance, for free!