Como realmente ler um teste de velocidade

Um teste de velocidade que mostra um único número, “sua velocidade é 340 Mbps”, responde uma pergunta bem menor do que a maioria pensa. Uma conexão são vários números, não um, e esta guia cobre o que significa cada número da tela de resultados, seguido de exatamente como o Sygnal Score os transforma num único veredito honesto.

Download e upload

São o que todo mundo espera: quantos megabits por segundo se movem em cada direção. Importam, mas menos isoladamente do que sugere o marketing no site do seu provedor, veja a guia sobre quanta velocidade você realmente precisa para os números reais por atividade. Uma assimetria que vale conhecer: a maioria dos planos residenciais é muito mais generosa com download do que com upload, o que é ótimo para navegar e assistir streaming, e uma limitação real para quem envia vídeo com frequência.

Latência ociosa

O tempo de ida e volta até um servidor próximo quando nada mais está acontecendo na linha, o número base de “a que distância está a internet, agora”. Latência ociosa entre 10 e 30ms é típica para uma conexão cabeada ou WiFi boa até um servidor próximo; acima disso, coisas interativas, chamadas, jogos, até uma página parecer instantânea, começam a sofrer, não importa quanta velocidade de download você tenha.

Latência sob carga e a diferença

A mesma medição de ida e volta, feita enquanto as fases de download e upload estão saturando ativamente a linha. Numa conexão limpa, isso quase não se move do número ocioso. Numa conexão com uma fila superdimensionada e sem gerenciamento em algum ponto do caminho, pode disparar para centenas ou milhares de milissegundos, isso é bufferbloat, e tem sua própria guia dedicada por ser o problema mais subestimado das redes domésticas. O número que importa não é nenhuma das duas leituras isoladas, é a diferença entre latência sob carga e ociosa: uma diferença pequena significa que a conexão continua ágil sob uso real, uma grande significa que ela desmorona bem quando você mais a está usando. A tela de resultados dá uma nota a essa diferença: A+ abaixo de 5ms, A abaixo de 15, B abaixo de 50, C abaixo de 150, D abaixo de 400 e F acima disso. A nota é dada pelos picos (o percentil 90 dos pings sob carga, na pior das fases de download e upload), enquanto a latência sob carga exibida é o valor típico (a mediana): uma linha que costuma ir bem mas tem picos recebe mesmo assim a nota que merece.

Jitter

A variação da latência de um pacote para o próximo, não a latência em si. Uma conexão com 40ms de latência que se mantém em 40ms é bem melhor para uma chamada ou um jogo do que uma que oscila entre 20ms e 90ms, mesmo que a média pareça idêntica, o jitter é o que faz uma chamada engasgar ou um jogo parecer inconsistente mesmo com o “ping” médio parecendo bom.

O jitter também é o número com maior chance de parecer bom na média e ainda assim arruinar uma chamada ou uma partida, um único trecho ruim de dois segundos é exatamente aquele momento de travar-e-recuperar numa videochamada. Se algo pareceu ruim durante uma chamada ou um jogo mas o teste depois parece limpo, isso não é necessariamente uma contradição, pode significar que o problema foi um pico breve que aquela única rodada de teste não capturou. Rodar o teste duas ou três vezes, especialmente durante a atividade que pareceu ruim, dá um retrato bem mais honesto do que qualquer rodada única.

Requisições com falha (e por que isso não é perda de pacotes)

O último número da tela de resultados é a porcentagem das próprias requisições do teste que falharam por completo: uma medição de latência que nunca voltou, ou um fluxo de download ou upload que foi interrompido antes de terminar. Numa conexão saudável, ele marca 0%. Um teste faz um número limitado de requisições, então uma única falha já pode aparecer como vários pontos percentuais, rode o teste de novo antes de tirar conclusões.

Não é perda de pacotes, e nós não a chamamos assim. Perda de pacotes são pacotes que nunca chegam, e ela é brutal para tráfego em tempo real: uma chamada ao vivo ou um jogo competitivo não têm tempo de esperar um reenvio, então até uma pequena porcentagem é sentida como um engasgo, um congelamento ou uma palavra perdida. Um teste de velocidade no navegador não consegue vê-la diretamente. Suas requisições trafegam sobre TCP, que reenvia em silêncio os pacotes perdidos, então a perda real só aparece aqui de forma indireta (como velocidade menor e latência mais alta ou com mais picos), nunca como uma contagem de pacotes perdidos. Medir a perda de pacotes real exige outro tipo de teste, que envie pacotes sem reenviá-los. Como as requisições com falha são um sinal bem mais grosseiro, elas aparecem só como informação e não contam nem para o Sygnal Score nem para as avaliações por uso.

O que o Sygnal Score faz com eles

O Sygnal Score transforma cinco dessas medições num número de 0 a 1.000, ponderado assim: download 300 pontos, upload 150, latência ociosa 175, bufferbloat 275, jitter 100, os pesos somam exatamente 1.000 quando todas as medições estão presentes. As requisições com falha não fazem parte dele, pelos motivos acima. Download e upload são escalados em logaritmo, não de forma linear, porque é assim que o valor real da velocidade se comporta: no download, as âncoras são 25 Mbps → 150 pontos, 100 Mbps → 225 pontos, 300 Mbps → 270 pontos, 1.000 Mbps ou mais → os 300 completos. O salto de 5 para 25 Mbps muda o que uma casa consegue fazer de verdade; o salto de 500 para 1.000 quase não muda nada, e o placar reflete isso em vez de fingir que gigabit é dez vezes melhor que 100 Mbps.

O bufferbloat é o maior bloco, com 275 pontos, de propósito, crédito total com diferença de 15ms ou menos entre carga e ociosidade (território da nota A), medida nos mesmos picos que a nota usa, crédito zero a partir de 400ms, porque uma conexão que parece rápida mas desmorona assim que é realmente usada não é uma boa conexão, e um placar baseado só em velocidade a chamaria de boa mesmo assim.

O número final cai numa de cinco faixas: excepcional (900+), forte (750+), decente (550+), com dificuldades (350+), ou fraca (abaixo de 350).

Por que uma linha rápida ainda pode pontuar baixo

Há mais uma regra, em cima de toda essa conta, e ela existe por causa de uma lacuna real na matemática acima: uma conexão lenta mas limpa pode conseguir um placar surpreendentemente alto só com os blocos da família de latência, mesmo que uma casa naquela linha não consiga transmitir 4K de forma confiável nem usar mais de um ou dois dispositivos. Um download de 0,5 Mbps com latência por outro lado perfeita pode pontuar na faixa dos 600, só com latência ociosa, bufferbloat e jitter, claramente errado para uma linha tão lenta.

A trava de velocidade existe para evitar isso: o placar fica limitado pela velocidade de download, numa escala, não importa quão limpo o resto da conexão meça. Abaixo de 25 Mbps, o placar não pode passar de 749 (o teto da faixa “decente”), uma casa abaixo dessa linha genuinamente não consegue fazer tudo que uma conexão moderna deveria, não importa quão limpa seja sua latência. Abaixo de 5 Mbps, a trava aperta para 549. Abaixo de 1 Mbps, aperta de novo para 349. Ao superar 25 Mbps a trava se solta por completo; nada acima desse limite fica travado por velocidade, só pelo desempenho real da conexão. Se o seu placar parece travado, é por isso, e é a resposta honesta, não uma penalidade: “seu Sygnal é tão forte quanto seu elo mais fraco” é a ideia inteira, e para uma linha muito lenta, a própria velocidade é esse elo.