Problema intermitente de alta ping / latência

3

Eu tenho trabalhado com o meu ISP (que é um WISP, na verdade, fixo de banda larga sem fio) tentando descobrir por que eu recebo intermitentemente alta latência. A latência é detectável em jogos online e outros aplicativos de streaming. Se eu fizer uma rota de rastreamento, você poderá ver o caminho pela rede de back-haul:

Tracing route to google.com [74.125.67.105]
over a maximum of 30 hops:

  1     1 ms     4 ms    <1 ms  192.168.23.1
  2     1 ms     8 ms     9 ms  10.100.100.1
  3     9 ms     9 ms     3 ms  10.7.37.1
  4    15 ms    24 ms    19 ms  10.7.36.1
  5    10 ms    79 ms     9 ms  10.7.31.3
  6    10 ms    39 ms    39 ms  10.10.5.9
  7    19 ms    19 ms    19 ms  10.10.5.5
  8     9 ms    19 ms    19 ms  10.10.5.1
  9   341 ms   237 ms   226 ms  10.250.200.1
 10   249 ms   280 ms   991 ms  <ISP WAN IP>
 11   703 ms   681 ms   401 ms  <ISP WAN IP>
 12   819 ms   628 ms   484 ms  <AT&T IP>    <- Traffic enters AT&T backbone
 13   699 ms   528 ms   290 ms  <AT&T IP>
 14   201 ms   106 ms    52 ms  <AT&T IP>
 15   624 ms   392 ms   436 ms  <AT&T IP>
 16   666 ms     *      252 ms  <AT&T IP>
 17   456 ms   403 ms   581 ms  209.85.254.120
 18   430 ms   339 ms     *     209.85.242.215
 19  1061 ms    56 ms    53 ms  72.14.239.131
 20  3514 ms   734 ms   219 ms  209.85.255.190
 21    49 ms    59 ms    56 ms  74.125.67.105

O que parece indicar que o problema é o host em 10.250.200.1. No entanto, se eu pingar diretamente o host tudo parece bem (~ 10ms ida e volta). Fazer ping em saltos subseqüentes após o nó suspeito também proporciona tempos de ida e volta razoáveis. A alta latência pode persistir por apenas alguns segundos até alguns minutos de cada vez.

EDIT Sim, este é um mau exemplo de um rastreio mostrando um problema definido, mas depois de testes repetidos nunca há latência > 100ms antes do salto 9, foi por isso que pensei que poderia ser um problema.

Um caminho durante o evento produz o seguinte:

        Source to Here   This Node/Link
Hop  RTT    Lost/Sent = Pct  Lost/Sent = Pct  Address
  0                                           192.168.23.129
                                0/ 100 =  0%   |
  1    2ms     0/ 100 =  0%     0/ 100 =  0%  192.168.23.1
                                0/ 100 =  0%   |
  2    3ms     0/ 100 =  0%     0/ 100 =  0%  10.100.100.1
                                0/ 100 =  0%   |
  3   14ms     0/ 100 =  0%     0/ 100 =  0%  10.7.37.1
                                0/ 100 =  0%   |
  4   15ms     0/ 100 =  0%     0/ 100 =  0%  10.7.36.1
                                0/ 100 =  0%   |
  5   19ms     0/ 100 =  0%     0/ 100 =  0%  10.7.31.3
                                0/ 100 =  0%   |
  6   27ms     0/ 100 =  0%     0/ 100 =  0%  10.10.5.9
                                0/ 100 =  0%   | 
  7   28ms     0/ 100 =  0%     0/ 100 =  0%  10.10.5.5
                                0/ 100 =  0%   |
  8  ---     100/ 100 =100%   100/ 100 =100%  10.10.5.1
                                0/ 100 =  0%   |
  9   25ms     0/ 100 =  0%     0/ 100 =  0%  10.250.200.1
                                0/ 100 =  0%   |
 10   24ms     1/ 100 =  1%     1/ 100 =  1%  <ISP WAN IP>
                                0/ 100 =  0%   |
 11   25ms     4/ 100 =  4%     4/ 100 =  4%  <ISP WAN IP>
                                0/ 100 =  0%   |
 12   35ms     0/ 100 =  0%     0/ 100 =  0%  <AT&T IP>
                                0/ 100 =  0%   |
 13  ---     100/ 100 =100%   100/ 100 =100%  <AT&T IP>
                                0/ 100 =  0%   |
 14  ---     100/ 100 =100%   100/ 100 =100%  <AT&T IP>
                                0/ 100 =  0%   |
 15  ---     100/ 100 =100%   100/ 100 =100%  <AT&T IP>
                                0/ 100 =  0%   |
 16   58ms     0/ 100 =  0%     0/ 100 =  0%  <AT&T IP>
                                1/ 100 =  1%   |
 17   59ms     1/ 100 =  1%     0/ 100 =  0%  209.85.254.120
                                0/ 100 =  0%   |
 18   59ms     1/ 100 =  1%     0/ 100 =  0%  209.85.242.215
                                0/ 100 =  0%   |
 19   56ms     1/ 100 =  1%     0/ 100 =  0%  72.14.239.127
                                0/ 100 =  0%   |
 20   60ms     1/ 100 =  1%     0/ 100 =  0%  209.85.255.194
                                0/ 100 =  0%   |
 21   59ms     1/ 100 =  1%     0/ 100 =  0%  74.125.67.105

Por que essa latência só aparece durante uma rota de rastreamento e não com um ping normal? A falta de desempenho que vejo na minha aplicação coincide com isso.

Em outras palavras, apesar de ter problemas com meu aplicativo, se eu executar um rastreio ao mesmo tempo, obtenho o resultado acima e, ao mesmo tempo, fazendo ping no host suspeito mostra um ping normal.

    
por Hugh Jeffner 03.07.2011 / 18:51

6 respostas

0

Após mais testes, isso é um problema com a latência do UDP.

O motivo pelo qual a alta latência coincide com o desempenho insatisfatório do aplicativo parece ser um host ligado à CPU. Um pacote ICMP com um TTL expirado requer tempo de CPU para criar uma resposta e, portanto, a maioria dos roteadores é configurada para "responder quando eu quiser". A latência no tráfego ICMP TTL expirado é uma indicação de um roteador ocupado nesse caso. O host parece estar no limite de sua rede, então um grande pedaço de todo o tráfego está passando por esse salto.

Suspeito que o ISP está fazendo algum tipo de inspeção de tráfego ou modelagem do protocolo UDP, o que também requer tempo de CPU.

    
por 10.08.2011 / 23:56
4

WISP? Significado Wireless ISP? Se assim for, há a sua resposta provável. Sem fio não é confiável e você está vendo a prova disso.

Você não pode consertá-lo porque seu meio (a atmosfera) é realmente horrível para transmitir dados. Primeiro porque o ar é um hub em vez de um switch, então você o está compartilhando com qualquer pessoa ao seu redor e colidindo pacotes, segundo porque CSMA / CA é mais lento que o CSMA / CD, terceiro porque o wireless é geralmente half-duplex em vez de full duplex e o quarto porque há ordens de grandeza de maior interferência através do ar versus o cobre. [As microondas, por exemplo, operam no mesmo comprimento de onda que o 802.11b / g ... mas o micro-ondas opera a cerca de 500-1000 Watts em relação aos 100 miliwatts da sua antena sem fio. As microondas são blindadas, mas a blindagem não é perfeita e as microondas não são regulamentadas pela FCC, portanto, não é ilegal causar interferência.] Além disso, o fato de você estar passando por mais de 10 saltos apenas para chegar à Internet. Isso não pode estar ajudando, especialmente se houver algum NAT ou firewall em andamento.

Como o @dbasnett diz, a latência do ping traceroute para um determinado host indica apenas o estado de toda a rede entre as interfaces tomadas como um todo naquele momento. É por isso que os tempos de resposta vão para baixo às vezes. Eles são pontiagudos porque a rede não é confiável. Seu pathping parece bom porque está executando um grande número de consultas, em vez de apenas 3 que tracert está sendo executado. Portanto, pathping mostra o que a rede está fazendo em um período de 325 segundos (por padrão) e tracert está mostrando quais são os 3 pacotes por salto na rede.

    
por 03.07.2011 / 19:48
3

9 vezes em 10 resultados de rota de rastreamento não são uma indicação de problemas de rede. O traceroute envia pacotes de solicitação de eco ICMP para cada salto sucessivo entre a origem e o destino, incrementando o TTL em um para cada salto sucessivo. O resultado de cada salto é uma indicação de como esse salto está respondendo ao tráfego ICMP, não é uma indicação da qualidade do caminho através e além desse salto. Um trabalho de roteador é encaminhar o tráfego e, como tal, muitos são programados para ignorar, descartar ou dar baixa prioridade ao tráfego ICMP direcionado a eles mesmos. O fato de os saltos 14, 19 e 21 terem tempos de resposta muito bons são indicadores de que não há nada de errado com o caminho. Se houvesse um problema no salto 12 (como você destacou) ou em qualquer outro salto que estivesse afetando o caminho, você veria um problema em cada salto sucessivo e veria cada salto pior que o anterior. Somente quando você vir esses tipos de resultados no traceroute, você deve suspeitar de um problema de caminho. O Hop 21 é o destino e, com um tempo de resposta de 59 ms, está dizendo que o caminho entre a origem e o destino é bom. A chave para analisar um problema de caminho é analisar seu desempenho enquanto dados reais o transitam, o que não pode ser feito a menos que você tenha um sniffer de pacote / monitor de rede em cada salto e tenha acesso a memória, CPU e contadores de throughput em cada nó da rede (roteadores e switches) no caminho da origem ao destino.

Em vez de tentar descobrir por que você tem problemas de desempenho com base em um tracert do caminho, você deve se concentrar na sessão TCP real entre a origem eo destino e examinar o tempo de resposta (latência) e qualquer perda de pacote entre eles. dois pontos finais.

Rota de rastreamento, como o próprio nome indica, é uma ferramenta para descobrir o caminho entre dois pontos de extremidade, não é uma ferramenta para analisar a qualidade desse caminho.

    
por 03.07.2011 / 19:42
1

Eu tenho que concordar com joeqwerty, o ICMP há muito tempo deixou de ser uma medida confiável de desempenho, latência ou throughput. Isso seria especialmente verdadeiro para rotas com muitos saltos em redes desconhecidas.

Um teste mais realista seria um com o (s) protocolo (s) que você está usando. Por exemplo, se fosse http, você poderia configurar uma captura de pacotes de rede Wireshark. Filtre na conversa com o host especificado e use as Estatísticas do Wireshark > Gráfico do Fluxo TCP > Gráfico de tempo de viagem de ida e volta. Este teste é mais preciso se você realizar a captura por pelo menos alguns minutos.

Outra opção interessante é o Padrão PingPlotter (não gratuito, mas com recurso completo por 30 dias). Isso fornece uma excelente capacidade de teste de taxa de transferência específica ao protocolo, especificando o número da porta e possui gráficos de tempo de ida e volta e pode ser salvo e carregado.

    
por 03.07.2011 / 20:11
0

Os pings e a rota de rastreamento (pings com um TTL específico) são temporais. O que você vê em um instante específico no tempo é apenas isso e não tem nada a ver com eventos passados ou futuros.

Parte da largura de banda da Internet (2% ish) é o tráfego de ping, que, a menos que você seja uma pessoa de backbone da Internet, não serve a nenhum propósito real. Se você tiver um problema, ligue para o seu ISP.

    
por 03.07.2011 / 19:17
-1

Certifique-se de reduzir seus buffers no link saturado.

    
por 04.07.2011 / 10:53