BoosterX: procesos en segundo plano de Windows y FPS en CS2
En esta página
Comparación de cuatro etapas en un mismo PC. Tras aplicar las optimizaciones de forma secuencial, disminuyó la actividad en segundo plano de Windows y aumentaron los FPS medios en el benchmark seleccionado de CS2 en 2,23–2,96% respecto al sistema Clean preparado. Advanced Advanced obtuvo los FPS medios más altos; Expert Hardcore, el P1 más alto y la menor actividad durante el periodo de inactividad registrado.
Las mediciones fueron realizadas por el desarrollador de BoosterX. El resultado corresponde a una serie en el equipo indicado. Los cálculos incluyen las ocho ejecuciones de FPS y las ventanas WPR completas de cinco minutos.
Resultados de WPR · Resultados de CS2 · Metodología · Descargar los datos originales
Qué se comprobó
Sección titulada « Qué se comprobó»Objetivo: comprobar cómo cambian la actividad en segundo plano de Windows y el rendimiento en un escenario fijo de CS2 al pasar secuencialmente por Clean → Safe Advanced → Advanced Advanced → Expert Hardcore.
WPR y CapFrameX responden a preguntas distintas. WPR muestra la actividad del sistema después del inicio de sesión y durante el periodo de inactividad. CapFrameX mide los intervalos entre fotogramas durante la carga del juego. Una reducción de varias veces en el uso de CPU en segundo plano no implica por sí sola un aumento equivalente de FPS.
Equipo y preparación
Sección titulada « Equipo y preparación»| Parámetro | Condiciones de la serie |
|---|---|
| Fecha de medición | 24 de octubre de 2026 |
| CPU | AMD Ryzen 7 7800X3D, 8 núcleos / 16 hilos |
| GPU | NVIDIA GeForce RTX 5070, controlador 617.42 |
| RAM | 32 GB, 2 × 16 GB DDR5-6000 |
| Placa / BIOS | ASRock B850 Riptide WiFi / 4.20 |
| Windows | Windows 11 Pro 26H2, compilación 26300.9711 |
| BoosterX | 2.4.2.4, compilación Debug; no se guardó el hash del archivo binario utilizado |
| CapFrameX | 1.8.6.2 |
| CS2 | CS2 FPS BENCHMARK DUST2, Workshop ID 3240880604 |
| Gráficos | 1280×960, preajuste Low, FidelityFX desactivado, Reflex activado, fps_max 0 |
| Otros ajustes | ReBAR, Game Mode y HAGS activados; CapFrameX detectó el modo de presentación como Fullscreen Optimized or Borderless |
| Energía | Clean, Safe y Advanced: «Equilibrado»; Expert Hardcore: PowerX v2.1 |
Preparación: instalación limpia de Windows, todas las actualizaciones, Steam, Spotify y controladores del chipset AMD. Los archivos de CS2 se trasladaron desde otro disco. El controlador de vídeo se eliminó con DDU y se volvió a instalar mediante la herramienta de instalación personalizada, con un conjunto reducido de componentes de NVIDIA. No se guardaron por separado la lista exacta de componentes ni la versión del controlador del chipset. Antes de la medición de referencia no se hicieron otros cambios manuales.
Por tanto, Clean aquí significa el sistema preparado antes de aplicar BoosterX, ya con aplicaciones y controladores instalados. No es Windows justo después de la primera pantalla de instalación. En el ETL de Clean también aparece actividad de OneDrive y de componentes de Edge.
Según los datos de los sensores, la frecuencia media de CPU Max durante las ejecuciones de FPS fue de aproximadamente 5035–5043 MHz, y la de GPU, de aproximadamente 2927–2930 MHz. Las frecuencias variaron: la serie no se realizó con frecuencias de CPU/GPU fijas. CPU Max no mide la frecuencia efectiva de cada núcleo. No se registraron los ajustes de PBO ni de Curve Optimizer.
Metodología
Sección titulada « Metodología»Los cuatro estados se aplicaron secuencialmente en una misma instalación de Windows. En cada etapa, primero se ejecutó el ciclo WPR y después la prueba de FPS. No se restauró la imagen Clean entre etapas; los cambios se acumularon. El paquete incluye un intento incompleto de WPR en Expert Hardcore, sin ETL. En el resumen se incluye la siguiente grabación, que sí se completó. Una de las ejecuciones de FPS de Expert Hardcore se realizó antes de esa grabación WPR completada y la otra, después.
WPR: cinco minutos desde el inicio de la grabación al iniciar sesión, cinco minutos de estabilización y, a continuación, cinco minutos de inactividad. Se registraron perfiles ligeros de actividad de CPU, disco, archivos y red. El cálculo se realizó directamente a partir del ETL, entre los marcadores de inicio y fin de cada fase. La duración de cada ventana difiere de 300 segundos en menos de 0,02 segundos. En los ocho ETL, los encabezados indican cero eventos y búferes perdidos.
El inicio de la primera fase se produjo aproximadamente entre el segundo 15 y el 23 después del arranque de Windows. Esta prueba no midió el tiempo de arranque del sistema operativo. Las métricas finales se recalcularon a partir de los ETL.
CS2: dos ejecuciones de aproximadamente 105 segundos por etapa. Se utilizó un escenario automatizado del mapa. La grabación de CapFrameX se iniciaba manualmente con una tecla de acceso rápido, aproximadamente en el mismo punto de referencia. No hay sincronización fotograma a fotograma del inicio. Los dos archivos con el nombre de proceso incorrecto infinst.exe también corresponden a la prueba de CS2. El archivo conserva los nombres originales y el contenido JSON.
No se registraron el build exacto de CS2, la versión del contenido del mapa en el momento de la grabación, el valor independiente de MSAA ni la duración del calentamiento previo. La versión actual del mapa en Workshop puede diferir de la utilizada. La comparación corresponde a este mapa, no a los FPS en una partida competitiva: los autores del mapa señalan por separado la diferencia entre la simulación local y el juego en un servidor.
WPR: actividad de Windows en segundo plano
Sección titulada « WPR: actividad de Windows en segundo plano»| Métrica | Clean | Safe Advanced | Advanced Advanced | Expert Hardcore |
|---|---|---|---|---|
| Tras iniciar sesión: primeros 5 minutos de grabación | ||||
| Uso medio de CPU, % | 1,488Base | 0,411Δ −1,077 p. p.−72,37% | 0,314Δ −1,174 p. p.−78,91% | 0,283Δ −1,205 p. p.−80,99% |
| Pico de CPU en un intervalo de unos 1 s, % | 30,60Base | 14,30Δ −16,30 p. p.−53,27% | 11,36Δ −19,24 p. p.−62,89% | 6,44Δ −24,16 p. p.−78,95% |
| Estimación del tiempo de CPU, núcleo·s | 71,42Base | 19,73Δ −51,68−72,37% | 15,06Δ −56,35−78,91% | 13,58Δ −57,84−80,98% |
| Cambios de contexto / s | 5781,8Base | 1330,6Δ −4451,2−76,99% | 1006,3Δ −4775,4−82,59% | 763,3Δ −5018,5−86,80% |
| Cambios de contexto, total | 1.734.523Base | 399.198Δ −1.335.325−76,99% | 301.900Δ −1.432.623−82,59% | 229.000Δ −1.505.523−86,80% |
| Transiciones de subprocesos a Ready / s | 3692,2Base | 817,9Δ −2874,2−77,85% | 614,7Δ −3077,5−83,35% | 455,7Δ −3236,5−87,66% |
| Procesos al final del intervalo | 148Base | 96Δ −52−35,14% | 92Δ −56−37,84% | 67Δ −81−54,73% |
| Procesos iniciados durante el intervalo | 113Base | 27Δ −86−76,11% | 18Δ −95−84,07% | 16Δ −97−85,84% |
| Subprocesos al final del intervalo | 2566Base | 1718Δ −848−33,05% | 1643Δ −923−35,97% | 1349Δ −1217−47,43% |
| Subprocesos iniciados durante el intervalo | 2833Base | 1030Δ −1803−63,64% | 832Δ −2001−70,63% | 683Δ −2150−75,89% |
| Suma de los conjuntos de trabajo de los procesos¹, MiB | 5054,5Base | 3283,6Δ −1770,9−35,04% | 2954,5Δ −2099,9−41,55% | 2234,4Δ −2820,0−55,79% |
| Suma del commit de los procesos¹, MiB | 2589,9Base | 1685,1Δ −904,8−34,93% | 1586,2Δ −1003,7−38,76% | 1195,6Δ −1394,3−53,84% |
| Identificadores de procesos¹ | 66.187Base | 43.247Δ −22.940−34,66% | 40.520Δ −25.667−38,78% | 30.987Δ −35.200−53,18% |
| DPC / s | 981,7Base | 347,4Δ −634,3−64,61% | 306,4Δ −675,4−68,79% | 204,2Δ −777,5−79,20% |
| Interrupciones de hardware (ISR) / s | 420,1Base | 120,4Δ −299,7−71,34% | 102,7Δ −317,4−75,56% | 92,3Δ −327,8−78,03% |
| Hard faults durante el intervalo² | 16.251Base | 9661Δ −6590−40,55% | 6049Δ −10.202−62,78% | 5271Δ −10.980−67,57% |
| Lectura de disco, MiB | 920,36Base | 295,67Δ −624,69−67,87% | 237,00Δ −683,36−74,25% | 218,96Δ −701,40−76,21% |
| Escritura en disco, MiB | 758,41Base | 123,43Δ −634,98−83,73% | 89,13Δ −669,28−88,25% | 66,27Δ −692,13−91,26% |
| Incluye la escritura de archivos WPR³, MiB | 591,76Base | 85,00Δ −506,76−85,64% | 62,00Δ −529,76−89,52% | 42,00Δ −549,76−92,90% |
| Operaciones de lectura de disco | 29.124Base | 16.718Δ −12.406−42,60% | 13.234Δ −15.890−54,56% | 12.391Δ −16.733−57,45% |
| Operaciones de escritura en disco | 13.298Base | 3118Δ −10.180−76,55% | 2157Δ −11.141−83,78% | 1588Δ −11.710−88,06% |
| Duración del intervalo, s | 300,000 | 300,018 | 300,003 | 300,015 |
| Inactividad: últimos 5 minutos del ciclo | ||||
| Uso medio de CPU, % | 1,238Base | 1,694Δ +0,456 p. p.+36,86% | 0,337Δ −0,901 p. p.−72,77% | 0,183Δ −1,055 p. p.−85,25% |
| Pico de CPU en un intervalo de unos 1 s, % | 12,17Base | 17,74Δ +5,57 p. p.+45,79% | 6,47Δ −5,70 p. p.−46,86% | 6,25Δ −5,92 p. p.−48,64% |
| Estimación del tiempo de CPU, núcleo·s | 59,41Base | 81,31Δ +21,90+36,86% | 16,18Δ −43,23−72,77% | 8,76Δ −50,64−85,25% |
| Cambios de contexto / s | 1944,9Base | 2061,6Δ +116,7+6,00% | 806,9Δ −1138,0−58,51% | 336,5Δ −1608,4−82,70% |
| Cambios de contexto, total | 583.440Base | 618.477Δ +35.037+6,01% | 242.071Δ −341.369−58,51% | 100.967Δ −482.473−82,69% |
| Transiciones de subprocesos a Ready / s | 1208,0Base | 1272,0Δ +64,0+5,30% | 522,9Δ −685,1−56,72% | 200,3Δ −1007,7−83,42% |
| Procesos al final del intervalo | 153Base | 101Δ −52−33,99% | 90Δ −63−41,18% | 64Δ −89−58,17% |
| Procesos iniciados durante el intervalo | 19Base | 168Δ +149+784,21% | 6Δ −13−68,42% | 5Δ −14−73,68% |
| Subprocesos al final del intervalo | 2388Base | 1678Δ −710−29,73% | 1412Δ −976−40,87% | 1189Δ −1199−50,21% |
| Subprocesos iniciados durante el intervalo | 1200Base | 2321Δ +1121+93,42% | 541Δ −659−54,92% | 333Δ −867−72,25% |
| Suma de los conjuntos de trabajo de los procesos¹, MiB | 5150,6Base | 3477,7Δ −1672,9−32,48% | 2890,6Δ −2260,0−43,88% | 2202,8Δ −2947,8−57,23% |
| Suma del commit de los procesos¹, MiB | 2847,4Base | 1796,3Δ −1051,1−36,91% | 1587,9Δ −1259,5−44,23% | 1223,9Δ −1623,5−57,02% |
| Identificadores de procesos¹ | 68.628Base | 45.867Δ −22.761−33,17% | 39.888Δ −28.740−41,88% | 30.597Δ −38.031−55,42% |
| DPC / s | 1210,5Base | 277,5Δ −933,0−77,08% | 216,7Δ −993,7−82,09% | 108,8Δ −1101,7−91,01% |
| Interrupciones de hardware (ISR) / s | 922,1Base | 86,5Δ −835,6−90,62% | 64,3Δ −857,8−93,03% | 46,8Δ −875,3−94,93% |
| Hard faults durante el intervalo² | 636Base | 5258Δ +4622+726,73% | 1040Δ +404+63,52% | 1203Δ +567+89,15% |
| Lectura de disco, MiB | 12,90Base | 105,32Δ +92,42+716,28% | 81,50Δ +68,60+531,64% | 9,83Δ −3,07−23,78% |
| Escritura en disco, MiB | 214,57Base | 317,84Δ +103,27+48,13% | 86,97Δ −127,60−59,47% | 31,03Δ −183,54−85,54% |
| Incluye la escritura de archivos WPR³, MiB | 164,00Base | 172,00Δ +8,00+4,88% | 72,00Δ −92,00−56,10% | 15,00Δ −149,00−90,85% |
| Operaciones de lectura de disco | 634Base | 5281Δ +4647+732,97% | 4241Δ +3607+568,93% | 836Δ +202+31,86% |
| Operaciones de escritura en disco | 5690Base | 2410Δ −3280−57,64% | 1250Δ −4440−78,03% | 1783Δ −3907−68,66% |
| Duración del intervalo, s | 299,986 | 299,999 | 300,006 | 300,016 |
Debajo de cada valor se muestra Δ respecto a Clean en la misma fase: la diferencia absoluta en las unidades de la fila y el cambio relativo en porcentaje. Para el uso de CPU, la diferencia absoluta se indica en puntos porcentuales (p. p.). El signo menos indica una reducción del valor y el signo más, un aumento; la duración de la ventana se muestra sin delta. Fórmulas: Δ = этап − Clean, Δ% = (этап / Clean − 1) × 100.
La CPU se calcula a partir de las muestras CPU Usage (Sampled), teniendo en cuenta la duración de los intervalos y promediando entre 16 procesadores lógicos. El tiempo de CPU estimado equivale al uso medio × duración de la ventana × 16 / 100. El pico se obtiene de intervalos de aproximadamente un segundo; los intervalos extremos pueden ser más cortos. Los eventos se cuentan dentro de la ventana completa; los procesos y los hilos corresponden al final de esta, sin Idle. Los inicios cuentan la creación repetida del mismo proceso.
¹ Memoria y controladores: instantánea de los contadores de procesos al finalizar el ETL, tomada 0,28–0,65 s después del marcador final. El desfase exacto se conserva en JSON. La suma de los conjuntos de trabajo cuenta de nuevo las páginas compartidas y no equivale a la RAM física ocupada. El commit de los procesos muestra la memoria virtual asignada que debe respaldarse con RAM o con el archivo de paginación; no es la cantidad realmente escrita en el archivo de paginación. Estas sumas no describen toda la memoria del kernel, los controladores ni la caché de archivos.
² Los hard faults indican la carga desde el disco de una página que no está en RAM, incluidas las páginas de archivos. No son errores físicos de memoria. DPC e ISR muestran la frecuencia de los eventos, no la latencia de entrada ni la duración de su procesamiento.
³ La escritura de WPR se identifica por los nombres de archivo de los registradores. Ya está incluida en la escritura total en disco. Las métricas de disco incluyen la actividad de la herramienta de medición y no son una estimación pura de la carga de las aplicaciones.
En la comparación entre Clean y Expert Hardcore, el uso de CPU según las muestras después del inicio de sesión se redujo aproximadamente 5,3 veces y, durante el periodo de inactividad, 6,8 veces. Los cambios de contexto durante el periodo de inactividad se redujeron aproximadamente 5,8 veces; el número de procesos al final de la ventana pasó de 153 → 64. Son relaciones entre métricas concretas medidas, no un coeficiente único de «aceleración de Windows».
Por qué Safe tuvo más actividad durante el periodo de inactividad
Sección titulada « Por qué Safe tuvo más actividad durante el periodo de inactividad»Durante el último minuto del periodo de inactividad de Safe se ejecutaron mscorsvw.exe y ngen.exe. mscorsvw.exe representó aproximadamente 56,4 segundos de procesador. CPU medio por minuto: 0,40 → 0,20 → 0,19 → 0,19 → 7,49%. Como resultado, la ventana completa tuvo más actividad que Clean, aunque los primeros cuatro minutos fueron más tranquilos.
Este pico se conserva en la tabla principal. Una única serie secuencial no permite separar el efecto sostenido del modo de las tareas puntuales en segundo plano ni de los cambios en el estado de Windows con el paso del tiempo.
Cómo interpretar las métricas de memoria y disco
Sección titulada « Cómo interpretar las métricas de memoria y disco»La escritura total en disco incluye la escritura del propio WPR. Por ejemplo, en el periodo de inactividad de Clean, de 214,57 MiB escritos, 164 MiB correspondieron directamente a los archivos de los registradores de WPR. Esta parte se muestra en una fila aparte de la tabla. La carpeta de la prueba estaba en OneDrive; no se aisló por separado el efecto de la sincronización. En esta publicación no se comparan la velocidad de red ni el consumo de energía.
CS2: FPS y tiempo de fotograma
Sección titulada « CS2: FPS y tiempo de fotograma»| Métrica | Clean | Safe Advanced | Advanced Advanced | Expert Hardcore |
|---|---|---|---|---|
| FPS medio | 888,29Base | 911,19Δ +22,91+2,58% | 914,56Δ +26,28+2,96% | 908,08Δ +19,79+2,23% |
| P1 FPS | 296,73Base | 304,42Δ +7,69+2,59% | 308,55Δ +11,82+3,98% | 312,15Δ +15,42+5,20% |
| P0,1 FPS | 259,15Base | 265,90Δ +6,76+2,61% | 260,28Δ +1,13+0,44% | 264,29Δ +5,14+1,98% |
| 1% bajo: promedio de fotogramas lentos, FPS | 275,50Base | 283,63Δ +8,14+2,95% | 283,41Δ +7,91+2,87% | 288,21Δ +12,71+4,61% |
| Tiempo medio de fotograma, ms | 1,126Base | 1,097Δ −0,028−2,51% | 1,093Δ −0,032−2,87% | 1,101Δ −0,025−2,18% |
| P99 del tiempo de fotograma, ms | 3,370Base | 3,285Δ −0,085−2,53% | 3,241Δ −0,129−3,84% | 3,204Δ −0,167−4,95% |
| Diferencia media entre fotogramas consecutivos, ms | 0,351Base | 0,338Δ −0,013−3,64% | 0,335Δ −0,016−4,53% | 0,329Δ −0,022−6,30% |
| FPS medio: rango de dos ejecuciones | 884,85 – 891,72 | 908,79 – 913,59 | 914,55 – 914,57 | 907,57 – 908,59 |
Advanced Advanced obtuvo los FPS medios más altos: 914,56 frente a 888,29 de Clean, +2,96%. Expert Hardcore quedó ligeramente por debajo en FPS medios, pero registró el P1 más alto: 312,15 frente a 296,73, +5,20%. La etapa más agresiva no fue la mejor en todas las métricas.
Los FPS medios de cada ejecución equivalen a 1000 / среднее время кадра в мс. P1 equivale a 1000 / P99 времени кадра; P99 se calcula mediante interpolación lineal sobre los fotogramas ordenados. Los resultados de cada etapa son la media de dos resultados. Debajo de los valores se muestran las diferencias absoluta y relativa respecto a Clean. Para los FPS, un valor mayor significa más rapidez; para el tiempo de fotograma, un valor menor significa más rapidez. La fila 1% low se calcula por separado como 1000 / среднее время самых медленных 1% кадров y no coincide con P1.
Las ocho ejecuciones y los fotogramas largos
| Etapa / ejecución | Fotogramas | FPS medio | P1 FPS | P99, ms | Fotograma más largo, ms |
|---|---|---|---|---|---|
| Clean / 1 | 93.631 | 891,72 | 299,70 | 3,337 | 11,956 |
| Clean / 2 | 92.911 | 884,85 | 293,75 | 3,404 | 12,453 |
| Safe Advanced / 1 | 95.928 | 913,59 | 306,00 | 3,268 | 10,488 |
| Safe Advanced / 2 | 95.424 | 908,79 | 302,84 | 3,302 | 7,385 |
| Advanced Advanced / 1 | 96.030 | 914,55 | 307,77 | 3,249 | 11,177 |
| Advanced Advanced / 2 | 96.031 | 914,57 | 309,32 | 3,233 | 8,448 |
| Expert Hardcore / 1 | 95.295 | 907,57 | 310,07 | 3,225 | 9,144 |
| Expert Hardcore / 2 | 95.403 | 908,59 | 314,23 | 3,182 | 8,894 |
Todos los intervalos entre fotogramas son positivos y la secuencia temporal es monótona. Se conservan los fotogramas largos. Los fotogramas no son repeticiones independientes del experimento: aquí solo hay dos ejecuciones de FPS por etapa. El rango de la tabla muestra la variación entre esas dos ejecuciones, no un intervalo de confianza.
El uso medio de GPU fue de aproximadamente 74–76%, con picos de hasta 95–96%. Estos datos no permiten afirmar que todas las partes del escenario estén limitadas exclusivamente por la CPU. El campo PcLatency de CapFrameX no se utiliza como latencia física de «movimiento del ratón → luz en pantalla».
Frametime Variance: uniformidad de los fotogramas
Sección titulada « Frametime Variance: uniformidad de los fotogramas»Se utilizó el principio de la pestaña Variances de CapFrameX: el valor absoluto de la diferencia entre los tiempos de dos fotogramas consecutivos |tᵢ − tᵢ₋₁|, en milisegundos. Los pares se distribuyen en cinco intervalos: <2, 2–<4, 4–<8, 8–<12 y ≥12 мс. Es una métrica de las variaciones entre fotogramas consecutivos; aquí no se calcula la varianza estadística en ms². Los límites de los intervalos se contrastaron con el código fuente de CapFrameX v1.8.6.
En Expert Hardcore, la proporción de pares con una diferencia de 2 ms o más es del 4,091% frente al 5,879% de Clean. Esto equivale a −1,787 p. p., o −30,4% respecto a Clean. En Safe Advanced, la reducción es del 18,0%; en Advanced Advanced, del 26,1%. Estos porcentajes corresponden a la proporción de variaciones consecutivas de 2 ms o más, no al aumento de FPS ni a la precisión al apuntar.
| Diferencia entre fotogramas consecutivos | Clean | Safe Advanced | Advanced Advanced | Expert Hardcore |
|---|---|---|---|---|
| <2 ms | 94,1214% | 95,1774%Δ +1,0561 p. p. | 95,6581%Δ +1,5367 p. p. | 95,9087%Δ +1,7873 p. p. |
| 2–<4 ms | 5,8540% | 4,8038%Δ −1,0502 p. p. | 4,3226%Δ −1,5313 p. p. | 4,0693%Δ −1,7847 p. p. |
| 4–<8 ms | 0,0166% | 0,0162%Δ −0,0004 p. p. | 0,0172%Δ +0,0006 p. p. | 0,0210%Δ +0,0044 p. p. |
| 8–<12 ms | 0,0075% | 0,0026%Δ −0,0049 p. p. | 0,0021%Δ −0,0054 p. p. | 0,0010%Δ −0,0065 p. p. |
| ≥12 ms | 0,0005% | 0,0000%Δ −0,0005 p. p. | 0,0000%Δ −0,0005 p. p. | 0,0000%Δ −0,0005 p. p. |
En cada etapa se combinan los recuentos de pares de las dos ejecuciones, sin unir el último fotograma de una ejecución con el primero de la otra. El denominador equivale a la suma de N − 1 de las dos ejecuciones. Por tanto, las proporciones están ponderadas por el número de pares, a diferencia de la media de los dos valores de FPS. Los recuentos exactos se conservan en JSON y CSV; la tabla redondea las proporciones a cuatro decimales. CapFrameX las redondea antes, por lo que pueden diferir los últimos dígitos mostrados.
La mayor reducción se concentra en el intervalo 2–<4 ms. La proporción de variaciones de 4–<8 ms en Expert Hardcore es ligeramente superior a la de Clean: 0,0210% frente a 0,0166%. Se conservan todos los intervalos, incluidas las variaciones poco frecuentes. Con dos ejecuciones no se puede determinar si este cambio es reproducible.
Qué significa para apuntar: en este benchmark, los intervalos entre fotogramas se volvieron más uniformes según el umbral de 2 ms. La posible mejora de la fluidez visual del movimiento de la mira sigue siendo una hipótesis: la grabación de los intervalos entre fotogramas no mide la precisión al apuntar, el movimiento del ratón ni la latencia hasta que aparece la imagen. Esta serie no permite prometer «una puntería mucho mejor».
Conclusión y límites del resultado
Sección titulada « Conclusión y límites del resultado»En esta serie secuencial se registró una reducción de la actividad en segundo plano después del inicio de sesión. En el escenario seleccionado de CS2, las tres etapas posteriores dieron más FPS medios que el sistema Clean preparado. Resultado práctico en este equipo: aproximadamente 2–3% más FPS medios, aunque Advanced y Expert Hardcore destacan en aspectos distintos.
El estudio no determina la contribución de cada ajuste, un aumento universal, el tiempo de inicio de Windows ni la latencia física de entrada. Expert Hardcore incluye un cambio del plan de energía, por lo que se compara la etapa completa. Reducir el número de procesos no es, por sí solo, una medida del rendimiento en juegos.
Limitaciones: un PC, orden fijo de las etapas, una carga WPR completada por etapa, dos ejecuciones de FPS, inicio manual de la captura y una compilación Debug sin el hash guardado del archivo binario. Los efectos del orden, el calentamiento de las cachés y el mantenimiento en segundo plano no se separaron de los de la optimización. Durante el periodo de inactividad de Clean también se inició brevemente el Administrador de tareas; se conserva la ventana completa, sin recortar ningún tramo. Esta serie no incluye una reproducción independiente ni una restauración de control a Clean.
Antivirus y FPS
Sección titulada « Antivirus y FPS»No se recomienda desactivar el antivirus para aumentar los FPS. Esta serie compara conjuntos de cambios completos: no incluye una prueba con la única variable «protección activada / desactivada». Por tanto, no demuestra que el antivirus no tenga ningún efecto en los FPS ni mide por separado el ahorro de memoria que supondría desactivarlo.
Microsoft recomienda mantener activada la protección en tiempo real. Si se produce una carga notable, se puede utilizar el análisis del rendimiento de Microsoft Defender para encontrar la causa concreta.
Restauración del estado
Sección titulada « Restauración del estado»La restauración del estado original después de Expert Hardcore no se comprobó en estas mediciones. Para repetir la prueba con estados independientes, se debe restaurar una imagen Clean preparada de antemano y documentar la restauración. Las limitaciones generales de la reversión se describen en los límites de restauración de BoosterX.
Datos originales y nuevo cálculo
Sección titulada « Datos originales y nuevo cálculo»8 ETL · 8 CapFrameX JSON · tablas, gráficos y scripts de recálculo. Para ver los resultados, abre README.html dentro del archivo. Las grabaciones originales se conservaron sin modificar. Los dos archivos llamados infinst.exe también forman parte de la prueba de CS2.
SHA-256 del archivo7f20104f7eb46428e5e4f383515653b1320827be39fc171d1b5590210d0fbcdd
WPR, CSV · Todas las ejecuciones de FPS, CSV · Frametime Variance, CSV · Cálculos, JSON · Script de recálculo
En un único archivo se recopilaron los directorios originales de las cuatro etapas WPR completadas, el intento incompleto de Expert Hardcore, los ocho archivos JSON originales de CapFrameX, los scripts de grabación utilizados, la metodología, las tablas, los gráficos y el código fuente del nuevo cálculo. No se incluyen las pruebas smoke antiguas ni los archivos de servicio que las duplican. La presencia de un estado de verificación antiguo en los directorios originales no altera los cálculos presentados aquí a partir de los ETL.
Para analizar los ETL por cuenta propia se necesita Windows Performance Toolkit; para las grabaciones originales del juego se puede utilizar CapFrameX. El script analysis/analyze.py utiliza Python 3 y WPT 10+, no inicia ninguna grabación ni modifica el sistema. Las instrucciones están en README.html. Las sumas de comprobación permiten verificar que los archivos no se han modificado; no demuestran que las condiciones del experimento fueran las indicadas.
Las trazas del sistema se conservan en su forma original: contienen información técnica sobre la instalación de prueba, incluidos procesos, rutas locales e identificadores del sistema. No se afirma que el archivo esté anonimizado. No se incluyen el código fuente de la aplicación BoosterX ni archivos ejecutables de terceros.
Fuentes e historial
Sección titulada « Fuentes e historial»- Las grabaciones originales de esta serie y el script de nuevo cálculo están disponibles arriba.
- CS2 FPS BENCHMARK DUST2: descripción y limitaciones del mapa.
- Microsoft: análisis de CPU, muestras de CPU y cambios de contexto.
- Microsoft: xperf cswitch y límites temporales.
- Microsoft: recomendaciones para mantener la protección de Defender.
- Microsoft: contadores de memoria de procesos.
- CapFrameX: pestaña Variances y comparación de distribuciones.
- CapFrameX v1.8.6: cálculo original de Frametime Variance.
- Metodología general de investigación de Wiki.
Última revisión: 2026-10-25. Primera edición del 24 de octubre: cuatro etapas en un mismo PC físico, mediciones originales abiertas y nuevo cálculo. El 25 de octubre se añadieron las diferencias respecto a Clean, una tabla ampliada de FPS y Frametime Variance. El estudio fue preparado por el desarrollador de BoosterX. Para una verificación independiente se publican las grabaciones originales, las condiciones de la prueba y el script de nuevo cálculo.