Retransmisiones espurias por picos de latencia Spurious RTO from delay spikes
ID de la causa rt-spurious-delay · Responsable principal Externo (Externo) · También Infraestructura de servidores (Equipo de infraestructura), Desarrollo de cliente (Equipo de desarrollo)
El paquete no se pierde; solo llega muy tarde por un momento. Pero si ese retraso supera el RTO, el emisor lo da por perdido y lo retransmite.
Por qué Por bufferbloat, el ahorro de energía del Wi-Fi, un cambio de estado de la radio móvil o una pausa de la máquina virtual, la latencia sube de golpe a cientos de ms → Efecto El RTO expira antes y se retransmite, y el original también llega enseguida (el receptor lo recibe duplicado) → En pantalla El congelamiento y la cámara rápida se deben al propio pico de latencia. La retransmisión espuria apenas los alarga, pero sube las métricas de retransmisión y se confunde con pérdida
Responsable principal Externo (Externo) · También Infraestructura de servidores (Equipo de infraestructura), Desarrollo de cliente (Equipo de desarrollo)
Tareas (Equipo de desarrollo)
En clientes con Android 10 o posterior, pedir durante la partida el modo Wi-Fi de baja latencia (bloqueo de Wi-Fi WIFI_MODE_FULL_LOW_LATENCY, que solo se aplica con la pantalla encendida y el juego en primer plano) para reducir los picos de latencia que causa el ahorro de energía.
Tareas (Equipo de infraestructura)
Evitar las instancias de rendimiento ampliable (burstable), no bajar demasiado el RTO mínimo, mantener F-RTO y las marcas de tiempo (tcp_frto, tcp_timestamps), mirar las métricas de retransmisión junto con TCPSpuriousRTOs y TCPDSACKRecv de nstat para no confundirlas con pérdida.
Tareas (Externo)
Para reducir los propios picos de latencia, indicar a los jugadores que usen SQM en el router y desactiven el ahorro de energía del Wi-Fi.
Cifras de referencia
Linux detecta los RTO espurios con F-RTO y a veces deshace la reducción del ritmo de envío. Se comprueba con TCPSpuriousRTOs (veces que un RTO se juzgó espurio) y TCPDSACKRecv (veces que el receptor avisó de que “eso ya lo tenía”) de nstat.
En el gráfico
Picos aleatorios · RTT (ping), RTO espurios
Dónde mirar
Ejecutar nstat cada minuto y ver juntos los incrementos de TcpExtTCPTimeouts (expiraciones del RTO), TcpExtTCPSpuriousRTOs, TcpExtTCPDSACKRecv y TcpExtTCPLostRetransmit. Con una captura de paquetes, usar el filtro de Wireshark tcp.analysis.spurious_retransmission
Se confirma si
Cuando suben los RTO, también suben TcpExtTCPSpuriousRTOs o TcpExtTCPDSACKRecv, y a la misma hora el RTT salta a cientos de ms. En la captura del receptor llegan tanto el original como la retransmisión
Se descarta si
Si TcpExtTCPSpuriousRTOs y DSACK no cambian, pero sube TcpExtTCPLostRetransmit (se pierde también lo retransmitido), es pérdida real. Si el RTT no salta y solo hay muchos DSACK de forma constante, apunta a “Retransmisiones rápidas espurias por reordenamiento de paquetes”
Se verifica con
Con herramientas de infraestructura (no hace falta código del juego)
SNMP counterLinux kernel TcpExtTCPSpuriousRTOs (RTO espurios detectados por F-RTO), TcpExtTCPDSACKRecv (DSACK recibidos), TcpExtTCPLostRetransmit (veces que SACK indicó que un paquete retransmitido se volvió a perder)
IP SysctlLinux kernel tcp_frto activado por defecto (ventajoso en redes inalámbricas con un RTT inestable), tcp_timestamps: 1 por defecto
WifiManagerAndroid (Google) WIFI_MODE_FULL_LOW_LATENCY (API 29, Android 10): bloqueo de Wi-Fi de baja latencia que solo se aplica con conexión a un AP, la pantalla encendida y la app en primer plano
net/ipv4/proc.cLinux kernel Nombres de contador que muestra nstat: TCPTimeouts, TCPSpuriousRTOs, TCPDSACKRecv y TCPLostRetransmit
net/ipv4/tcp_timer.cLinux kernel TCPTimeouts sube cuando expira el temporizador de retransmisión (RTO)