Pérdida en el tramo inalámbrico Wi-Fi / cellular link loss
ID de la causa rt-wireless · Responsable principal Externo (Externo) · También Infraestructura de servidores (Equipo de infraestructura), Desarrollo de servidor (Equipo de desarrollo), Desarrollo de cliente (Equipo de desarrollo)
El Wi-Fi y las redes móviles reintentan varias veces la transmisión en el tramo inalámbrico y, si aun así no lo consiguen, descartan el paquete. TCP vuelve a enviar ese paquete bastante después.
Por qué La señal es débil o hay muchas interferencias, y las transmisiones en el tramo inalámbrico fallan una tras otra → Efecto Al superar el límite de reintentos del dispositivo inalámbrico (normalmente de unos pocos a algo más de diez), el paquete se descarta → En pantalla Congelamiento mientras dura la espera de la retransmisión TCP; los paquetes siguientes aguardan en el búfer de recepción y luego llega todo en cámara rápida
De vez en cuando, al azar, Al moverse o cambiar de zona
Responsable
Responsable principal Externo (Externo) · También Infraestructura de servidores (Equipo de infraestructura), Desarrollo de servidor (Equipo de desarrollo), Desarrollo de cliente (Equipo de desarrollo)
Tareas (Equipo de desarrollo)
Servidor: activar TCP_NODELAY (con Nagle activado, RACK no tiene paquetes posteriores con los que detectar la pérdida), no acumular las actualizaciones de estado mientras la retransmisión bloquea el envío y mandar solo la más reciente (limitar con TCP_NOTSENT_LOWAT lo que se acumula en el kernel). Cliente: activar TCP_NODELAY (las pérdidas en el sentido de los inputs del jugador las recupera el SO del cliente), mostrar en pantalla el estado de la red cuando se concentran las pérdidas o el ping se dispara.
Tareas (Equipo de infraestructura)
Acelerar la recuperación de pérdidas con RACK-TLP (el servidor no puede evitar la pérdida inalámbrica; lo único que puede hacer es recuperarse antes), comprobar que no se hayan cambiado los valores predeterminados de los Linux recientes: net.ipv4.tcp_recovery=1 (RACK) y net.ipv4.tcp_early_retrans=3 (TLP).
Tareas (Externo)
Indicar a los jugadores que usen conexión por cable o las bandas de 5 GHz o 6 GHz, y que cambien la ubicación o el canal del router.
Cifras de referencia
Con un 1% de pérdida inalámbrica, desaparece 1 de cada 100 paquetes del juego. Si se reciben 10 por segundo, hay un tirón aproximadamente cada 10 segundos. Sin RACK-TLP, cada pérdida detiene la conexión durante un RTO (ping + 200 ms o más).
En el gráfico
Alto solo en algunos · Tasa de retransmisión por conexión, RTT (ping) por conexión
Dónde mirar
Desde la computadora del jugador, enviar cientos de pings a la dirección del router (gateway) y al servidor del juego, comparar la pérdida y la dispersión de la latencia, y repetir la medición con cable o con datos móviles. En el servidor, retrans y rtt (media/desviación) de la conexión de ese jugador con ss -ti
Se confirma si
El ping al router ya muestra pérdida o latencia irregular, que desaparece al pasar a cable. Desde el servidor, solo la conexión de ese jugador tiene retrans y desviación del RTT altas
Se descarta si
Si hasta el router todo está limpio y la pérdida empieza más allá, apunta al ISP o a la ruta (“Desbordamiento de la cola en el cuello de botella (pérdida por congestión)”, “Cambio de ruta o ruta ECMP defectuosa”). Si empeoran a la vez varios jugadores del mismo ISP, revisar primero el tramo del ISP
Se verifica con
En el entorno del jugador
Para saber más
Los reintentos del dispositivo inalámbrico generan jitter (varios ms por reintento), y solo hay pérdida cuando se supera el límite de reintentos. Por eso, a medida que empeora la calidad de la señal, los síntomas crecen en este orden: “jitter → congelamientos ocasionales → congelamientos frecuentes”. Al pasar de un router (AP) a otro (roaming) se pueden perder paquetes seguidos durante un intervalo de decenas de ms a varios segundos. Las redes móviles hacen muchos reintentos en el tramo con la estación base, así que el problema suele verse como picos de latencia de cientos de ms, y la pérdida es menos frecuente.
net/wireless/core.cLinux kernel Límite de reintentos predeterminado de la pila inalámbrica de Linux: 7 para tramas cortas y 4 para tramas largas (dot11ShortRetryLimit, dot11LongRetryLimit)
Wi-Fi roaming support in Apple devicesApple Al cambiar de AP no se pueden enviar datos hasta que termina la autenticación con el nuevo AP, y en entornos 802.1X puede tardar unos segundos
IP SysctlLinux kernel tcp_recovery: 0x1 por defecto (RACK); tcp_early_retrans: 3 por defecto (TLP activado); TCP_NOTSENT_LOWAT y tcp_notsent_lowat limitan la cantidad de datos aún sin enviar
tcp(7) — Linux manual pageLinux man-pages TCP_NODELAY desactiva el algoritmo de Nagle y envía enseguida incluso los datos pequeños