Libro blanco del lag en juegos › Buscar por síntoma
Input lag: 76 causas y sus responsables
También se dice: responde tarde, va pesado, los controles no responden bien
Abrir en la guía de síntomas interactiva →
Pasa un tiempo desde que presionas hasta que ves el resultado. La imagen en sí puede verse fluida.
Presionas el botón de la habilidad y se activa 0.2–0.5 s después. Las acciones que esperan confirmación del servidor, como recoger objetos, hablar o intercambiar, van lentas.
El tiempo de ida y vuelta (ping) es alto, o hay una cola acumulada en algún punto. Hay que revisar la distancia, la cola del router, Nagle (la función de TCP que junta paquetes pequeños antes de enviarlos) y las colas del servidor. Si el ping es bajo y aun así todo va pesado, hay que mirar tu PC (V-Sync, FPS bajos) o un diseño que espera la confirmación del servidor en cada acción (capítulo sobre modelos de netcode).
Causas de este síntoma
L1 Proceso del juego en el cliente
- Carga de renderizado de multitudes: Cuando cientos de jugadores entran en la misma pantalla, como en un asedio o un world boss, el costo de dibujarlos se vuelve inasumible. (Desarrollo de cliente (Equipo de desarrollo))
- Cuello de botella al procesar paquetes en el hilo principal: Si el cliente solo procesa una cantidad fija de paquetes recibidos por frame, cuando llegan muchos de golpe se acumulan y se van pasando una y otra vez al frame siguiente. (Desarrollo de cliente (Equipo de desarrollo))
- V-Sync y cola de renderizado: Los frames que dibuja la GPU se acumulan en una cola de varios frames y salen al ritmo del monitor; mientras tanto, el input se retrasa. (Desarrollo de cliente (Equipo de desarrollo))
L2 SO y dispositivo del cliente
- Ahorro de energía y thermal throttling: El modo batería de una computadora portátil, el modo de ahorro de energía del teléfono o el calor del dispositivo reducen la velocidad de la CPU y la GPU. Lo característico del calor es que al principio todo va bien y la lentitud llega al cabo de un rato. (Externo (Externo))
- Otras apps del dispositivo que ocupan el ancho de banda: Si en la misma computadora hay una sincronización en la nube, una descarga grande o el parche de un juego, los paquetes del juego esperan en la cola. (Externo (Externo))
- Latencia de pantalla, dispositivos de entrada y generación de frames: Si el ping es normal pero el control se siente pesado, puede que el procesamiento de imagen del televisor, un controlador inalámbrico o la generación de frames estén añadiendo latencia entre el input y la pantalla. (Externo (Externo))
L3 Red doméstica
- Canal Wi-Fi saturado: En sitios con decenas de routers, como un edificio de apartamentos, hay que compartir el mismo canal y esperar turno para transmitir. (Externo (Externo))
- Bufferbloat (cola del router): Cuando alguien de la familia sube un video o descarga un archivo grande, se acumulan en la cola del router cientos de ms de paquetes, y los paquetes del juego también esperan detrás. (Externo (Externo))
- Retraso en el cambio de estado RRC (ahorro de energía de la radio móvil): Si no hay comunicación durante un rato, el teléfono pasa la conexión de radio a un estado de bajo consumo, y al llegar el siguiente paquete tarda en volver a activarla. (Desarrollo de cliente (Equipo de desarrollo))
L4 Ruta por internet
- Retardo de propagación (distancia física): Ni siquiera la luz pasa de unos 200,000 km por segundo dentro de la fibra óptica. Un servidor lejano siempre responde tarde, por muy bueno que sea. (Infraestructura de servidores (Equipo de infraestructura))
- Internet satelital (órbita baja y geoestacionaria): En internet satelital la señal tiene que ir al espacio y volver. Con satélites geoestacionarios, solo la ida y vuelta ya supera los 0.5 segundos. Los satélites de órbita baja como Starlink suelen ser rápidos, pero cuando se reasigna la ruta la latencia oscila y la conexión puede cortarse un instante. (Externo (Externo))
- Enrutamiento con rodeos: Por los acuerdos de interconexión entre ISP, el tráfico hacia un servidor cercano puede dar un rodeo por un lugar lejano. (Infraestructura de red (Equipo de infraestructura))
- Fallos en cables submarinos y enlaces internacionales: Cuando se corta un cable submarino, el tráfico da un rodeo por rutas lejanas durante semanas (a veces meses) hasta que se repara, y los enlaces que quedan se saturan. (Externo (Externo))
- Limitación de velocidad y gestión del tráfico del ISP: En los planes que limitan la velocidad al superar el consumo de datos o que gestionan cierto tipo de tráfico, los paquetes se retrasan o se descartan. (Externo (Externo))
- Paso por una VPN o un acelerador de juegos: Con una VPN o un acelerador de juegos activado, los paquetes pasan por los servidores intermedios (relay) de esa empresa. Si el relay está lejos o saturado, la conexión acaba siendo más lenta que sin él. (Externo (Externo))
L5 Equipos de red del centro de datos
- Desvío por la protección DDoS y falsos positivos: Para frenar un ataque, el tráfico se desvía a un centro de depuración (scrubbing), lo que alarga la ruta, y a veces se bloquea a jugadores legítimos tomándolos por atacantes. (Infraestructura de red (Equipo de infraestructura))
- Saturación del enlace del centro de datos: Cuando la distribución de parches, el envío de logs o las copias de seguridad usan el mismo enlace que el juego, el enlace se llena. (Infraestructura de red (Equipo de infraestructura))
L6 Tarjeta de red del servidor
- Interrupciones de la NIC concentradas en un solo núcleo: Si la NIC envía las interrupciones de llegada de paquetes a un solo núcleo de CPU, ese núcleo se convierte en el cuello de botella. (Infraestructura de servidores (Equipo de infraestructura))
- Coalescencia de interrupciones excesiva: Para reducir la carga de la CPU, la NIC junta paquetes y avisa de una sola vez, así que los paquetes se retrasan lo que dura esa espera. (Infraestructura de servidores (Equipo de infraestructura))
- Saturación del ancho de banda de la NIC: Si una tarjeta de 1 Gbps o 10 Gbps se usa hasta su límite, la cola de transmisión crece y al final los paquetes se descartan. (Desarrollo de servidor (Equipo de desarrollo))
- Retraso por agrupación en GRO/LRO: Son funciones que agrupan varios paquetes en uno para reducir la carga de la CPU. Según la configuración, un paquete pequeño del juego puede esperar un momento al siguiente paquete con el que agruparse. (Infraestructura de servidores (Equipo de infraestructura))
L7 SO del servidor (kernel)
- Picos de latencia por la gestión de energía del servidor (C-states, escalado de frecuencia): Los núcleos de CPU inactivos entran en estados de ahorro de energía profundos (C-states) y bajan su frecuencia para ahorrar electricidad. Cuando llega un paquete o vence un temporizador, despertar y subir la frecuencia lleva tiempo, y eso añade latencia al procesar paquetes pequeños. (Infraestructura de servidores (Equipo de infraestructura))
- Cambios de rendimiento tras actualizar el SO, el kernel, los drivers o el firmware: El código del juego no cambia, pero el servidor se vuelve más lento después de actualizar el SO, el kernel, los drivers o el firmware. Las actualizaciones pueden cambiar valores predeterminados, el planificador, las mitigaciones de vulnerabilidades de la CPU (mitigations) o el comportamiento de los drivers. (Infraestructura de servidores (Equipo de infraestructura))
L8 Sockets y protocolos
- Algoritmo de Nagle + ACK retardado: El algoritmo de Nagle, que junta paquetes pequeños antes de enviarlos, y el ACK retardado, que envía los ACK con retraso, se bloquean mutuamente, y cada mensaje escrito en varias partes se retrasa entre 40 y 200 ms. (Desarrollo de servidor (Equipo de desarrollo))
- Slow start tras inactividad: Si una conexión TCP pasa un rato inactiva, vuelve a reducir la ventana de congestión (lo que puede enviar de una vez), y cuando de repente tiene que enviar muchos datos, los envía en varias tandas. (Infraestructura de servidores (Equipo de infraestructura))
- Caída brusca del ritmo de envío por el control de congestión: TCP interpreta la pérdida como señal de congestión y reduce la velocidad de envío entre un 30 y un 50%. Reacciona igual ante la pérdida en el Wi-Fi. (Infraestructura de servidores (Equipo de infraestructura))
- Modelo de E/S bloqueante: En un modelo en el que el hilo no puede hacer nada más mientras espera a un socket, todo se vuelve más lento a medida que aumentan los jugadores. (Desarrollo de servidor (Equipo de desarrollo))
L9 Proceso del juego en el servidor
- Tick que excede su presupuesto: Si el trabajo de un tick supera su presupuesto, el intervalo de tick del servidor se alarga y toda esa zona va más lenta o va a tirones. (Desarrollo de servidor (Equipo de desarrollo))
- Explosión de broadcast: Si el movimiento de un jugador se envía a todos los que lo ven, las actualizaciones que hay que enviar crecen con el cuadrado del número de jugadores reunidos. (Desarrollo de servidor (Equipo de desarrollo))
- Sobrecarga de una zona de un solo hilo (hotspot): En un diseño con un hilo por zona, si la gente se concentra en un lugar, solo ese núcleo llega al 100%. (Desarrollo de servidor (Equipo de desarrollo))
- Contención de locks: Si varios hilos esperan un mismo lock para escribir los mismos datos, por más hilos que se añadan, solo se ejecuta uno a la vez. (Desarrollo de servidor (Equipo de desarrollo))
- Acumulación en la cola de mensajes: Si las solicitudes llegan más rápido de lo que se procesan y se acumulan en la cola, las últimas se procesan varios segundos después o se descartan. (Desarrollo de servidor (Equipo de desarrollo))
- Costo de serialización y compresión: Convertir a bytes y comprimir los datos que se van a enviar también consume CPU, y con mucha gente este costo se dispara. (Desarrollo de servidor (Equipo de desarrollo))
- Agotamiento del pool de hilos: Si todos los hilos de trabajo que procesan tareas quedan atados a trabajos lentos, las solicitudes nuevas esperan indefinidamente. (Desarrollo de servidor (Equipo de desarrollo))
- Combate concentrado en un solo objetivo (world boss): Cuando cientos de jugadores golpean a la vez a un mismo jefe, el cálculo de ese único jefe se concentra en un punto y la información de cada golpe se envía a todos los que lo ven. (Desarrollo de servidor (Equipo de desarrollo))
- Avalancha de spawns al entrar en una zona concurrida: Al teletransportarse a un pueblo lleno de gente, el servidor tiene que enviar de golpe la apariencia, el equipamiento y el estado de los cientos de jugadores que ahora son visibles. (Desarrollo de servidor (Equipo de desarrollo))
- Acumulación de entidades (objetos e invocaciones sin limpiar): Si los objetos tirados en el suelo, las invocaciones y los temporizadores terminados que deberían desaparecer no se limpian y se acumulan, el trabajo de cada tick crece cuanto más tiempo lleva encendido el servidor. (Desarrollo de servidor (Equipo de desarrollo))
- Cambio del patrón de tráfico tras un parche: Si nuevo contenido, efectos o campos sincronizados aumentan el tamaño y la frecuencia de los paquetes, un servidor que iba bien empieza a chocar tras el parche con los límites de MTU, ancho de banda o número de paquetes. (Desarrollo de servidor (Equipo de desarrollo))
L11 Disco
- Avalancha de fsync: Pedir que los datos se escriban en disco “con garantía” cuesta, según el disco, de 0.1 ms a decenas de ms por llamada, y si se acumulan las solicitudes, la cola se alarga. (Desarrollo de servidor (Equipo de desarrollo))
- Agotamiento de los créditos de ráfaga del disco en la nube: Algunos discos en la nube y las instancias pequeñas tienen créditos de ráfaga para rendir por encima de su nivel base durante un rato; si la actividad intensa se alarga y los créditos se agotan, la velocidad cae de golpe. (Infraestructura de servidores (Equipo de infraestructura))
- Límite de IOPS y saturación de la cola: Cuando se supera el número de solicitudes por segundo que el disco puede procesar, la cola se alarga y la latencia se dispara. (Infraestructura de servidores (Equipo de infraestructura))
- Copias de seguridad, compresión y escaneos: Cuando una copia de seguridad de madrugada, la compresión de logs o un escaneo de seguridad acaparan el disco, las lecturas y escrituras del servidor del juego se retrasan. (Infraestructura de servidores (Equipo de infraestructura))
- Latencia de búsqueda (seek) en HDD: En un HDD el cabezal tiene que moverse sobre el plato (búsqueda, seek), así que cada lectura o escritura de datos dispersos tarda cerca de 10 ms. (Infraestructura de servidores (Equipo de infraestructura))
L12 Base de datos
- Consultas sin índice: Sin índice, encontrar las filas que cumplen una condición obliga a leer la tabla entera (escaneo completo). (Desarrollo de servidor (Equipo de desarrollo))
- Contención de bloqueos en una fila caliente: Si todos intentan modificar la misma fila (el almacén del gremio, un objeto popular de la casa de subastas, un contador global del servidor), el bloqueo solo lo consigue uno cada vez. (Desarrollo de servidor (Equipo de desarrollo))
- Deadlock en la BD: Si dos transacciones (operaciones de BD que se procesan como un solo bloque) esperan cada una la fila que bloqueó la otra, la BD cancela una de ellas a la fuerza. (Desarrollo de servidor (Equipo de desarrollo))
- Agotamiento del pool de conexiones: El número de conexiones abiertas con la BD es fijo, así que si las consultas lentas ocupan las conexiones, las demás solicitudes esperan. (Desarrollo de servidor (Equipo de desarrollo))
- Checkpoint y volcado del log: Cuando la BD vuelca de golpe al disco, de forma periódica, los cambios que tiene en memoria, las consultas se ralentizan. (Infraestructura de BD (Equipo de infraestructura))
- Caché fría (justo después de reiniciar): Al reiniciar la BD, su caché en memoria está vacía, y durante un tiempo todas las consultas leen del disco. (Infraestructura de BD (Equipo de infraestructura))
- Avalancha de inicios de sesión y consultas N+1: Si cargar un personaje requiere decenas de consultas separadas, decenas de miles de inicios de sesión simultáneos se convierten en millones de consultas. (Desarrollo de servidor (Equipo de desarrollo))
- Procesos batch masivos: Calcular rankings, enviar correo del juego en masa o limpiar datos antiguos con el servicio en marcha acapara bloqueos y disco. (Desarrollo de servidor (Equipo de desarrollo))
- Estampida de caché: Si la caché de unos datos populares caduca a la vez, miles de solicitudes se lanzan de golpe contra la BD. (Desarrollo de servidor (Equipo de desarrollo))
- Transacciones abiertas durante mucho tiempo: Si una transacción permanece abierta mucho tiempo, sigue reteniendo sus bloqueos y la BD no puede limpiar (purge) las versiones antiguas de los datos, así que todo se vuelve cada vez más lento. (Desarrollo de servidor (Equipo de desarrollo))
- Comandos lentos en Redis: Redis procesa los comandos de uno en uno, así que un solo comando lento bloquea todas las solicitudes que vienen detrás. (Desarrollo de servidor (Equipo de desarrollo))
- Consultas lentas por un cambio en el plan de ejecución: Aunque el código no cambie, si la BD cambia la forma de procesar una consulta (el plan de ejecución), una consulta que ayer tardaba 2 ms hoy tarda cientos de ms. (Infraestructura de BD (Equipo de infraestructura))
- Bloqueos por cambios de esquema (DDL) en producción: Si se añade una columna o un índice a una tabla con el servicio en marcha, un bloqueo que solo se necesita durante un instante puede dejar esperando a todas las solicitudes que usan esa tabla. (Infraestructura de BD (Equipo de infraestructura))
L13 Arquitectura y operación de servidores
- Paso por un gateway o proxy: Si se pone un servidor intermedio entre el cliente y el servidor del juego, cada paso por él suma tiempo de procesamiento y ese servidor se convierte en un punto único de fallo. (Desarrollo de servidor (Equipo de desarrollo))
- Fallo en cascada: Cuando un servicio se vuelve lento, los servidores que lo llaman se quedan bloqueados esperando su respuesta y hasta funciones sin relación se detienen. (Desarrollo de servidor (Equipo de desarrollo))
- Despliegues y reinicios: Si al reiniciar un servidor para actualizarlo no se trasladan sus conexiones, los jugadores que estaban en él se desconectan, y los guardados justo antes del cierre y las reconexiones llegan todos de golpe. (Desarrollo de servidor (Equipo de desarrollo))
- Exceso de macros y bots: Los bots envían solicitudes con mucha más frecuencia que una persona y acaparan la capacidad de procesamiento del servidor. (Desarrollo de servidor (Equipo de desarrollo))
- Errores de matchmaking y asignación de región: Si a un jugador se le asigna un servidor de una región lejana cuando hay una cercana, tiene siempre el ping alto aunque su conexión esté bien. (Desarrollo de servidor (Equipo de desarrollo))
Diseño del netcode
- Feedback solo tras la respuesta del servidor (solicitud-respuesta): Al presionar un botón no hay animación ni sonido hasta que llega la respuesta del servidor. El ping se convierte directamente en el tiempo de respuesta. (Desarrollo de cliente (Equipo de desarrollo))
- Protocolo con muchas idas y vueltas secuenciales (chatty): Si una sola acción necesita varias idas y vueltas al servidor en secuencia, el ping se multiplica por ese número. (Desarrollo de servidor (Equipo de desarrollo))
- Sin búfer de inputs para habilidades: Si no se puede presionar la siguiente habilidad hasta que el servidor confirme que terminó la anterior, cada combo arrastra un tiempo de ida y vuelta. (Desarrollo de cliente (Equipo de desarrollo))
- Ventanas de tiempo cortas que el ping consume: Si el tiempo para reaccionar es corto, como en las esquivas, los parries o los bloqueos, el ping consume ese margen y aparecen ataques imposibles de evitar. (Desarrollo de servidor (Equipo de desarrollo))
- Espera al jugador más lento en lockstep: En una arquitectura en la que todos calculan juntos el mismo turno, si el input de uno llega tarde, todos esperan. (Desarrollo de servidor (Equipo de desarrollo))
- Doble espera de tick: Si las solicitudes se acumulan hasta el siguiente tick para procesarlas y el resultado también se envía en el tick posterior, el intervalo de tick se suma dos veces. (Desarrollo de servidor (Equipo de desarrollo))
Problemas que solo afectan a algunos
- Tamaño del búfer de inputs de cada jugador: Si el servidor guarda un poco los inputs de cada jugador y los saca de uno en uno por tick, los demás lo ven fluido, pero el momento en que el servidor confirma las acciones de ese jugador se retrasa en la misma medida. (Desarrollo de servidor (Equipo de desarrollo))
- Un miembro del grupo con lag y las mecánicas del jefe: En las mecánicas de raid en las que todos deben reaccionar juntos en un momento preciso, la reacción tardía de una sola persona con lag hace fracasar a todo el grupo. (Desarrollo de servidor (Equipo de desarrollo))
- Personaje con datos sobredimensionados: Un personaje con miles de objetos o correos acumulados, o con listas de amigos o de bloqueados y buffs fuera de lo normal, tiene varias veces más datos que cargar al conectarse, que guardar y que anunciar a su alrededor. Va lento solo con ese personaje, sin importar la conexión. (Desarrollo de servidor (Equipo de desarrollo))
- Presupuesto de envío y prioridad por conexión: Si el servidor limita lo que envía a cada conexión y empieza por lo más cercano, la conexión con un límite bajo recibe tarde, o nunca, los NPC lejanos. (Desarrollo de servidor (Equipo de desarrollo))
Causas raíz de la retransmisión TCP
- Descarte de paquetes en el host del servidor receptor: Los paquetes llegan al servidor, pero se descartan porque se desborda el búfer circular de la NIC (el búfer donde se guardan un momento los paquetes que llegan) o porque se satura el núcleo que procesa la recepción en el kernel. (Infraestructura de servidores (Equipo de infraestructura))
- Retransmisiones espurias por picos de latencia: 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. (Externo (Externo))
- Retransmisiones rápidas espurias por reordenamiento de paquetes: Cuando los paquetes cambian de orden al pasar por varias rutas o por enlaces agregados, el receptor avisa con ACK duplicados de que “falta un paquete”, y el emisor reenvía paquetes que estaban bien. (Infraestructura de red (Equipo de infraestructura))
- ACK retrasados o perdidos (subida saturada): Los datos llegaron bien, pero si el ACK que confirma la recepción se retrasa o se pierde en una cola de subida llena, el emisor lo da por perdido y retransmite. (Externo (Externo))
- RTO mal ajustado al entorno: 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. (Infraestructura de servidores (Equipo de infraestructura))
Ver la guía de síntomas interactiva