15/10/2017 Blog LabCisco: Interpretação dos Resultados do Ping

Blog do Prof Sam uel Henrique Bucke Brito | Redes de Com putadores e Telecom unicações

Início Downloads & Laboratórios Videoaulas Autor UNIMEP

Mem bros no Facebook

C h eg o u o n o vo u p ! O novo up! é feito de novas ideias para um
F eit o d e n o vas id eias. novo você.
Blog Lab Cisco
CLIQUE E CONHEÇA Passe
Volkswagen o Mouse

Pesquisar no Blog

sábado, 4 de m aio de 2013

Interpretação dos Resultados do Ping

Olá Pessoal.

Esse é mais um artigo que escrevo atendendo a pedido dos leitores do blog. Existem várias
ferramentas de monitoramento de redes no mercado, sendo que todas elas, de alguma forma,
retornam algumas métricas importantes de desempenho em redes, tais como: vazão em bps,
latência (atraso), jitter (variação da latência no tempo), etc. A mais comum de todas essas Sua Conexão
ferramentas e que certamente faz parte da vida cotidiana de TODO profissional de redes é o "bom e
velho" ping - presente em praticamente todas as caixas e sistemas operacionais! Esse blog é acessível
via IPv6. Se o globo
Apesar de parecer simples, o ping vai MUITO além de simplesmente confirmar se há comunicação estiver girando, então
com um host remoto qualquer - ele também traz alguns valores importantes para determinar o você também possui
conexão IPv6.
desempenho de uma rede. Para cada linha de resposta echo-reply do ICMP (protocolo utilizado por
trás do ping) ele traz o valor do atraso fim-a-fim na comunicação (latência), conforme pode ser
observado no primeiro destaque em vermelho da figura abaixo.

Também ao final da sequência de respostas ele traz um resumo estatístico com os valores mais
baixo, médio e alto da latência nos parâmetros rtt min/avg/max. Ele ainda mostra qual foi a
porcentagem de perda de pacotes que, normalmente, não deve exceder 2%. Valores de perda de
pacotes acima de 5% são indicativos de que está havendo algum problema na rede, que pode ser
desde o cabeamento até a aplicação em si! É importante destacar que no Linux ele calcula o jitter
(parâmetro denominado mdev no ping). Essas informações podem ser observadas no segundo
destaque em vermelho da figura abaixo.

Com prar o Livro de Cisco

Com prar o Livro de IPv6

Não existe um valor único de latência que seja referência para todas as redes, por isso estarei
mostrando alguns valores referenciais aceitáveis para algumas das tecnologias mais comuns que
são: (1) Rede Local, (2) Internet via TV a Cabo, (3) xDSL, (4) Dial-Up e (5) Links de Longa Distância
Privativo.

http://labcisco.blogspot.com.br/2013/05/interpretacao-dos-resultados-do-ping.html 1/7
15/10/2017 Blog LabCisco: Interpretação dos Resultados do Ping
1) Em redes locais cabeadas a comunicação deve ter excelente desempenho, haja vista a
proximidade entre os dispositivos e a boa qualidade da infraestrutura de cabeamento de propriedade
da empresa. É esperado que a latência em redes locais não ultrapasse 10ms (recomendado) ou é
tolerável até 30ms (não recomendado). Quanto mais dispositivos intermediários existirem entre duas
máquinas, naturalmente maior será essa latência porque cada dispositivo intermediário terá algum
mecanismos de tratamento dos quadros;

2) Um valor ideal de latência para links de Internet via Cable Modem seria algo entre 30ms e 50ms.
No entanto a arquitetura da rede é compartilhada através de barramentos nas vizinhanças e a rede
tende a sofrer mais com instabilidade em momentos de muito acesso, o que pode implicar em Com prar o Livro de Linux
latências maiores que 100ms;

3) A latência ideal para a tecnologia xDSL seria algo em torno de 70ms. O que acontece é que essa
tecnologia é muito popular porque aproveita a infraestrutura de cabeamento da rede telefônica,
motivo pelo qual muitas operadoras acabam vendendo mais conexões do que suas centrais
suportam. Essa situação pode implicar em latências de 100ms ou mais, o que é comum de
acontecer no Brasil;

4) A conexão discada naturalmente é aquela que apresenta pior desempenho porque utiliza a rede
pública de telefonia comutada (PSTN) através da modulação do sinal digital do computador em sinal
analógico (audio), ou seja, simplificando, conversão dos dados em som. Por isso a latência dessa Atualizações no E-Mail
tecnologia pode facilmente ser bem superior a 250ms;
Email address... Submit
5) Os links de longa distância privativos mais profissionais, ou seja, aqueles normalmente utilizados
pelas empresas devem apresentar excelente desempenho. Normalmente os contratos desses links
têm cláusulas de SLA em que a operadora se compromete a entregar uma qualidade mínima com Arquivo de Postagens
base em parêmetos pré-definidos. Normalmente esses links também não devem exceder 10ms
► 2017 (12)
(recomendado), mas pode ser tolerável latência de até 20ms ou 30ms (dependendo do contrato);
► 2016 (31)

Lembrem-se de que essas informações são referenciais, ou seja, nenhum desses valores deve ser ► 2015 (33)
aceito como REGRA! Há outros fatores que vão interferir diretamente na latência, principalmente ► 2014 (61)
quando pensamos em links de longa distância. Por exemplo, em situação ideal o sinal percorre um ▼ 2013 (81)
cabo metálico a aproximados 200.000 km/s (quase 2/3 da velocidade da luz). Isso quer dizer que ► Dezembro (5)
você terá resultados diferentes na sua empresa se pingar um servidor localizado no Brasil e outro na
► Novembro (3)
China! ;-) Por isso antes de verificar o desempenho da rede é necessário estabelecer os critérios
► Outubro (4)
que serão utilizados para fazê-lo, criando uma metodologia homogênea que não interfira nos
resultados! ► Setembro (6)

► Agosto (7)
Outro detalhe importante é que vejo as pessoas testando a velocidade da conexão de Internet em ► Julho (8)
casa e sempre muito preocupadas com a tal largura de banda ou taxa de transmissão (em bps), no
► Junho (5)
entanto tão importante quanto a largura de banda é a latência. Por exemplo, vamos pensar na
▼ Maio (7)
seguinte situação:
Lançamento do Cisco Packet
Tracer 6.0.1
Cenário 1: Ana contratou uma Internet xDSL de 25M
- Teste de Desempenho: Taxa de Transmissão de 19M; Latência de 190ms; Autoconfiguração de Endereços
IPv6 (SLAAC)

Cenário 2: Beto contratou Internet Cable de 10M Servidores DHCPv6 em Redes

IPv6
- Teste de Desempenho: Taxa de Transmissão de 8M; Latência de 60ms;
IPv6 no Café da Manhã
Na sua opinião qual dos dois cenários é melhor? Mensagem ao Leitor do Blog -
Resultado de Sorteio
A resposta correta é: Cenário 2
Interpretação dos Resultados do
Ping
Acontece que mesmo a Ana tendo mais largura de banda para acessar mais informação, o estado
do link está MUITO pior do que o do Beto que possui menos da metade da largura de banda. No Palestra Sobre o "Big Data" na
UNIMEP
entanto, o retorno das requisições de Beto será muito mais rápido do que da Ana. É isso que
explica porque um link de 2M na empresa em que você trabalha tende a ter desempenho muito ► Abril (6)
melhor do que a Internet de 10M da sua casa!!! As latências dos links de longa distância privativos ► Março (7)
são muito menores do que as latências das conexões residencias!
► Fevereiro (11)

Compreenderam? Espero que sim... ► Janeiro (12)

► 2012 (15)
O jitter, por exemplo, é uma métrica extremamente importante para ambientes que possuem
aplicações multimídia de "tempo real", como voz e vídeo. Os administradores de ambientes que
possuem essas aplicações devem sempre estar atentos não somente à latência que representa o
atraso na entrega dos pacotes, mas principalmente ao jitter. A latência mostra o desempenho real
da rede naquele exato momento, enquanto que o jitter mostra seu comportamento ao longo do
tempo, ou seja, define o grau de estabilidade da rede.

Pegando o exemplo do ping da figura acima que apresenta jitter de 15ms, esse seria um valor alto
para uma rede local cabeada (ethernet), mas é um valor comum em redes sem fio pela própria
natureza mutável do ambiente. Lembrem-se que as comunicações sem fio estão sujeitas a
interferência de vários fatores externos, por isso o sinal tende a oscilar com maior frequência - o que
as faz mais instáveis do que as redes cabeadas.

Uma evidência prática de que o jitter é ainda mais prejudicial para aplicações multimídia do que a
própria latência é que normalmente o recurso comumente utilizado para minimizar o efeito do jitter
consiste na utilização de buffers (pequenas memórias eletrônicas) nos dispositivos para armazenar Top Posts
os pacotes e, somente então, entregá-los "sem" jitter ao usuário, conforme pode ser observado na
figura abaixo. Lançamento do
Cisco Packet
Tracer 6.2.0

http://labcisco.blogspot.com.br/2013/05/interpretacao-dos-resultados-do-ping.html 2/7
15/10/2017 Blog LabCisco: Interpretação dos Resultados do Ping
Wireshark na
Análise de Tráfego
e Protocolos em
Redes

Interpretação dos
Resultados do Ping

Configuração de
Sw itch Multi-Layer
(Layer-3)

Calculando Sub-
Redes de Tamanho
Variável (VLSM)

Lançamento do
Cisco Packet
O problema é que essa "solução" implica no aumento da latência, o que mostra a preferência pelo Tracer 7.0
aumento na latência se houver diminuição do jitter. Obviamente que o alinhamento dessas duas
métricas (latência e jitter) acaba sendo um exercício de balança e o bom senso é fundamental para
assegurar o bom desempenho das aplicações. De nada adianta eliminar totalmente o jitter se a
latência ficar muito alta. O valor ideal do jitter vai variar em função da latência do link.

Status do IPv6
Por exemplo, no contexto de um link de longa distância xDSL (acesso à Internet) que tem em
média de 50ms a 100ms, um jitter de até 15ms ou 30ms pode ser aceitável. Por outro lado, no
contexto de uma rede local em que a latência máxima é 10ms, esses valores seriam inaceitáveis -
principalmente se existirem aplicações multimídia de "tempo real".

A gente costuma utilizar como medidas de referência para latência em aplicações multimídia o
limite de até 150ms para bom desempenho (recomendado) e valores entre 151ms até 400ms para
desempenho tolerável (não recomendado), sendo que qualquer valor acima de 400ms é
INACEITÁVEL!!!

Status do IPv4

IPv4 Exhaustion Counter

Quem diria que uma ferramenta tão simples quanto o ping seria na realidade tão poderosa, não é ▼ P re se n t Statu s ( R IR )
mesmo? ;-) Esse é um dos motivos de eu sempre dizer aos meus alunos que na área de network ing X-day and Reserved Blocks
（Remaining /8）
é crucial entrender os fundamentos por trás da tencologias, muito mais até do que saber AfriNIC
operacionalizar. O ideal é "casar" as duas coisas: fundamento e prática!
APNIC
Espero que esse artigo seja útil não apenas no dia-a-dia de vocês, mas principalmente no sentido
ARIN
de "abrir a mente" para a necessidade do profissional dessa área conhecer os fundamentos daquilo
que está operacionalizando! LACNIC

RIPE NCC
Abraço.

Samuel.

Postado por Samuel Henrique Bucke Brito às 13:30:00

Registro de Acessos
Marcadores: Desempenho, Monitoramento, Ping, SLA, Telecomunicações
2,374,433
25 comentários:
Busca por Palavra-Chave

Anônim o 4 de maio de 2013 16:59 #PodeAcreditar (2)

802.11 (9)
Ótimo post,
802.3 (4)
O resultado numérico de ferramentas de monitoramento de rede são apenas números sem o devido ACL (8)
conhecimento para interpretar os resultados. Esse post irá ajudar muitas pessoas que trabalham no dia-a-dia ANSI/TIA-568-C (5)
com monitoramente de redes. ARP (1)
AS (12)
Parabéns,
Backup (3)

http://labcisco.blogspot.com.br/2013/05/interpretacao-dos-resultados-do-ping.html 3/7
15/10/2017 Blog LabCisco: Interpretação dos Resultados do Ping
Filipe Banco de Dados (1)
Responder BGP (11)
Big-Data (2)
Respostas Blog (19)
BPDU (1)
Sam uel Henrique Bucke Brito 5 de maio de 2013 03:42 Cabeamento (10)
A proposta do artigo era exatamente essa, a de ajudar os profissionais que trabalham com redes Cat5e (3)
no dia-a-dia e que precisam interpretar os resultados de um monitoramento. Fico satisfeito e Cat6 (3)
realmente espero que o artigo seja útil para muitos dos leitores do blog.
Cat6A (2)
Cat7 (2)
Responder CCNA (17)
CEF (1)
Certificação (19)

FABRICIO RAMOS 6 de junho de 2013 16:00 CGI.br (8)

Cisco (123)
Ótima explicação.
Classe D (3)
Excelente, CORE (3)
Desempenho (13)
Fabricio Cruz DHCP (10)
Responder DHCP Snooping (1)
Disponibilidade (6)
DNS (4)
Anônim o 8 de setembro de 2013 21:31 Educação (13)
Interessante um curso de redes online com todos esses datalhes mostrados em teoria e prática? Já pensou EIGRP (3)
nisso professor Samuel? Entrevista (1)
Responder Errata (2)
Ether-Channel (3)
Respostas Ethernet (7)
Facebook (2)
Sam uel Henrique Bucke Brito 9 de setembro de 2013 00:37
Fibra Óptica (5)
Já me fizeram essa sugestão algumas vezes, no entanto a gravação das aulas consome muito Firew all (5)
tempo. Ultimamente estou com pouco tempo disponível porque estou tocando vários projetos Física (1)
paralelos... Abraço!
Fotos (2)
Gerenciamento (17)
Responder
GNS (9)
Governança (5)
HTTP (1)

Anônim o 14 de setembro de 2013 22:14 ICMPv6 (5)

IEEE (13)
Olá professor, qual a bibliografia usou ou que recomenda para estudar mais sobre esses assuntos desse
excelente texto? IETF (4)
IGP (2)
Queria estudar mais principalmente sobre a latência que que referiu das seguintes tecnologias: "1) Rede Informatize-se (1)
Local, (2) Internet via TV a Cabo, (3) xDSL, (4) Dial-Up e (5) Links de Longa Distância Privativo"
Internet (42)

Grato IOS (16)

IoT (3)
Responder
IPSec (4)
IPv4 (29)
Respostas
IPv6 (55)
Sam uel Henrique Bucke Brito 14 de setembro de 2013 22:23 ISP (4)
ISR (2)
Eu gosto bastante dos livros da Cisco Press porque eles são bem focados e específicos na sua
proposta. Por isso os livros de QoS da Cisco Press trazem uma boa abordagem desse contexto. Laboratório (96)
Dois títulos que eu sugeriria são: LACNIC (4)
LAN (6)
> IP Quality of Service
Linux (34)
Autoria: Srinivas Raju Vegesna
Livros (36)
> End-to-End QoS Netw ork Design: QoS in LANs, WANs, and VPNs Marco Civil da Internet (3)
Autoria: Tim Szigeti, Christina Hattingh MIB (1)
Microsoft (6)
Monitoramento (8)
Martony Dem es 29 de dezembro de 2013 18:40 MPLS (1)
Samuel, parabens pelo blog! Estou gostando muito. Inclusive adquiri seus dois livros. Quanto ao Multicast (4)
(5) links de longa Dist Privativo se inclue o ATM? Multimídia (6)
Quanto aos dois livros, tem tradução para portugues?
NAT (3)
NDP (1)
Negócios (2)
Sam uel Henrique Bucke Brito 29 de dezembro de 2013 19:37
NetFlow (1)
Olá Martony. NIC.br (31)
NMS (3)
Agradeço pelo feedback positivo. A tecnologia ATM normalmente implica em latências ainda
menores porque possui backbone óptico com circuitos OC (Optical Carrier), lembrando que a Notícias (34)
latência varia em função da distância. Imagino que você esteja se referindo aos livros de QoS que NTP (2)
mencionei em meu comentário anterior... Nesse caso, a resposta é que desconheço qualquer Ondas (1)
tradução desses livros.
OSPF (3)
P&D (4)
Continue acompanhando o blog!
Packet-Tracer (13)
Abraço. Palestra (10)
Par-Trançado (1)
Responder PIM-DM (2)
PIM-SM (2)
Ping (1)
PoE (1)

http://labcisco.blogspot.com.br/2013/05/interpretacao-dos-resultados-do-ping.html 4/7
15/10/2017 Blog LabCisco: Interpretação dos Resultados do Ping
Anônim o 7 de março de 2014 10:29 Policing (2)

Oi Samuel bom dia, Policy-Map (3)

Muito bom seu post, mas tenho alguma dúvida: Pós-Graduação (2)
Porque quando eu pingo o meu roteador com tamanho de buffer em 19232 vai ok, mas em 19233 causa PPP (3)
"esgotado tempo limite" ? PSTN (1)
PTT (3)
C:\Documents and Settings\mori>ping -t 192.168.1.1 -l 19233
Disparando contra 192.168.1.1 com 19233 bytes de dados: QoS (5)
Esgotado o tempo limite do pedido. Rack (1)
Esgotado o tempo limite do pedido. Redes Convergentes (2)
Esgotado o tempo limite do pedido.
Redistribuição (1)
Esgotado o tempo limite do pedido.
Esgotado o tempo limite do pedido. Relay-Agent (1)
Estat¡sticas do Ping para 192.168.1.1: Restrição de Banda (1)
Pacotes: Enviados = 5, Recebidos = 0, Perdidos = 5 (100% de perda), RFC (7)
Control-C
Rotas (2)
^C
C:\Documents and Settings\mori>ping -t 192.168.1.1 -l 19232 Roteamento (19)
Disparando contra 192.168.1.1 com 19232 bytes de dados: Route-Map (4)
Resposta de 192.168.1.1: bytes=19232 tempo=4ms TTL=64 Route-Reflector (1)
Resposta de 192.168.1.1: bytes=19232 tempo=4ms TTL=64
SAMBA (2)
Resposta de 192.168.1.1: bytes=19232 tempo=4ms TTL=64
SDN (4)
Resposta de 192.168.1.1: bytes=19232 tempo=4ms TTL=64
Resposta de 192.168.1.1: bytes=19232 tempo=4ms TTL=64 Segurança (19)
Shaping (1)
Estat¡sticas do Ping para 192.168.1.1: SLA (5)
Pacotes: Enviados = 5, Recebidos = 5, Perdidos = 0 (0% de perda),
SNMP (2)
Aproximar um n£mero redondo de vezes em milissegundos:
M¡nimo = 4ms, M ximo = 4ms, M‚dia = 4ms SSH (3)
Control-C STP (3)
^C Sw itch (21)
C:\Documents and Settings\mori>
TACACS+ (1)

grato e abraços, Telecomunicações (4)

Morikaw a Teleconferência (2)

Responder Telefonia (3)

Telnet (2)
Respostas Terminal-Server (1)
TV (3)
Sam uel Henrique Bucke Brito 7 de março de 2014 11:53 UNIMEP (14)
Olá Morikaw a, Vídeo (19)
VLAN (6)
O tamanho máximo do pacote IPv4 é 65535 bytes e o limite permitido no parâmetro size/lenght do VLSM (1)
ping é 65500. É provável que haja alguma regra de firew all pré-configurada no seu roteador que
VoIP (3)
esteja limitando esse parâmetro a 19232.
VPN (5)
Abraço. VRF (2)
WAN (5)
Responder WebEx (1)
Wireless (11)
Wireshark (3)
WLAN (9)
Anônim o 19 de julho de 2014 10:44

Só um detalhe sobre a medição do jitter do meu ponto de vista: Se você usar PINGs para medição de jitter
então você medirá algo completamente diferente do que a maioria das pessoas querem dizer quando falam
sobre "Jitter" para a Qualidade de Serviço (que é usado principalmente para medir a qualidade da linha de
dados para VoIP ou Vídeo).

Por favor, considerem os seguintes três aspectos que explicam a comparação entre a solução de medição de
jitter” PING” e “PRTG Netw ork Monitor” do sensor de QoS:

PINGs usam pacotes ICMP e muitos roteadores / sw itches dão a estes uma prioridade mais baixa.
Ao utilizar PINGs e medi-los em um ponto, o que você realmente está medindo é o tempo que o pacotes vai e
volta (sensor QoS do PRTG por outro lado só envia os pacotes em uma direção e as medidas de tempo de
viagem "one-w ay")

VoIP e vídeo na maioria dos casos, usam pacotes UDP no qual roteadores / sw itches são susceptíveis a dar
uma prioridade maior. Essa é a razão pela qual sensor de QoS do PRTG usa UDP para medir jitter etc .
Ps: As palavras acima foram retiradas de um site em Ingles que nao me recordo a muito tempo e que debatiam
sobre o mesmo assunto, achei interessante compartilha-las aqui! Só para incrementar o ótimo texto =D
No caso seria melhor utilizar ferramentas que gerem pacotes UDP para calcular o jitter real.

Responder

Respostas

Sam uel Henrique Bucke Brito 19 de julho de 2014 12:05

Não existem diferentes formas de jitter que, por definição, é a variação na latência da entrega de
pacotes. Nesse sentido, seu comentário está incorreto ao dizer que medir o jitter pelo ping é algo
completamente diferente do que a maioria das pessoas querem dizer. Se a rede não possui
nenhuma priorização de tráfego configurada (QoS), então a medição pelo ping é válida porque
existe somente um perfil de tŕafego para todo o ambiente. O ping é apenas mais uma ferramenta,
obviamente que nem sempre a malhor...

No entanto, sua observação está correta quando diz que medir o jitter através do ping pode ser
um problema em redes que tenham QoS configurado para priorizar determinado perfil de tráfego.
Isso porque é possível que o tráfego ICMP não seja priorizado e o resultado disso é uma
interferência direta nos resultados na medição, uma vez que outros perfis de tráfego
provavelmente tenham sido priorizados em detrimento do ICMP, o que impactaria negativamente na
fidelidade da medição.

Isso é natural, da mesma forma que a medição pelo ping sequer será possível em redes que
tenham regras de firew all bloqueando o ICMP. Repare que o artigo em questão não entrou no
mérito da existência dessas configurações, justamente para que o processo de medição seja

http://labcisco.blogspot.com.br/2013/05/interpretacao-dos-resultados-do-ping.html 5/7
15/10/2017 Blog LabCisco: Interpretação dos Resultados do Ping
válido. Em toda rede que possui VoIP e/ou outros tipos de aplicações multimídia é fortemente
recomendada a configuração de QoS para definir diferentes perfis de tráfego e priorizar aqueles
de tempo real (sensíveis e latência e jitter), por isso é importante fazer os testes com base no
mesmo perfil de tráfego desejado para não comprometer os resultados.

Aproveitando o gancho, o softw are PBX IP da Cisco (CUCM) já possui embutido nele ferramentas
para medição de jitter via UDP e o administrador pode visualizar essas informações através de
comandos "show " no próprio roteador. Por exemplo, o administrador pode visualizar o status das
chamadas/sessões ativas entre dois telefones e checar o resultado do jitter referente àquela
chamada específica, o que é muito útil.

Certamente sua observação pode foi/será a dúvida de outros leitores, agradeço pela comentário.

Abraço.

Responder

Wilson Junior 25 de setembro de 2014 10:50

Excelente artigo mestre Samuel!!!

Responder

Renan Godoi 4 de outubro de 2014 00:09

Parabéns.. Otimo texto.

Gostaria só de acrescentar uma dica que também conseguimos através do PING, que é identificar o Sistema
Operacional pelo TTL ( time to live) Todo sistema operacional possui um padrão de retorno, que é em UNIX
255, Linux 64,Window s 128. Isso Ja me ajudou em alguns casos de suporte e pode ser util.

Responder

Anônim o 1 de abril de 2015 11:56

Olá Samuel, estou como uma duvida, como eu faria para resolver esta questão?
Qual é a formula?

2) Qual seria a taxa real de transmissão (bps) através de uma rede que, após um teste com o comando PING
no servidor, obteve-se os seguintes resultados: (Dica: 1ms = 0,001s)
C:\PING 10.0.160.208
Disparando contra 10.0.160.208
Resposta de 10.0.160.208: Bytes=32 tempo = 9ms
Resposta de 10.0.160.208: Bytes=32 tempo = 7ms
Resposta de 10.0.160.208: Bytes=32 tempo = 6ms
Resposta de 10.0.160.208: Bytes=32 tempo = 7ms

Estatísticas do PING para 10.0.160.208:

Pacotes enviados = 4, Recebidos = 4, Perdidos = 0 (0% de perda),
Aproximar um número redondo de vezes em milissegundos:
Mínimo = 6, Máximo = 9, Média = 7

Responder

Respostas

Sam uel Henrique Bucke Brito 10 de abril de 2015 15:55

O ping isoladamente não vai te ajudar e determinar a vazão da sua rede em bps, uma vez que ele
utiliza as mensagens "echo request" e "echo reply" para determinar a latência na comunicação
entre dois hosts. Para ajudá-lo, recomendo a leitura de outro artigo no blog:

http://labcisco.blogspot.com.br/2013/04/iperf-no-monitoramento-de-desempenho-em.html

Unknow n 12 de fevereiro de 2016 19:15

não consigo add esse servido no meu celular não pq?

Responder

Wallace 24 de maio de 2015 18:03

Artigo sucinto e direto.

Parabéns!

Responder

José Eduardo Santos 3 de outubro de 2015 21:24

Este site é excelente para estudo de T.I.,pois,ajuda o estudante de T.I. a tirar suas próprias conclusões,nos
dando grande campo de visão e estimulando de um modo elegante,ao estudante a ter grande interesse na
matéria T.I..Parabéns!

Responder

carlos ibarra 21 de novembro de 2015 09:25

Muito bacana a postagem e os comentários!

Responder
http://labcisco.blogspot.com.br/2013/05/interpretacao-dos-resultados-do-ping.html 6/7
15/10/2017 Blog LabCisco: Interpretação dos Resultados do Ping
Responder

Treta Entre Nós 11 de maio de 2016 13:01

ping em todos os sites sao iguais ?? me expliquem

Responder

Tharivol 19 de maio de 2016 14:19

"vazão em bps, latência (atraso), jitter (variação da latência no tempo)" quais ferramentas realizam essas
operações?

o cisco packet tracer tambem monitora a rede simulada e devolve essas informaçoes para o usuario?

Responder

Hiago Costa 27 de setembro de 2016 00:30

professor, bom dia,

num cenário simples, qual é a ferramente utilizada mais comumente para se medir o Jitter de links de internet?
ele serve também para algum tipo de medição em uma rede privada?

Responder

Marcus Afonso 8 de agosto de 2017 06:25

Grato pela explicação. Estou leigo no assunto e começo a entender como funciona minha internet. Grato
professor Samuel. Marcus Afonso. Manaus/Amazonas. mbinda@live.com.pt

Responder

Digite seu comentário...

Comentar como: Conta do Google

Publicar Visualizar

Postagem mais recente Página inicial Postagem mais antiga

Assinar: Postar comentários (Atom)

Prof. Samuel Henrique Bucke Brito. Tema Simples. Tecnologia do Blogger.

http://labcisco.blogspot.com.br/2013/05/interpretacao-dos-resultados-do-ping.html 7/7