La suavidad no es FPS: tiempo de fotograma explicado en 2 minutos

Tiempo de fotograma en dos minutos (la única definición que importa)

FPS es una tasa: fotogramas por segundo. El tiempo de fotograma es una duración: cuánto tardó en producirse un solo fotograma.
Tu cerebro experimenta la duración más directamente que la tasa. Esa es toda la historia.
Todo lo demás son detalles y asignación de culpas.

Convertir FPS a tiempo de fotograma

Tiempo de fotograma (milisegundos) ≈ 1000 / FPS.

• 60 FPS → ~16.67 ms por fotograma
• 120 FPS → ~8.33 ms por fotograma
• 144 FPS → ~6.94 ms por fotograma
• 240 FPS → ~4.17 ms por fotograma

Si cada fotograma llega exactamente cada 6.94 ms a 144 FPS, el movimiento se ve extremadamente suave.
Si la mayoría de los fotogramas llegan cada 6–7 ms pero cada pocos segundos un fotograma tarda 40 ms, notarás un tirón.
El FPS promedio puede seguir siendo “alto”. Tu experiencia no lo será.

Qué significa realmente el gráfico de tiempo de fotograma

Un gráfico de tiempo de fotograma es simplemente una línea de tiempo de “qué tan tarde estuvo este fotograma”.
Línea plana bien. Picos mal. Patrones en sierra suelen ser problemas de pacing, encolamiento o sincronización.
Picos aleatorios dispersos suelen ser trabajo en segundo plano (compilación, IO, recolector de basura, antivirus, telemetría, overlays).

“Pero mi contador de FPS marca 140!” Claro. Si tomas 139 fotogramas a 7 ms y 1 fotograma a 40 ms, el promedio aún se ve bien.
Tus ojos recordarán la traición de 40 ms.

Broma #1: Los contadores de FPS son como los cuadros de mando trimestrales: excelentes para promediar el dolor hasta que alguien grita en la reunión.

Por qué FPS miente (y por qué tus ojos no)

FPS normalmente se toma por muestreo y se promedia en una ventana (a veces un segundo completo).
El tiempo de fotograma es por fotograma. Por fotograma es donde vive el stutter.
Si estás solucionando “se siente raro”, no quieres el promedio. Quieres los peores momentos.

Tres números que importan más que el FPS promedio

• 1% low FPS: el FPS en el 1% más lento de fotogramas. Mejor indicador de tirones que el promedio.
• 0.1% low FPS: el 0.1% más lento. Captura el problema de “una vez por minuto doy un tirón”.
• Percentil de tiempo de fotograma: por ejemplo, tiempo de fotograma al percentil 99. Eso es “qué tan malo es lo malo”.

Lo que realmente notas: la varianza

Los humanos detectan irregularidad. Un 60 FPS estable puede sentirse más suave que un 90–180 FPS que oscila salvajemente.
La “sensación” tiene mucho que ver con la consistencia del pacing: que el tiempo entre fotogramas sea uniforme.

Por qué “más FPS” puede empeorar la sensación

FPS sin límite puede saturar el hilo de render del CPU, crear colas más grandes e incrementar la latencia. Entonces obtienes:

• Más calor → throttling → picos periódicos en el tiempo de fotograma
• Más contención → jitter en el planificador del SO
• Más consumo energético → oscilaciones de boost de la GPU (especialmente en portátiles)
• Más rarezas en swapchain y sincronización → pacing irregular

El contador sube, el juego se siente peor y empiezas a cuestionarte a ti mismo. No lo hagas.
Limita el FPS a un valor sostenible y verás cómo se aplanan los tiempos de fotograma.

Datos e historia interesantes que realmente puedes usar

1. VSync se diseñó originalmente para eliminar el tearing, no por “suavidad”. Sincroniza la presentación con la frecuencia de refresco,
   pero puede introducir tirones si los fotogramas pierden la fecha límite y esperan un ciclo completo de refresco.
2. Los “1% lows” se popularizaron porque los promedios ocultaban el stutter. Los benchmarkers empezaron a reportar los bajos una vez que el hardware de alto FPS volvió
   el “promedio” irrelevante para la calidad percibida.
3. Los primeros juegos 3D a menudo estaban limitados por CPU, no por GPU. Transformaciones y lighting se hacían en CPU antes de que las GPU las asumieran, por lo que los patrones de tirones eran distintos: picos por simulación pesada en vez de picos por shaders.
4. La compilación de shaders es un clásico moderno de stutter. Los motores que compilan shaders bajo demanda pueden pegar tirones la primera vez que ves un efecto nuevo.
   El caching ayuda, pero solo si el pipeline está bien implementado y persistido.
5. La VR hizo que el pacing de fotogramas fuera innegociable. Las molestias en VR forzaron a la industria a tratar las fechas límite de fotogramas fallidas como fallos de primera clase,
   no como una molestia estética.
6. Los bugs de pacing existían incluso cuando el FPS “estaba bien”. Algunos drivers y motores antiguos producían presentaciones desiguales
   (AFR multi-GPU era notorio), provocando “microstutter” a pesar de un FPS promedio alto.
7. Los planificadores modernos del SO pueden crear jitter bajo carga. Tareas en segundo plano, gestión de energía y tormentas de interrupciones pueden robar
   rebanadas de CPU en el momento equivocado y aparecer como picos de tiempo de fotograma.
8. El almacenamiento se volvió rápido, pero los bloqueos por IO no desaparecieron. NVMe redujo los tiempos promedio de carga, pero un solo IO bloqueado en el hilo equivocado
   aún puede causar un tirón visible si el motor no está diseñado para hacer streaming correctamente.

Dónde muere el tiempo de fotograma: patrones comunes de cuello de botella

El stutter raramente es “una sola cosa”. Normalmente es un camino crítico que ocasionalmente se bloquea.
Piensa como un SRE: no arreglamos la “latencia”. Arreglamos la latencia de cola, y encontramos la dependencia que la posee.

Limitado por CPU: el hilo principal llega tarde

Síntomas: uso de GPU bajo o fluctuante, un núcleo de CPU al máximo, picos en tiempo de fotograma durante AI, física, streaming del mundo,
recolección de basura o escenas con muchas draw calls.

Enfoque práctico: reduce el coste de la simulación, reduce draw calls, limita FPS, o mueve trabajo fuera del hilo principal.
Si eres jugador, no puedes reescribir el motor, pero puedes cambiar ajustes que afecten la CPU: distancia de visión, densidad de multitud,
física/partículas, construcción de BVH de ray tracing (sí, eso también puede afectar la CPU).

Limitado por GPU: el renderizado llega tarde

Síntomas: uso de GPU alto y estable, tiempo de fotograma aumenta con resolución y efectos pesados, picos correlacionados con explosiones,
volumetría, RT o post-procesado. El gráfico puede seguir mostrando picos si los relojes se reducen por temperatura.

Enfoque práctico: baja resolución, desactiva primero los efectos caros (RT, volumetría, sombras), usa DLSS/FSR/XeSS si están disponibles,
y evita FPS sin límite si provoca throttling térmico.

Pacing / problemas de sincronización: el pipeline es desigual

Síntomas: FPS promedio alto, pero el gráfico de tiempo de fotograma muestra picos periódicos a intervalos regulares (p. ej., cada segundo o múltiplos del refresco).
A menudo ligado a VSync, triple buffering, modo ventana sin bordes, overlays, software de captura o limitadores de fotogramas deficientes.

IO y almacenamiento: el tirón que no “bajas gráficos” soluciona

Síntomas: picos al entrar en nuevas áreas, girar rápidamente, abrir menús o después de sesiones largas.
La cola de disco sube, los page faults se disparan y el sistema se siente “pegajoso” entre aplicaciones.

Causas: stalls en streaming de assets, escrituras en caché de shaders, RAM insuficiente que deriva en paginación, antivirus escaneando archivos del juego,
o una unidad haciendo mantenimiento en segundo plano. El almacenamiento rápido ayuda, pero una arquitectura de hilos mala vuelve irrelevante el almacenamiento veloz.

Red y tick del servidor: los juegos online también pueden dar tirones

No todo el “stutter” es tiempo de fotograma. Pérdida de paquetes y jitter pueden parecer tirones porque el movimiento del jugador salta o hace rubber-band.
Distingue el stutter de render (picos en tiempo de fotograma) del stutter de simulación/red (tiempo de fotograma estable, pero movimiento inconsistente).

Guía rápida de diagnóstico (primer/segundo/tercer chequeo)

Cuando estás bajo presión—noche de torneo, demo para la dirección, “por qué esta estación de trabajo se siente fatal”—necesitas triaje.
Este es el camino más corto hacia una respuesta útil.

Primero: confirma que es tiempo de fotograma, no red o percepción

1. Activa un gráfico de tiempo de fotograma (en el juego, overlay o herramienta de captura).
2. Reproduce el tirón tres veces en el mismo punto/acción.
3. Si el gráfico hace picos con el tirón: es latencia de render/simulación. Si no lo hace: sospecha de red o problemas de entrada.

Segundo: decide si estás limitado por CPU o GPU

1. Observa la utilización y los relojes de la GPU durante el tirón.
2. Si el uso de GPU es bajo cuando el tiempo de fotograma es alto: CPU o stall de sincronización/driver.
3. Si el uso de GPU está al máximo y el tiempo de fotograma sube con la resolución: limitado por GPU.

Tercero: elimina la “sabotaje externa”

1. Desactiva overlays (captura, chat, rendimiento, software RGB).
2. Revisa tareas en segundo plano: scans de antivirus, actualizaciones, indexado, telemetría.
3. Revisa salud de almacenamiento y paginación: poca RAM y page faults son fábricas de tirones.

Cuarto: aplica los estabilizadores más rápidos

• Limita FPS (preferible el limitador dentro del juego). Objetivo: ligeramente por debajo del refresco (p. ej., 141 en 144 Hz).
• Activa VRR (G-Sync/FreeSync) si está soportado; empareja con límites sensatos.
• Elige un plan de energía que no haga downclock agresivo bajo cargas transitorias.

Si haces esos cuatro pasos y aún tienes picos, no estás “perdiendo una opción”. Estás tratando con un problema de contenido/engine/driver,
o con inestabilidad de hardware/SO. Ahí es cuando reúnes evidencia en vez de tocar casillas a ciegas.

Tareas prácticas: 14 comandos reales, qué significan, qué decides

Están escritas como un runbook de SRE porque eso es lo que es el troubleshooting de rendimiento: un incidente con gráficos,
hipótesis y contención. La mayoría de los comandos están orientados a Linux porque son reproducibles y honestos.
Si estás en Windows, el modelo mental aún se traduce: buscas saturación de CPU, stalls de GPU, encolamiento de IO y presión de memoria.

Task 1: Confirmar tasa de refresco y modo actual

cr0x@server:~$ xrandr --current
Screen 0: minimum 8 x 8, current 2560 x 1440, maximum 32767 x 32767
DP-1 connected primary 2560x1440+0+0 (normal left inverted right x axis y axis) 596mm x 335mm
   2560x1440     143.91*+
   1920x1080     143.85
HDMI-1 disconnected (normal left inverted right x axis y axis)

Qué significa: Estás realmente funcionando a 143.91 Hz en DP-1. Bien.
Si pensabas que estabas a 144 Hz pero estás a 60 Hz, ningún ajuste arregla “se siente lento”.

Decisión: Si el refresco está mal, corrige la configuración de pantalla/cable/puerto antes de tocar otra cosa.

Task 2: Comprobar compositor / ruta de vsync (pista Wayland/X11)

cr0x@server:~$ echo $XDG_SESSION_TYPE
wayland

Qué significa: Estás en Wayland. Algunos juegos y overlays se comportan distinto; las herramientas de captura y compositores pueden añadir latencia o artefactos de pacing.

Decisión: Si el tirón es nuevo tras cambiar el tipo de sesión, prueba el otro tipo como control.

Task 3: Presión de CPU en vivo y saturación por núcleo

cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.8.0 (host) 	01/13/2026 	_x86_64_	(16 CPU)

12:10:01 AM  CPU   %usr %nice %sys %iowait %irq %soft %steal %idle
12:10:02 AM  all   28.10  0.00  6.20   0.15 0.00  0.35   0.00 65.20
12:10:02 AM    0   92.00  0.00  5.00   0.00 0.00  0.00   0.00  3.00
12:10:02 AM    1   18.00  0.00  4.00   0.00 0.00  0.00   0.00 78.00

Qué significa: CPU0 está casi saturado mientras otros están relativamente inactivos. Eso grita “limitado por el hilo principal”.

Decisión: Reduce ajustes que carguen la CPU, limita FPS y revisa interrupciones en segundo plano o un cuello de botella single-thread.

Task 4: Confirmar presión de memoria (la paginación causa tirones)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            31Gi        27Gi       1.2Gi       1.1Gi       3.0Gi       2.8Gi
Swap:           16Gi       7.8Gi       8.2Gi

Qué significa: Swap está siendo usado activamente. No necesariamente fatal, pero usar swap durante el juego es una causa clásica de tirones.

Decisión: Cierra procesos que consuman mucha memoria, reduce la calidad de texturas o añade RAM. Si el swap crece durante el juego, trátalo como un incidente real.

Task 5: Vigilar fallos de página mayores en tiempo real

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  0 812345 1213456 102400 2800000  15   22   120   340 5200 8800 31  7 60  2  0
 3  1 813112 1189000 102400 2792000  80  110   900  1400 6400 9900 35  8 52  5  0

Qué significa: Valores no nulos en si/so significan que hay swap in/out ocurriendo. Eso implica IO en la ruta de memoria.

Decisión: Si la actividad de swap se correlaciona con los tirones, deja de tratar los ajustes gráficos como el problema.

Task 6: Identificar encolamiento de IO y saturación de disco

cr0x@server:~$ iostat -xz 1 3
Linux 6.8.0 (host) 	01/13/2026 	_x86_64_	(16 CPU)

Device            r/s     w/s   rkB/s   wkB/s  await  %util
nvme0n1          12.0    85.0   640.0  8200.0   6.50  78.00
sda               0.0     2.0     0.0    64.0  25.00   5.00

Qué significa: NVMe está ocupado (%util alto). await ~6.5 ms está más o menos bien, pero los picos importan.
Si ves await saltar a decenas/centenas de ms durante los tirones, el IO está involucrado.

Decisión: Si el IO está saturado, mueve el juego a un almacenamiento más rápido, exclúyelo del escaneo AV y revisa escrituras en segundo plano.

Task 7: Buscar picos de latencia en filesystem y capa de bloques

cr0x@server:~$ sudo dmesg -T | tail -n 8
[Tue Jan 13 00:11:02 2026] nvme nvme0: I/O 123 QID 5 timeout, aborting
[Tue Jan 13 00:11:02 2026] nvme nvme0: Abort status: 0x371
[Tue Jan 13 00:11:03 2026] EXT4-fs warning (device nvme0n1p2): ext4_end_bio:343: I/O error 10 writing to inode 262145 starting block 12345678

Qué significa: Eso no es “stutter”, eso es un incidente de almacenamiento. Timeouts y errores de IO se manifestarán como tirones graves y eventualmente pérdida de datos.

Decisión: Deja de benchmarkear. Haz copia de seguridad. Revisa SMART, cables, temperaturas y firmware.

Task 8: Revisar SMART de NVMe e indicadores de throttling térmico

cr0x@server:~$ sudo smartctl -a /dev/nvme0
SMART/Health Information (NVMe Log 0x02, NSID 0xffffffff)
Critical Warning:                   0x00
Temperature:                       79 Celsius
Available Spare:                   100%
Percentage Used:                   6%
Data Units Read:                   12,345,678
Data Units Written:                9,876,543
Warning Comp. Temperature Time:    0
Critical Comp. Temperature Time:   12

Qué significa: 79°C y tiempo de “temperatura crítica” no nulo sugiere eventos de throttling.
El throttling puede crear picos periódicos en el tiempo de fotograma debido a que la latencia de IO se dispara.

Decisión: Mejora el flujo de aire, añade un disipador, reposiciona la unidad, actualiza firmware si hace falta.

Task 9: Confirmar driver de GPU y estadísticas básicas de GPU (ejemplo NVIDIA)

cr0x@server:~$ nvidia-smi --query-gpu=name,driver_version,utilization.gpu,clocks.sm,temperature.gpu,pstate --format=csv
name, driver_version, utilization.gpu [%], clocks.sm [MHz], temperature.gpu, pstate
NVIDIA GeForce RTX 4070, 550.54.14, 96 %, 2475 MHz, 73, P0

Qué significa: La GPU está casi al máximo y en P0 (estado de máxima performance). Probablemente estás limitado por GPU en este momento.

Decisión: Si el tiempo de fotograma es alto aquí, baja ajustes pesados de GPU o usa un upscaler.

Task 10: Verificar razones de throttling de GPU (NVIDIA)

cr0x@server:~$ nvidia-smi -q -d PERFORMANCE | sed -n '1,80p'
==============NVSMI LOG==============
Performance State                          : P0
Clocks Throttle Reasons
    Idle                                   : Not Active
    Applications Clocks Setting             : Not Active
    SW Power Cap                            : Not Active
    HW Slowdown                             : Active
    HW Thermal Slowdown                     : Active
    Sync Boost                              : Not Active
    SW Thermal Slowdown                     : Not Active

Qué significa: Hay slowdown térmico activo. Tu GPU está frenándose intermitentemente.
Eso produce un patrón muy específico de “va bien y luego pega un tirón”.

Decisión: Mejora la refrigeración, reduce ligeramente el límite de potencia o limita FPS para reducir calor sin matar la capacidad de respuesta.

Task 11: Capturar procesos CPU en segundo plano cuando ocurre un tirón

cr0x@server:~$ top -b -n 1 | head -n 20
top - 00:12:44 up  2:31,  1 user,  load average: 4.21, 3.88, 3.51
Tasks: 329 total,   2 running, 327 sleeping,   0 stopped,   0 zombie
%Cpu(s): 36.3 us,  7.2 sy,  0.0 ni, 55.8 id,  0.5 wa,  0.0 hi,  0.2 si,  0.0 st
MiB Mem :  32154.0 total,   1204.0 free,  27680.0 used,   3270.0 buff/cache
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 8421 cr0x      20   0  9812m  5020m  132m R  168.0  15.6  12:31.22 game.bin
 2210 root      20   0  1240m  220m   34m S   45.0   0.7   0:40.11 tracker-miner-fs

Qué significa: El juego consume mucho (esperado), pero también lo hace un indexador de archivos. Eso acompaña al stutter.

Decisión: Pausa/desactiva el indexado para la ubicación de la biblioteca del juego. Si es gestionado por la empresa, solicita una exclusión.

Task 12: Revisar tormentas de interrupciones (input lag y picos)

cr0x@server:~$ cat /proc/interrupts | head
           CPU0       CPU1       CPU2       CPU3
  0:         45          0          0          0   IO-APIC   2-edge      timer
  1:          2          0          0          0   IO-APIC   1-edge      i8042
 24:    1423456    1322211    1209987    1187765   PCI-MSI 327680-edge      nvme0q0
 42:     983221     964112     955001     948887   PCI-MSI 524288-edge      nvidia

Qué significa: Altas tasas de interrupciones son normales para NVMe/GPU, pero si una CPU se satura mientras otras están inactivas,
puedes obtener jitter de planificación.

Decisión: Si ves desequilibrio patológico o saltos súbitos, investiga problemas de drivers, ajustes MSI/MSI-X o regresiones del kernel.

Task 13: Comprobar escalado de frecuencia de CPU (picos de downclock)

cr0x@server:~$ grep -H . /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor:powersave
/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq:800000

Qué significa: El governor está en powersave y la CPU está a 800 MHz ahora mismo.
Eso es genial para batería y terrible para picos en el tiempo de fotograma.

Decisión: Cambia a un governor orientado a rendimiento mientras juegas o cuando ejecutes cargas sensibles a la latencia.

Task 14: Aplicar un governor de rendimiento temporal (prueba, no “configures y olvides”)

cr0x@server:~$ sudo cpupower frequency-set -g performance
Setting cpu: 0
Setting cpu: 1
Setting cpu: 2
Setting cpu: 3
Setting cpu: 4
Setting cpu: 5
Setting cpu: 6
Setting cpu: 7
Setting cpu: 8
Setting cpu: 9
Setting cpu: 10
Setting cpu: 11
Setting cpu: 12
Setting cpu: 13
Setting cpu: 14
Setting cpu: 15

Qué significa: Has eliminado una fuente importante de variación de latencia: el downclock agresivo.

Decisión: Si esto mejora el pacing, crea una solución por perfil (modo juego) en vez de mantener el equipo caliente 24/7.

Tres mini-historias corporativas desde las trincheras

1) El incidente causado por una suposición errónea: “El FPS es alto, así que la estación está bien”

Un equipo de diseño se quejó de que su vista 3D “se sentía pegajosa” en estaciones de trabajo nuevas y de alta gama.
TI respondió lo obvio: “La GPU es de primer nivel; el contador de FPS supera 120; no es la máquina.”
El ticket rebotó dos veces. La moral no mejoró ni un porcentaje.

Un ingeniero con mentalidad SRE se sentó con un usuario y hizo lo aburrido: miró el tiempo de fotograma, no el FPS.
El gráfico estaba plano hasta que abrieron un panel pesado del explorador de assets, entonces se disparaba cada pocos segundos como un metrónomo.
No era un tirón aleatorio. Era un stall periódico.

Correlacionaron los picos con la actividad de disco. Resultó que el directorio de caché de assets estaba en una carpeta sincronizada por red
exigida por la política. El agente de sincronización se despertaba por temporizador, escaneaba un montón de archivos pequeños y competía con el IO de la aplicación.
El FPS promedio se mantuvo alto porque el render entre stalls iba bien. La experiencia del usuario no.

La solución no fue “más GPU”. Fue mover la caché a un NVMe local y excluirla de la sincronización,
manteniendo los archivos finales sincronizados. Los picos en el tiempo de fotograma desaparecieron.
El postmortem fue directo: deja de usar FPS como proxy de capacidad de respuesta.

2) La optimización que salió mal: perseguir FPS pico y comprar tirones

Un pequeño equipo interno corría una pared de visualización para una sala de briefings. Alguien notó que la app a veces caía por debajo del refresco.
Un ingeniero bienintencionado “optimizó” desbloqueando FPS y desactivando la sincronización para “dejar que la GPU corriera libre”.
El contador de FPS se disparó. El equipo aplaudió internamente. Luego los clientes empezaron a preguntar por qué el movimiento se veía entrecortado.

El problema no era el rendimiento bruto; era el pacing. El render sin límite creó una cola profunda de fotogramas.
La latencia input-to-photon aumentó, y la pantalla vio una entrega irregular porque el compositor y el swapchain ahora lidiaban con una avalancha de fotogramas.
Pequeños stalls periódicos (recolección de basura, flush de logs, telemetría) se volvieron visibles como tirones duros porque no había una cadencia consistente.

Lo más humillante: la “optimización” también aumentó las temperaturas. Después de quince minutos, la GPU se throttled.
El tiempo de fotograma pegó un gran salto justo cuando el briefing alcanzó el “momento wow”.

La solución fue contraintuitiva para la gente de “más FPS”: limita FPS ligeramente por debajo del refresco, activa VRR cuando sea posible y mantiene el buffering predecible.
El FPS pico disminuyó. La suavidad mejoró. Los clientes dejaron de entrecerrar los ojos.

3) La práctica aburrida pero correcta que salvó el día: triaje de rendimiento basado en evidencia

Un equipo de producción responsable de un simulador de entrenamiento tuvo una candidata a salida que “se sentía peor” que la build anterior.
Sin crashes, sin regresiones obvias en el FPS promedio. Solo una sensación general de tirones al moverse rápidamente por un entorno complejo.
El camino fácil era debatir opiniones. El camino correcto fue recoger trazas consistentes.

Mantuvieron una lista estándar de captura de rendimiento: misma ruta, mismas barridas de cámara, mismo preset gráfico, mismo estado de máquina.
Capturaron tiempos de fotograma, utilización CPU/GPU y estadísticas de IO. Luego compararon percentiles, no promedios.
La regresión apareció como un peor tiempo de fotograma en el percentil 99.9, aunque el FPS promedio no cambió.

El culpable fue mundano: un cambio en el logging que hacía flush a disco más frecuentemente, y en el hilo principal.
En máquinas rápidas “pasaba”, hasta que el filesystem hizo un sync periódico o el disco se calentó y la latencia se disparó.
El logging no era “pesado” en promedio; ocasionalmente bloqueaba.

Movieron el logging fuera del hilo principal y lo hicieron en lotes de forma segura. La release se envió a tiempo.
Nadie escribió un mensaje épico en Slack, que es señal de que se hizo bien.

Errores comunes: síntoma → causa raíz → solución

1) “FPS alto pero pega tirones cuando giro rápido”

Síntoma: Picos al girar la cámara, entrar en nuevas áreas o efectos vistos por primera vez.

Causa raíz: Stalls en streaming de assets o compilación de shaders bajo demanda.

Solución: Habilita precompilación de shaders si existe, calienta la caché de shaders, mueve el juego a almacenamiento rápido, evita IO en segundo plano y mantén margen de RAM.

2) “Es fluido durante 10 minutos y luego empeora”

Síntoma: Los picos en tiempo de fotograma aumentan con el tiempo.

Causa raíz: Throttling térmico (GPU/CPU/NVMe) o fuga de memoria que lleva a paginación.

Solución: Monitorea relojes/temperaturas, mejora refrigeración, limita FPS, revisa RAM y actividad de swap, reinicia como contención si hace falta.

3) “Tirón periódico cada segundo (o cada pocos segundos)”

Síntoma: Picos en tiempo de fotograma con cadencia regular.

Causa raíz: Tareas en segundo plano programadas (indexadores, actualizadores), flush de telemetría, o mismatch de sync/buffering con la cadencia del refresco.

Solución: Desactiva tareas programadas, prueba pantalla completa exclusiva, usa un cap de FPS sensato y evita limitadores de terceros que causen jitter de pacing.

4) “Activar VSync lo hace lento; desactivarlo produce tearing”

Síntoma: O bien tearing o bien entrada pegajosa.

Causa raíz: Comportamiento clásico de VSync: perder deadlines fuerza esperar un refresco entero; buffering añade latencia.

Solución: Usa VRR si está disponible; limita FPS ligeramente por debajo del refresco; si te quedas con VSync, ajusta para no perder deadlines de refresco.

5) “Bajar gráficos no ayuda al stutter”

Síntoma: Mismos picos con ajustes bajos.

Causa raíz: Limitación por hilo principal de CPU, stalls de IO o interrupciones a nivel de SO.

Solución: Reduce ajustes que carguen CPU, revisa procesos en segundo plano, verifica presión de memoria y deja de culpar a la GPU por defecto.

6) “Microstutter solo en ventana sin bordes”

Síntoma: Fullscreen se siente más suave que borderless.

Causa raíz: La ruta del compositor añade complejidad de planificación y buffering; los overlays se enganchan de forma distinta.

Solución: Prueba fullscreen exclusivo, desactiva overlays, prueba distintos ajustes de compositor o tipo de sesión.

7) “Stutter tras actualizar drivers”

Síntoma: Nuevos picos o peor pacing después de la actualización.

Causa raíz: Regresión de driver, invalidación de caché de shaders o cambios en las defaults de gestión de energía.

Solución: Instalación limpia del driver, reconstruye la caché de shaders, verifica comportamiento de potencia/relojes y haz rollback si la evidencia lo respalda.

Broma #2: Si tu arreglo involucra “prueba reinstalar Windows”, eso no es troubleshooting; es exorcismo de rendimiento con una barra de progreso.

Listas de verificación / plan paso a paso

Checklist A: estabilizar el pacing en 15 minutos

1. Medir: activa un gráfico de tiempo de fotograma y reproduce el tirón de forma fiable.
2. Limitar FPS: usa el limitador del juego primero; ajusta el cap a refresco-3 (p. ej., 141 para 144 Hz).
3. VRR: activa G-Sync/FreeSync; mantén el cap para permanecer dentro de la ventana VRR.
4. Overlays desactivados: desactiva herramientas de captura/overlay una por una; vuelve a probar tras cada cambio.
5. Temperaturas: vigila relojes y temperaturas de GPU/CPU; arregla throttling antes de perseguir ajustes.
6. Margen de memoria: asegúrate de tener RAM disponible; cierra navegadores y launchers que se hinchan con el tiempo.
7. Sanidad de IO: asegura que el juego esté en almacenamiento local rápido; exclúyelo de escaneo en tiempo real si la política lo permite.

Checklist B: decidir “CPU-bound vs GPU-bound” sin adivinar

1. Baja la resolución un paso (o activa un upscaler).
2. Si los tiempos de fotograma mejoran significativamente: más bound a GPU.
3. Si los tiempos de fotograma cambian poco: más bound a CPU o IO/sync.
4. Baja ajustes que carguen CPU (distancia de visión/multitud/física).
5. Si los tiempos de fotograma mejoran: confirmado CPU-bound.

Checklist C: paquete de evidencia para escalar (driver/vendor/equipo de engine)

• Captura de tiempo de fotograma mostrando picos (incluye estadísticas percentiles si es posible).
• Relojes/temperaturas/utilización de GPU en el momento de los picos.
• Utilización por núcleo de CPU y estado de escalado de frecuencia.
• Estadísticas de IO (cola/await) y memoria (swap/page faults).
• Pasos exactos para reproducir (escena, ruta, ajustes, tiempo hasta fallo).

Una nota de fiabilidad que deberías tomar para tus propios sistemas

“La latencia promedio tranquiliza. La latencia cola es la experiencia del cliente.” Esa es la misma lección que el tiempo de fotograma.
En ops, seguimos p95/p99. En render, seguimos 1% y 0.1% lows y los picos en tiempo de fotograma.

Una cita, porque es relevante y vale la pena recordar:
Todo falla todo el tiempo. — Werner Vogels

Preguntas frecuentes

1) Si tengo un monitor de 240 Hz, ¿necesito 240 FPS?

No. Necesitas entrega consistente. 120 FPS con tiempos de fotograma planos ~8.3 ms puede sentirse mejor que un 200–240 inestable.
Un mayor refresco ayuda a reducir la latencia percibida, pero solo si tu sistema puede mantener tiempos de fotograma estables.

2) ¿Cuál es la diferencia entre “stutter” y “input lag”?

Stutter es tiempos de fotograma desiguales (tirones visuales). Input lag es el tiempo desde tu acción hasta los fotones en la pantalla.
Se correlacionan pero no son idénticos: puedes tener pacing suave con alta latencia (colas profundas),
o baja latencia con picos ocasionales (stalls en segundo plano).

3) ¿Son los 1% lows lo mismo que picos de tiempo de fotograma?

Están relacionados. Los 1% lows resumen el 1% más lento de fotogramas en un solo número.
Los picos de tiempo de fotograma muestran la forma y el timing exactos. Usa lows para comparaciones rápidas; usa gráficos para diagnóstico.

4) ¿Por qué un cap de FPS a veces hace que el juego se sienta más suave?

Porque reduce la varianza y evita colas descontroladas y oscilaciones térmicas.
Un cap fuerza al pipeline a una cadencia predecible. La cadencia predecible se ve suave.

5) ¿Debería usar el limitador del juego, el del driver o una herramienta externa?

Prefiere el limitador dentro del juego primero. Está más cerca del modelo de timing del engine y suele producir mejor pacing.
Los límites a nivel de driver pueden estar bien. Las herramientas externas varían mucho; algunas son excelentes, otras introducen jitter. Mide, no asumas.

6) ¿La RAM más rápida ayuda al tiempo de fotograma?

A veces, especialmente en escenarios limitados por CPU donde el hilo principal es sensible a latencias de memoria.
Pero rara vez es una solución mágica. Si estás paginando a disco, RAM más rápida no te salvará. Arregla la presión de memoria primero.

7) ¿Por qué pego tirones solo la primera vez que entro a un área?

Eso suele ser compilación de shaders o calentamiento de caché de assets. Una vez compilado/cacheado, las repeticiones son más suaves.
Los juegos que precompilan shaders al inicio tienden a pegar menos tirones durante la partida, a costa de pantallas de carga más largas.

8) ¿El almacenamiento realmente puede causar stutter incluso con NVMe?

Sí. NVMe mejora los promedios, no la arquitectura. Un solo IO sincrónico en un hilo crítico puede bloquear el fotograma.
Además: throttling térmico o problemas de firmware pueden disparar la latencia de IO. Revisa SMART y temperaturas si el patrón encaja.

9) ¿VRR (G-Sync/FreeSync) siempre es mejor?

Usualmente, para tasas de fotogramas variables. Pero VRR no arregla picos enormes; solo adapta el timing de refresco a la entrega de fotogramas.
Aún necesitas eliminar stalls. Además, VRR mal configurado junto con caps deficientes puede causar parpadeo o pacing extraño.

10) ¿Qué tiempo de fotograma es “bueno”?

Coincide con tu objetivo. Para 60 Hz, quieres la mayoría de fotogramas por debajo de 16.67 ms, con picos mínimos.
Para 144 Hz, apunta a ~6.94 ms típico y mantén la cola ajustada: picos por encima de ~20 ms serán notorios en movimientos rápidos.

Conclusión: próximos pasos que realmente mueven la aguja

Deja de discutir con un contador de FPS. Mide tiempo de fotograma.
El objetivo no es un número pico heroico; es consistencia aburrida.
Lo aburrido es suave. Lo suave es lo que querías.

Haz esto a continuación, en orden

1. Activa un gráfico de tiempo de fotograma y reproduce el problema.
2. Limita FPS ligeramente por debajo del refresco y prueba de nuevo.
3. Clasifica el cuello de botella: CPU, GPU, IO/memoria o sync/pacing.
4. Elimina ofensores en segundo plano (overlays, indexadores, actualizadores) y revisa termales.
5. Si los picos persisten, junta un paquete de evidencia (percentiles, relojes, temperaturas, IO, memoria) y escala con datos.

Esa es toda la religión del tiempo de fotograma. Practícala una semana y empezarás a oír problemas de stutter en reuniones
de la misma forma que oyes la latencia cola en producción: como un problema de dependencia solucionable, no como “mi máquina me odia”.