NetDiag+
Evidências que a sua operadora não consegue ignorar
"À noite minha internet fica lenta" é uma sensação, e o suporte é treinado para responder a sensações com um reboot do roteador. Um número com lugar e hora é outra conversa: a perda de pacotes começa no meu terceiro salto toda noite depois das nove, aqui estão as execuções. Três medições fazem esse trabalho — onde a perda começa, como a latência se comporta sob carga e quão longe e quão instáveis estão os servidores que você realmente usa — e desde o NetDiag+ 1.4.6 cada uma delas exporta como texto puro para colar em um chamado, um fórum ou o formulário da Anatel.
Três medições que apontam um lugar e uma hora
- Localize a perda com o MTR. Um traceroute que continua pingando cada salto mostra onde os pacotes começam a sumir. Perda que começa em um salto e persiste até o fim é real, e esse salto aponta a rede responsável. Perda em um único salto que desaparece no seguinte é aquele roteador limitando as próprias respostas — normal, não é evidência. Rode na hora ruim e anote o salto.
- Adicione a latência sob carga e a tabela de latência. Um teste de bufferbloat diz quanto a latência sobe com a linha ocupada e em que direção: um pico no upload aponta para o seu roteador, um pico no download para o equipamento da operadora — e essa direção é o que decide de quem é o problema. O Painel de latência adiciona mediana, jitter e perda aos servidores que você usa, medindo o seu roteador primeiro para que ninguém possa culpar o seu Wi-Fi se ele estiver limpo.
- Exporte como texto, nas horas certas, mais de uma vez. Toda ferramenta tem Compartilhar → relatório de texto: alvos, horários, todos os números. Uma execução não prova nada; três na hora ruim em dias diferentes mais uma em hora tranquila como controle é um padrão. O gráfico de tendência de bufferbloat guarda o pior pico de cada execução ao longo de 7, 30 ou 90 dias, então o padrão fica visível sem você anotar nada. O histórico guarda tudo o que você rodou.
Grátis · 27 ferramentas · compra única remove os anúncios · sem assinatura
Perguntas que as pessoas realmente fazem
O que o chamado deve conter, exatamente?
Datas e horários de cada execução. O salto onde a perda começa e a porcentagem. Latência ociosa contra latência com download e com upload. Mediana e jitter para dois ou três servidores que a sua casa usa. Qual teste foi o controle. Tudo colado como texto, não descrito — um técnico consegue agir sobre uma lista de saltos, não sobre "está travando".
O suporte diz que a linha está boa. Estão mentindo?
Geralmente não. Os testes deles verificam níveis de sinal, contadores de erro e vazão, e tudo isso pode estar perfeito enquanto uma fila adiciona 300 ms ou um link de peering congestionado derruba 2% dos pacotes às nove da noite. Você está medindo algo que eles não medem. Diga isso e entregue os números.
Capturas de tela ou texto?
Texto. Dá para buscar, citar, colar em uma ferramenta interna e encaminhar ao engenheiro que realmente conserta; uma captura, não. Texto também sobrevive à compressão de imagem de um fórum e ao formulário web de um regulador. Guarde as capturas para você.
Quantas execuções formam um caso?
O suficiente para mostrar que o problema se repete e depende do horário. Três execuções na hora ruim em dois ou três dias, mais uma em hora boa que volta limpa, é o mínimo que transforma uma reclamação em relatório. Se a da hora boa também vier ruim, a causa não é congestionamento — isso também é útil.
Isso realmente faz alguém consertar algo?
Move o chamado do primeiro nível para alguém que sabe ler uma lista de saltos, que é a etapa onde normalmente trava. Onde existe regulador, os formulários de reclamação pedem exatamente isto: datas, medições, o que a operadora respondeu. Evidência não garante conserto; ela remove os motivos para dizer não.
O número isolado mais forte em tudo isso é a latência sob carga. Próximo: qual servidor está longe e qual está instável →