Perda no trecho sem fio Wi-Fi / cellular link loss
ID da causa rt-wireless · Responsável principal Externo (Externo) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura), Desenvolvimento do servidor (Equipe de desenvolvimento), Desenvolvimento do cliente (Equipe de desenvolvimento)
O Wi-Fi e a rede móvel tentam retransmitir algumas vezes no trecho sem fio e, se ainda assim não conseguem, descartam o pacote. O TCP só reenvia o pacote descartado bem mais tarde.
Por quê Sinal fraco ou muita interferência fazem as transmissões no trecho sem fio falharem várias vezes seguidas → Efeito Passado o limite de tentativas do equipamento sem fio (normalmente de algumas a pouco mais de dez), o pacote é descartado → Na tela Trava enquanto o TCP espera para retransmitir; os pacotes seguintes ficam esperando no buffer de recepção e depois chegam em avanço rápido
Aleatoriamente, de vez em quando, Em movimento ou ao trocar de mapa
Responsável
Responsável principal Externo (Externo) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura), Desenvolvimento do servidor (Equipe de desenvolvimento), Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Servidor: ligar o TCP_NODELAY (com o Nagle ligado, o RACK fica sem pacotes seguintes para usar na detecção de perda), enviar só a atualização de estado mais recente enquanto a retransmissão bloqueia o envio, sem acumular as anteriores (limitar com TCP_NOTSENT_LOWAT o volume acumulado no kernel). Cliente: ligar o TCP_NODELAY (as perdas no sentido dos comandos do jogador são recuperadas pelo SO do cliente), mostrar o estado da rede na tela quando as perdas se concentram ou o ping dispara.
O que fazer (Equipe de infraestrutura)
Acelerar a recuperação de perdas com RACK-TLP (o servidor não consegue evitar a perda no sem fio, só recuperar mais rápido), confirmar que os padrões do Linux recente, net.ipv4.tcp_recovery=1 (RACK) e net.ipv4.tcp_early_retrans=3 (TLP), não foram alterados.
O que fazer (Externo)
Orientar os jogadores a usar cabo, usar 5 GHz ou 6 GHz e mudar o roteador de lugar ou de canal.
Números de referência
Com 1% de perda no sem fio, 1 em cada 100 pacotes do jogo some. Recebendo 10 pacotes por segundo, há um engasgo a cada 10 segundos, em média. Sem RACK-TLP, cada perda deixa a conexão parada por um RTO (ping + pelo menos 200 ms).
No gráfico
Alto só em alguns · Taxa de retransmissão por conexão, RTT (ping) por conexão
Onde olhar
No PC do jogador, enviar centenas de pings para o endereço do roteador (gateway) e para o servidor do jogo e comparar a perda e a variação da latência; repetir com cabo ou com dados móveis. No servidor, ver retrans e rtt (média/desvio) da conexão desse jogador com ss -ti
Confirma se
O ping até o roteador já mostra perda ou latência oscilando, e o problema some no cabo. No servidor, só a conexão desse jogador tem retrans e desvio de RTT altos
Descarta se
Limpo até o roteador, com perda a partir dele: operadora ou caminho (“Estouro de fila no gargalo”, “Mudança de rota ou caminho ECMP com defeito”). Vários jogadores da mesma operadora piorando ao mesmo tempo: verificar primeiro o trecho da operadora
Como verificar
Verificação no ambiente do jogador
Saiba mais
As tentativas do equipamento sem fio geram jitter (alguns ms a cada tentativa), e só viram perda quando passam do limite de tentativas. Por isso, conforme a qualidade do sem fio piora, os sintomas crescem nesta ordem: “jitter → travamentos ocasionais → travamentos frequentes”. No momento em que o dispositivo passa de um ponto de acesso (AP) para outro (roaming), pode haver perdas seguidas por um período de dezenas de ms a alguns segundos. A rede móvel retransmite muito no trecho até a antena, então o problema costuma aparecer mais como picos de latência de centenas de ms do que como perda.
net/wireless/core.cLinux kernel Limites padrão de tentativas na pilha sem fio do Linux: 7 para frames curtos e 4 para frames longos (dot11ShortRetryLimit, dot11LongRetryLimit)
Wi-Fi roaming support in Apple devicesApple Ao trocar de AP, não dá para enviar dados até terminar a autenticação no novo AP; em ambientes 802.1X isso pode levar alguns segundos
IP SysctlLinux kernel tcp_recovery com padrão 0x1 (RACK), tcp_early_retrans com padrão 3 (TLP ligado); TCP_NOTSENT_LOWAT e tcp_notsent_lowat limitam a quantidade de dados ainda não enviados
tcp(7) — Linux manual pageLinux man-pages TCP_NODELAY desliga o algoritmo de Nagle e envia na hora até dados pequenos
include/net/tcp.hLinux kernel Valor mínimo do RTO: TCP_RTO_MIN = 200 ms
misc/ss.ciproute2 ss -ti mostra retrans: retransmissões em andamento/total acumulado de retransmissões e rtt: RTT/desvio do RTT (rttvar)