RTO mal ajustado al entorno RTO min too low or too high
ID de la causa rt-rto-setting · Responsable principal Infraestructura de servidores (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo)
Si se baja demasiado el RTO mínimo, cualquier pequeño retraso provoca retransmisiones espurias; y el valor predeterminado (200 ms) es demasiado largo para un juego, así que cada pérdida detiene la conexión mucho tiempo.
Por qué Se baja mucho el RTO mínimo pensando en el centro de datos, o se deja el valor predeterminado tal cual en los tramos de internet → Efecto Si es bajo, hay avalanchas de retransmisiones con cualquier pico de latencia; si es alto, cada pérdida implica una espera larga → En pantalla Con el valor predeterminado, cada pérdida provoca un congelamiento de cientos de ms seguido de cámara rápida; si se baja demasiado, los congelamientos se acortan, pero las retransmisiones espurias se disparan y desperdician el enlace
Responsable principal Infraestructura de servidores (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo)
Tareas (Equipo de desarrollo)
Con Linux 6.15 o posterior, estudiar bajar el máximo del RTO en las conexiones del juego con TCP_RTO_MAX_MS (como también se acorta el tiempo hasta abandonar la conexión, fijar a la vez con TCP_USER_TIMEOUT cuándo se da por desconectada), bajar el RTO mínimo solo en las conexiones internas entre servidores con la opción de socket TCP_RTO_MIN_US (6.15 o posterior), estudiar la opción de socket TCP_THIN_LINEAR_TIMEOUTS para que los RTO seguidos no se dupliquen, solo en las conexiones del juego.
Tareas (Equipo de infraestructura)
Bajar rto_min por ruta solo para las conexiones internas entre servidores, mantener el valor predeterminado en los tramos de internet y compensar con RACK-TLP y la configuración para thin streams (tcp_thin_linear_timeouts).
Cifras de referencia
En Linux, RTO = tiempo de ida y vuelta + max(200 ms, desviación del RTT × 4). Se duplica con cada fallo, hasta un máximo de 120 segundos. Desde Linux 6.15, TCP_RTO_MAX_MS permite bajar ese máximo hasta 1 segundo.
En el gráfico
Siempre alto · RTO por conexión, RTO espurios
Dónde mirar
Configuración del RTO mínimo del servidor (rto_min en ip route show; desde Linux 6.11, sysctl net.ipv4.tcp_rto_min_us), rto y rtt de ss -ti, e incremento de TcpExtTCPSpuriousRTOs en nstat
Se confirma si
En el servidor con el mínimo bajado, el rto de las conexiones de internet está pegado al rtt y TcpExtTCPSpuriousRTOs sube mucho. Con el valor predeterminado, el rto de las conexiones del juego supera al rtt en 200 ms o más, y cada pérdida detiene la conexión ese tiempo
Se descarta si
Si el rto sigue el cálculo predeterminado (unos rtt + 200 ms), hay pocos RTO espurios y aun así las pausas son especialmente largas, apunta a pérdidas seguidas o al método de recuperación (“Recuperación lenta en thin streams”, “Eliminación de opciones TCP en dispositivos intermedios”)
Se verifica con
Con herramientas de infraestructura (no hace falta código del juego)
Fuentes
RFC 6298: Computing TCP's Retransmission TimerIETF RTO = SRTT + max(G, 4·RTTVAR); recomienda un mínimo de 1 segundo; se duplica con cada fallo; si se fija un máximo, de al menos 60 segundos
include/net/tcp.hLinux kernel En Linux, TCP_RTO_MIN es 200 ms y TCP_RTO_MAX, 120 segundos
net/ipv4/tcp_input.cLinux kernel En Linux, RTO = SRTT + rttvar, y rttvar no baja del RTO mínimo (200 ms por defecto)
IP SysctlLinux kernel tcp_rto_min_us: 200000 por defecto (tienen prioridad la opción de ruta rto_min y la opción de socket TCP_RTO_MIN_US); tcp_rto_max_ms: 1,000–120,000 (120,000 por defecto); tcp_thin_linear_timeouts