Muchos FPS de media pero malos 1% lows: qué significa eso

El contador dice 200 y el juego se siente como si fuera a 90. No hay nada roto, nada se congela durante un segundo entero, pero un tiroteo nunca se siente como promete el número. Esa experiencia tiene un nombre y una medición, y en cuanto sabes leerla dejas de perseguir el número equivocado.

Primero, la frase honesta. Esta página explica una medición, no un arreglo. w0a no imprime ninguna cifra de «FPS ganados» en ningún sitio, así que si un cambio ayudó es algo que lees en tus propias capturas de antes y después, frente a tu propio ruido entre ejecuciones — y cada número de abajo se puede recalcular a partir del archivo que guarda la página Benchmark.

Qué son en realidad los tres números

Ordena todos los fotogramas de una ejecución del más lento al más rápido.

Los FPS medios son el promedio de todos. Es la cifra menos útil de la página.
El 1% low es el peor uno por ciento de esos fotogramas. Se suele imprimir como una cifra de FPS, así que un «1% low de 70» significa que cada uno de tus peores fotogramas tardó más o menos lo que tarda un fotograma en un juego a 70 FPS.
El 0,1% low es el peor de cada mil — los sucesos raros y profundos.

El tiempo de fotograma son los mismos datos en milisegundos, y merece la pena memorizar la aritmética porque hace concreto todo lo demás de esta página: 16,7 ms son 60 FPS, 6,9 ms son 144, 4,2 ms son 240.

Así que una ejecución con una media de 200 y un 1% low de 70 es una ejecución en la que el fotograma típico tardó unos 5 ms y el peor centésimo tardó unos 14 — casi el triple. Y a 200 FPS, el uno por ciento de tus fotogramas son dos fotogramas cada segundo. Dos veces por segundo, la imagen se queda quieta el tiempo que ocupan tres fotogramas. Eso es lo que estás notando, y ninguna media te habla de ello.

Lee la diferencia, no el número

Un 1% low de 70 es excelente en una ejecución a 90 FPS y alarmante en una de 200. La lectura útil es la relación entre los dos:

Lo que ves	Lo que suele significar
La media y el 1% low van juntos	Entrega constante. Eso es lo que significa «suave», incluso con una tasa de fotogramas modesta.
El 1% low muy por debajo de la media	Algo está interrumpiendo una ejecución por lo demás sana — un suceso, no una carga de trabajo.
El 0,1% low muy por debajo del 1% low	Sucesos raros y profundos: un reinicio del controlador, una tormenta de paginación, una lectura larga de disco.
Todo bajo a la vez	Sencillamente estás pidiendo más de lo que entrega el hardware. Baja un ajuste.

Esa tercera fila es fácil de leer mal. Si tu 1% low está bien y tu 0,1% low es horrible, no tienes un problema de ritmo — tienes un puñado de incidentes concretos, y los incidentes se pueden encontrar.

Por qué una cola mala es un problema distinto de una media baja

Una media baja es una cuestión de carga de trabajo: la máquina está haciendo todo lo que puede y no es suficiente. La respuesta es un ajuste, una resolución u otro hardware.

Una cola mala es una cuestión de sucesos: la máquina sigue el ritmo casi siempre y algo la para cada cierto tiempo. La respuesta está en encontrar ese algo. La lista es corta y cada elemento deja un rastro — un driver reteniendo un núcleo del procesador, páginas volviendo desde el disco, una lectura de assets, un trabajo en segundo plano, un shader compilándose, un reinicio del controlador. Por qué los juegos dan tirones en Windows 11 recorre esa lista causa por causa, y qué busca el escaneo de tirones es la versión automática, que etiqueta cada hallazgo como probado, probable, candidato o no comprobado en lugar de darte una puntuación de confianza que no se ha ganado.

Hay también un caso intermedio: una máquina que de media no está limitada por la GPU pero se topa con un límite en los momentos de más trabajo. Los fotogramas que se quedan atrás son exactamente los fotogramas en los que más cosas están pasando — es decir, el tiroteo. Si tu GPU se queda bastante por debajo de la ocupación total mientras los lows sufren, la GPU no llega al 100% es la página de diagnóstico para eso.

La disciplina de medición que hace que todo esto merezca la pena

Los percentiles tienen más ruido que las medias, porque se calculan a partir de menos fotogramas. Dos ejecuciones de la misma configuración sin cambios no van a dar el mismo 1% low, y la diferencia entre ellas es el cambio más pequeño que eres capaz de detectar siquiera.

Por eso una captura solo sirve al lado de su propio ruido. La página Benchmark calcula un ruido de medición a partir de la dispersión minuto a minuto de cada captura y lo imprime por separado para la media, para el 1% low y para el 0,1% low — y no va a afirmar una diferencia que caiga dentro de él. Ahí está toda la disciplina en un solo comportamiento: un resultado más pequeño que tu propia variación entre ejecuciones no es un resultado.

La versión práctica:

El mismo juego, el mismo mapa o la misma repetición, la misma duración, los mismos ajustes dentro del juego.
Juega de la misma manera. Una ejecución mirando a una pared y una ejecución en pleno tiroteo no son comparables.
Graba la configuración sin cambios al menos tres veces antes de tocar nada, para saber qué pinta tiene tu propio ruido.
Cambia una cosa. Cinco cambios y una sola medición no te dicen nada sobre cuál importó — y sumar cinco ganancias medidas por separado es aritmética, no medición.
Compara los lows. Leer el resultado del benchmark explica para qué sirve cada número de la página.

La aritmética exacta, número a número

Esto es lo que hace la página Benchmark con una captura, en el orden en que lo hace.

Paso	La regla	Por qué está ahí
Qué fotogramas cuentan	Solo los fotogramas dibujados mientras el juego era la ventana en primer plano. Cuando el juego vuelve al primer plano, se deja fuera el primer segundo; antes de una pérdida de foco detectada, se dejan fuera los últimos 0,2 segundos. El tiempo dejado fuera se informa junto con la ejecución.	Una captura empieza y se detiene desde la propia ventana de w0a, así que sus bordes son el juego en segundo plano. En una captura grabada, 94 de los 185 fotogramas que había detrás del 1% low eran esos bordes. La cifra de un segundo es un valor elegido, no medido.
Paradas	Un intervalo de fotograma de más de 200 ms se excluye de la media y de todos los percentiles, y se cuenta aparte.	Por encima de 200 ms es una pantalla de carga, un alt-tab o una parada del driver, no renderizado. Metido en la media, enterraría todos los fotogramas reales.
FPS medios	Los fotogramas contados divididos por el tiempo que ocuparon: fotogramas × 1000 ÷ milisegundos totales.
1% low	Ordena los tiempos de fotograma contados. Toma el 1% más lento, redondeado hacia arriba y nunca menos de un fotograma, promedia esos tiempos de fotograma y convierte el resultado en FPS: 1000 ÷ ese promedio.	La otra definición habitual, la tasa de fotogramas en el tiempo de fotograma del percentil 99, se rechazó a propósito: cuando exactamente el 1% de los fotogramas da tirones, cae en el límite y da casi la misma cifra que la media.
0,1% low	Lo mismo, con el 0,1% más lento.
Tiempo de fotograma de los percentiles 99 y 99,9	Se informa aparte, en milisegundos.	Para lectores y herramientas que usan la definición por percentil.
Demasiado corta para leerla	Por debajo de 900 fotogramas no hay suficientes para que el percentil signifique nada.
Recuento de tirones	Un fotograma es un tirón cuando dura más que el doble de la mediana de los tres segundos de alrededor y también más que esa mediana más 8 ms, hasta un segundo.	Tres segundos en lugar de un número fijo de fotogramas, para que la regla signifique lo mismo a 60 FPS y a 300. El término de 8 ms evita que la fluctuación normal a tasas de fotogramas altas cuente como tirón. Los fotogramas de entre 200 ms y un segundo quedan fuera de los percentiles pero entran aquí: un hipo de 250 ms por compilación de shaders es exactamente lo que este recuento existe para atrapar.
Ruido de medición	La captura se corta en bloques de 60 segundos. Cada lado de una comparación necesita al menos dos bloques enteros, o la página dice «no comparable» en lugar de colorear una cifra. El suelo de ruido es un intervalo del 95% a partir de la dispersión entre bloques de los dos lados (método de Welch), como porcentaje del valor «antes». Solo cuentan los bloques completos sin eventos perdidos, y nunca se produce un suelo de cero.	Una diferencia dentro de tu propia variación entre bloques no es un resultado.
Series emparejadas	Cuando ejecutas una serie A/B, solo se informa de un cambio si una prueba exacta de rangos con signo y un intervalo bootstrap del 95% de la mediana de las diferencias (10 000 remuestreos) excluyen ambos el cero, y la mediana es al menos el efecto más pequeño que un piloto de 10 ejecuciones mostró que la configuración puede detectar. La serie necesita al menos 6 pares — con 5, el valor p más pequeño posible es 0,0625 — y sugiere 8, ejecutados en orden ABBA.	Un solo par de antes y después no puede separar un cambio de una GPU caliente o de otro punto de aparición.

Compruébalo tú mismo: recalcula desde el CSV

Guardar CSV en la página Benchmark escribe una tabla con las columnas side,kind,name,value. Las filas con kind = metric son las cifras del resumen; las filas con kind = frame son los intervalos de fotograma, uno por fila, con el tiempo de fotograma en milisegundos en value. Las filas de fotograma guardan la serie entera, paradas incluidas, precisamente para que puedas aplicar tú mismo la regla de los 200 ms y llegar a los mismos números.

Dos cosas antes de empezar:

Los números del archivo usan siempre el punto como separador decimal, diga lo que diga la región de tu Windows. En muchas configuraciones regionales en español, como la de España, el separador decimal es la coma, así que díselo a tu hoja de cálculo al importar, o 6.94 llegará como texto.
Los nombres de las columnas son identificadores fijos en inglés. Están pensados para scripts y son los mismos en todos los idiomas.

En una hoja de cálculo: filtra un side y kind = frame, quita las filas por encima de 200, ordena value de mayor a menor, promedia las primeras N filas, donde N es el número de filas dividido entre 100 y redondeado hacia arriba, y divide 1000 entre ese promedio. El resultado debería ser igual a low_1pct_fps de ese lado.

En PowerShell (cambia before por after para el otro lado):

$ms = Import-Csv .\capture.csv |
  Where-Object { $_.kind -eq 'frame' -and $_.side -eq 'before' } |
  ForEach-Object { [double]::Parse($_.value, [Globalization.CultureInfo]::InvariantCulture) } |
  Where-Object { $_ -le 200 } |
  Sort-Object
$take = [Math]::Max(1, [Math]::Ceiling($ms.Count * 0.01))
1000 / ($ms | Select-Object -Last $take | Measure-Object -Average).Average

Para el 0,1% low, usa 0.001 en lugar de 0.01. Dos comprobaciones rápidas de coherencia en el mismo archivo: el número de filas de fotograma con valor de 200 o menos es igual a la métrica frames, y el número de filas por encima de 200 es igual a excluded_over_stall_ms.

Dos cosas que arruinan un percentil sin que te enteres

La generación de fotogramas. Los fotogramas insertados no llevan ningún estado nuevo del juego. Un 1% low sacado de contar fotogramas sigue produciendo un número, pero ha dejado de describir la respuesta — que es la única razón por la que lo estabas mirando. Desactiva la generación mientras mides. Esto es una cuestión de definición, no una afirmación de que la generación de fotogramas cause tirones.

Las pantallas de carga y las pausas. Una pausa de carga de tres segundos es un solo «intervalo entre fotogramas» de tres mil milisegundos y, si se deja en los datos, se convierte en tu 0,1% low y entierra todo lo que era real. Por eso los intervalos así de largos se excluyen de los percentiles y se reportan aparte, para que ningún número se construya en silencio encima de uno.

Qué no mueve el 1% low

Esto merece decirse claro, porque es fácil confundir las dos cosas: las funciones de latencia y la estabilidad de los percentiles son afirmaciones distintas. Los modos de baja latencia de los fabricantes reducen la profundidad de la cola de renderizado, y esa reducción está medida. No existe ninguna medición publicada que demuestre que mejoren los percentiles de tiempo de fotograma. Las dos cosas pueden merecer la pena; no son la misma cosa, y una página que te presente una como la otra te está vendiendo algo. Instalación limpia para 1% lows estables repasa las pruebas publicadas con fuentes, y la latencia de entrada que ningún software puede arreglar es la cuenta honesta de hasta dónde llega y hasta dónde no llega el trabajo sobre la latencia.

La misma cautela vale para las listas del Registro que prometen mejores lows. Los valores de gestión de memoria del kernel y las anulaciones de la resolución del temporizador se rechazan aquí de plano, no porque sean exóticos sino porque nadie ha publicado de ellos una medición que sobreviva al contacto con un método.

Lo que la página Benchmark no imprime

Ninguna cifra de «FPS ganados», para ningún ajuste, en ninguna parte de w0a. Una ganancia es lo que muestran tus dos propias capturas, o nada.
Ninguna causa, solo el momento. Cuando un tirón coincide con otra cosa que pasó, la tarjeta dice que los dos cayeron en la misma ventana. No dice que uno causara el otro.
Ninguna diferencia dentro del suelo de ruido se muestra como cambio, en ninguna dirección.

Si tus lows son malos y quieres las causas en lugar de las cifras, por qué los juegos dan tirones en Windows 11 es la lista, y qué busca el escaneo de tirones es lo que w0a comprueba automáticamente. Para CS2 en concreto, Pocos FPS y tirones en CS2 aplica todo esto a un juego.

Relacionado

¿Juegas a CS2? Qué opciones de lanzamiento siguen haciendo algo y dónde están de verdad los fotogramas en el menú de vídeo: Pocos FPS y tirones en CS2: una lista basada en mediciones

w0a no cambia ningún ajuste de Windows hasta que se lo pides, y un tweak guarda el valor anterior antes de escribir uno nuevo. Avísame

¿Te sirvió esta página?

¿Qué faltaba, o qué no funcionó? Leemos todos estos mensajes.

Si esta página no resolvió tu problema, escríbenos — dinos qué artículo leíste y lo corregimos.