O ping marca 25 ms no lobby e 90 ms assim que a partida começa. Dispara, o servidor discorda e sofre rubber-banding três metros para trás. Nem o contador do jogo nem um teste de velocidade lhe dizem para onde vão esses milissegundos. Entre a sua máquina e o servidor de jogo estão o router de casa, o seu operador, uma ou duas redes de trânsito e a rede do próprio anfitrião. O atraso, e o jitter por trás dos picos de lag, vem de um deles.
Um traceroute mostra cada um desses saltos com a latência, o jitter e a perda de pacotes, e identifica a rede a que pertence. Executado a partir do seu próprio PC (tracert no Windows, mtr no macOS ou Linux), mostra a sua linha: o seu Wi-Fi, o seu operador. O TraceMapper executa-o a partir dos nossos servidores na Alemanha e em França ou de sondas em mais de 30 cidades: o caminho até ao servidor de jogo visto de fora de sua casa, num mapa. Lado a lado, os dois dizem-lhe se o atraso está do seu lado, num ponto de peering ou no anfitrião. Um traceroute não baixa o ping por si só; diz-lhe que solução vale a pena tentar.
Encontrar o salto que acrescenta latência
Execute tracert ou mtr a partir do seu PC até ao endereço do servidor (dos registos do jogo ou da lista da plataforma) e leia a latência do primeiro salto ao último: procure o primeiro aumento que se mantém. O salto 1 é o router de casa: acima de 5 ms em Ethernet, ou de 20 ms com jitter visível, o problema está dentro de casa, quase sempre no Wi-Fi. Os saltos 2 a 4 são do operador; um aumento aí às 21h que desaparece às 8h é congestionamento de hora de ponta. Um aumento exatamente onde o ASN muda é a passagem para um trânsito ou para o anfitrião. 40 ms constantes desde a mudança de ASN até ao fim são distância: a resposta é outra região. Um traçado do TraceMapper parte do nosso centro de dados ou de uma sonda: os primeiros saltos não são os seus, leia-o a partir da primeira mudança de rede.
O jitter e a perda, não o ping médio, causam rubber-banding
Um ping de 60 ms com 2 ms de jitter parece fluido; 40 ms com 30 ms de jitter parecem avariados, porque o jogo prevê a sua posição entre pacotes e corrige-a quando chegam atrasados. Leia a coluna do jitter salto a salto: o primeiro salto onde ele sobe é o seu segmento instável. A perda funciona da mesma forma, com uma armadilha. Um salto intermédio com 20% de perda enquanto o destino mostra 0% é um router a despriorizar as respostas ao traceroute, não pacotes de jogo perdidos. A perda real começa num salto e persiste até ao último. Execute o traceroute em hora de ponta e fora dela e compare os dois lado a lado; a diferença diz-lhe se enfrenta congestionamento ou um problema permanente de caminho.
Wi-Fi ou cabo, escolha de região e a prova a enviar
Execute tracert uma vez em Wi-Fi e outra no cabo, mesmo alvo, e compare: se o jitter do salto 1 cair de 15 ms para menos de 1 ms, nenhuma definição do router vence um cabo. Depois trace duas ou três regiões de servidores no TraceMapper a partir da sonda mais próxima: a lista do jogo raramente reflete o caminho real, e uma região próxima pode passar por um ponto de troca distante. Se o seu próprio tracert se degrada a partir dos saltos do operador enquanto o caminho do TraceMapper a partir de uma sonda do seu país se mantém limpo, o problema está na sua linha: exporte o traçado do TraceMapper (um PDF datado) e anexe o seu tracert ao pedido de suporte. Se ambos se degradam no mesmo salto distante, está para lá do operador. Uma VPN merece um teste quando o problema é peering, porque muda onde o tráfego é entregue; nada faz contra a distância ou o Wi-Fi.
Ler um traceroute: uma partida que tem lag todas as noites
Exemplo didático, não uma medição real. Um jogador em Lyon executa tracert até um servidor em Frankfurt. O salto 1, o router de casa, responde em 1 ms sem jitter. Os saltos 2 a 4, na rede do operador, ficam entre 8 e 11 ms. No salto 5 o ASN muda para um trânsito: 14 ms. O salto 6 marca 68 ms com 25 ms de jitter, e todos os saltos até ao servidor ficam perto dos 70 ms. O aumento persiste até ao fim, por isso é real, e começa logo após a passagem. Um traçado do TraceMapper para o mesmo servidor a partir de uma sonda em Paris chega lá em 12 ms por outro trânsito: o servidor está bem, o elo fraco é o trânsito a quem o operador do jogador entrega o tráfego. O mesmo tracert às 7h dá 18 ms: congestionamento de hora de ponta. Opções: uma região servida por outro trânsito, um teste com VPN ou um pedido ao operador com os dois traçados.
Ferramentas a usar antes e depois do traceroute
O Ping envia uma rajada de sondas e devolve mínimo, média, jitter e perda; use-o primeiro para confirmar que o pico está a acontecer agora, depois trace. O DNS Lookup diz para que endereço resolve o nome do servidor, pois alguns jogos usam endereços diferentes por região. O WHOIS e o IP Reputation identificam a quem pertence o endereço de um servidor, útil quando um servidor comunitário afinal está noutro continente. O Port Check confirma se a porta do jogo está acessível quando se suspeita de firewall ou de CGNAT.