Seu speed-test mente. Meça responsiveness em vez disso.

A mentira do número grande

Todo site de speed-test abre com um mostrador. Ele acelera, para num número impressionante (480 down, 510 down, 940 down se você é fibra) e esse número vira a história. A história quase sempre está errada. Não desonesta, exatamente. Só a pergunta errada, respondida com precisão.

Vazão é uma medida de capacidade: quanta água o cano consegue mover quando nada mais está acontecendo. O problema é que redes reais quase nunca parecem com "nada mais está acontecendo". Redes reais parecem com uma chamada de vídeo da família, um backup na nuvem, um sync do Slack, uma atualização de software e uma criança vendo desenho, tudo ao mesmo tempo. Nessa cena, o que importa não é o total de litros por minuto. O que importa é se o seu pacote de voz consegue cortar a fila e chegar a tempo.

Essa segunda pergunta é responsiveness, e por vinte anos mal tivemos como medi-la num navegador. Agora temos. Está embutida no macOS. Só não te contaram.

O que é bufferbloat, em um parágrafo

Todo roteador e modem entre seu laptop e a internet tem um buffer: um pedacinho de memória onde os pacotes esperam a vez deles. Quando o link na frente do buffer é mais lento que o link atrás dele (seu uplink de 40 Mbps atrás de um LAN de gigabit, digamos), o buffer começa a encher. Os fabricantes fizeram esses buffers absurdamente grandes, porque jogar pacote fora parece bug. Mas um buffer grande demais segura o seu pacote de voz do Zoom atrás de cada outro pacote que apareceu um milissegundo antes. O cano está movendo bytes de sobra. Os bytes que importam só estão na fila. Esse atraso (medido em centenas de milissegundos sob carga) é bufferbloat. É por isso que seu speed-test passa e a chamada desmonta.

Conheça o RPM: Round-trips Per Minute

Em 2021 o time de redes da Apple propôs uma métrica em linguagem clara: RPM, ou Round-trips Per Minute. A ideia é quase constrangedoramente simples. Enquanto o cano está saturado (você está baixando e enviando a todo vapor), conte quantos round-trips completos de requisição/resposta você consegue fechar em um minuto. Uma rede responsiva faz milhares. Uma rede bloated cai para algumas centenas. Mesmo cano de 500 Mbps, nos dois casos.

A Apple lançou uma ferramenta para isso no macOS Monterey. Ela se chama networkQuality, vive em /usr/bin/networkQuality, e se você abrir um Terminal e rodar, vai ver algo assim:

$ networkQuality
==== SUMMARY ====
Uplink capacity:   38.412 Mbps
Downlink capacity: 476.185 Mbps
Responsiveness:    Medium (540 RPM)
Idle Latency:      18 ms

Leia essa saída com calma. O cano é grosso, quase meio gigabit em download. A responsividade é medium. 540 round-trips por minuto dão cerca de nove por segundo: seu pacote de voz espera mais ou menos 111 ms numa rede carregada, contra 18 ms quando ociosa. Essa lacuna é a razão exata pela qual sua chamada soa bem quando ninguém mais está em casa, e desmorona quando a família toda está streamando.

High, Medium, Low, o que isso significa?

A Apple agrupa o RPM em três categorias legíveis:

High, 2.000 RPM ou mais. A rede é responsiva. Trabalho em tempo real (chamadas, jogos, edição colaborativa) vai parecer firme, não importa o que mais esteja rodando.
Medium, mais ou menos 600–2.000 RPM. A rede ainda dá pra usar, mas apps interativos vão parecer pesados sob carga. É onde ficam quase todas as redes domésticas no horário nobre, e de onde vêm as reclamações.
Low, abaixo de 600 RPM. Os buffers estão cheios. Chamadas de voz caem, vídeo congela, teclas no SSH chegam em rajadas. Nenhuma quantidade extra de banda resolve isso até os buffers esvaziarem.

Por que um speed-test não enxerga isso

Um speed-test mede só a metade fácil do problema: idle throughput, geralmente em uma rajada curta, geralmente sobre uma conexão que sua operadora aprendeu a priorizar. Ele te conta o que seu cano consegue fazer quando ele está pouco carregado, e nunca faz a pergunta seguinte sobre latência sob carga. Bufferbloat é, por definição, invisível para esse teste, porque o teste é a carga, não há outro tráfego para fazer fila atrás.

O sintoma do lado do cliente é familiar. O técnico da operadora aparece, roda o speed-test, ele passa, e te dizem que a conexão está bem. A próxima chamada de vídeo trava do mesmo jeito. O técnico não mentiu. Ele só mediu a coisa errada.

O teste de RPM na prática

O networkQuality da Apple é elegantemente brutal. Ele abre várias conexões paralelas para endpoints de CDN, satura nos dois sentidos e então cronometra quanto tempo um par pequeno de requisição e resposta HTTP/2 leva para completar enquanto a saturação está rolando. Esse é o valor de RPM. As medidas de capacidade saem de carona, é por isso que a ferramenta entrega os três números numa única execução.

O teste leva uns quinze segundos. Ele martela seu link, então não rode durante uma chamada. Ele também revela coisas que sua operadora preferiria não mostrar: canais de Wi-Fi colidindo com vizinhos, um roteador com bug de firmware que dobra a profundidade da fila, uma VPN que adiciona 200 ms de latência em cada round-trip. Você vai descobrir, com muita frequência, que o elo fraco não é a operadora. É algo dentro da sua casa.

O que fazer quando o RPM está Low

Não tem solução única, mas a checklist é finita:

Teste no fio antes. Plugue um cabo Ethernet no Mac e rode networkQuality de novo. Se o RPM pular pra High, seu problema é o Wi-Fi (congestão, sobreposição de canal ou distância), não a operadora.
Ative Smart Queue Management. Roteadores que suportam SQM, CAKE ou fq_codel achatam o bufferbloat dramaticamente. Um roteador de $100 com fq_codel ligado bate um de $600 sem.
Limite seu upload. Se SQM não estiver disponível, restrinja o upload do Mac a uns 90 % da capacidade de uplink que você mediu. Só essa mudança já evita que seus próprios uploads encham o buffer e deixem seus downloads sem ACK de retorno.
Troque o combo modem-roteador da operadora. Boa parte dos equipamentos fornecidos pelas ISPs é configurada para benchmarks de vazão, não para responsividade. Colocar o equipamento da operadora em modo bridge e seu próprio roteador na frente é a maior melhoria isolada de RPM que a maioria das pessoas vai ver.

Três mitos teimosos

"Mais banda resolve." Às vezes, na maior parte não. Se seu uplink já está saturado por um único backup, subir de 40 para 100 Mbps de upload vai ajudar. Mas se o culpado é o buffer, você vai bater no mesmo teto duas vezes mais rápido e os sintomas voltam. A solução é esvaziar a fila, não engrossar o cano à frente dela.

"Meu ping é 12 ms, então tudo bem." Ping mede latência ociosa: quanto tempo um pacote leva quando nada está no caminho. Bufferbloat só aparece sob carga. Um ping ocioso de 12 ms num link bloated rotineiramente vira 350 ms sob carga. Rode ping num terminal e um upload grande em outro, e você vai ver isso acontecer em tempo real.

"A operadora já otimizou pra isso." Algumas, sim. Muitas, não. A engenharia não é difícil, mas o incentivo comercial aponta no sentido oposto: uma rede ajustada para speed-test ganha em mercados que compram pelo número de vazão. Responsividade quase nunca aparece numa página de marketing.

Onde o WiFi & IP Info se encaixa

Colocamos o motor networkQuality a um clique de distância na barra de menus. O painel Network Quality do nível Pro roda o mesmo teste da Apple, expõe a capacidade de uplink/downlink, reporta a faixa de RPM e a linha-base de RTT, e, crucialmente, mantém um log. Você pode clicar em "rodar de novo" uma vez por hora durante uma semana e ver o padrão: High no sábado de manhã, Medium no jantar, Low quando as crianças voltam da escola. É esse gráfico que faz a operadora realmente fazer alguma coisa, porque reprodutibilidade é o que transforma uma reclamação em chamado.

Combine com o gráfico de Histórico de latência e o Registro de conexões do app, e você manda à sua operadora um chamado de trinta segundos: "RPM cai de 2.400 para 410 entre 18:00 e 21:00 horário local, correlacionado com RTT mediano três vezes maior até o gateway de vocês. CSV anexado." É uma conversa muito diferente de "minha internet está lenta."

A versão curta

Seu speed-test mede capacidade. Capacidade é real, e de vez em quando ela é o problema. Na maior parte das vezes, porém, o problema é responsiveness: se seu tráfego consegue entrar e sair rápido enquanto o cano está ocupado. RPM é a métrica para isso. A Apple construiu uma ferramenta de primeira para medir isso. Nós colocamos essa ferramenta na sua barra de menus, e mantemos o histórico.

Se você for guardar uma só frase desta página, que seja esta: banda é o tamanho da rua; responsividade é quanto você espera no semáforo. As duas importam. Só uma delas está na sua página de speed-test.