Cómo investigamos Windows

En la sección «Investigación de Windows» verificamos afirmaciones técnicas concretas. En cada artículo explicamos qué comprobamos, en qué condiciones y a qué sistemas se aplica el resultado.

La existencia de un parámetro, su influencia en el funcionamiento del sistema y la ganancia de rendimiento requieren pruebas por separado.

Qué se considera una prueba

Utilizamos varios tipos independientes de evidencia:

1. Documentación primaria. Documentos oficiales de Microsoft, especificaciones y documentación del fabricante del equipo o de la aplicación.
2. Observación estática. Indicios de implementación en una versión concreta del componente. Tal observación está limitada a la compilación investigada y por sí sola no demuestra la ejecución de la ruta durante el funcionamiento.
3. Observación dinámica. Eventos del sistema, estado de los componentes y trazas obtenidas en el escenario descrito.
4. Medición controlada. Comparación de una métrica elegida de antemano con un cambio conocido y un retorno del estado verificado.
5. Reproducción. Repetición del resultado en una ejecución independiente, en otro sistema o compilación.

Los métodos internos de automatización de la recopilación y el procesamiento no se publican. Esto no cambia la exigencia de revelar la pregunta verificada, la configuración, las métricas, el número de ejecuciones y las limitaciones.

Estados de los materiales

Estado	Significado
Documentado	El comportamiento está descrito en una fuente pública primaria.
Observado	El evento o estado se detectó en el entorno indicado.
Medido	Se obtuvo una diferencia numérica según la metodología descrita.
Reproducido	El resultado se repitió de forma independiente.
No reproducido	El efecto declarado no se detectó en las condiciones indicadas.
Datos insuficientes	La metodología o la muestra no permiten llegar a una conclusión.

El estado se refiere a una afirmación concreta, y no automáticamente a todo el artículo. No utilizamos un porcentaje de confianza arbitrario ni declaramos un resultado universalmente probado sin verificarlo en otros sistemas.

Cómo se construye el experimento

Antes de la medición se fijan:

• una pregunta verificada;
• la variable independiente;
• la métrica principal y su unidad;
• Windows build, hardware relevante, controladores y versiones de las aplicaciones;
• un umbral prácticamente significativo;
• el método de retorno al estado inicial.

Comparamos el estado inicial y el modificado, luego verificamos el retorno. Cuando es posible, alternamos el orden de las ejecuciones por pares. Controlamos el calentamiento, la alimentación, las temperaturas y la carga en segundo plano; si esto no es posible, indicamos la limitación.

Los intervalos individuales de una misma traza muestran cambios a lo largo del tiempo, pero no se consideran repeticiones independientes. El resultado de una máquina virtual no puede trasladarse automáticamente a un ordenador físico. Para concluir sobre todos los dispositivos de una misma clase no basta con verificar un solo dispositivo.

Banco físico click-to-photon

Para las investigaciones de juegos utilizamos un banco de hardware propio. Mide físicamente la latencia completa desde la señal eléctrica del botón del ratón hasta el cambio de brillo del píxel en la pantalla, sin una estimación por software de ese intervalo.

La ruta principal está organizada así:

1. Un cable está soldado a la línea del botón izquierdo de un Logitech G PRO X SUPERLIGHT de primera generación. El flanco eléctrico inicia el temporizador de un Arduino Uno.
2. Ese mismo clic pasa por el controlador del ratón, USB, Windows, el juego, la cola de renderizado, la GPU y el monitor.
3. Un fotosensor fijado en la pantalla detiene el temporizador cuando el brillo de la zona de prueba cruza un umbral elegido de antemano.
4. Un resultado contiene el intervalo completo click-to-photon en milisegundos.

Tal inicio incluye deliberadamente el procesamiento por el controlador del ratón y su click debounce, pero no incluye el recorrido mecánico del botón hasta el cierre del contacto. No restamos la latencia del ratón del valor final. En la metodología actual de mediciones independientes de RTINGS para el G PRO X SUPERLIGHT se indican 2.5 ms por cable y 3.1 ms a través del receiver. La baja click latency medida hace de este ratón una parte estable y adecuada del banco, pero no convierte el resultado en la latencia pura de Windows o del juego.

Un microcontrolador HID independiente con formato Arduino Nano puede enviar clics a Windows automáticamente. Esta ruta se utiliza cuando hay que eliminar las diferencias de la pulsación manual y repetir la señal de entrada a un ritmo controlado. Responde a otra pregunta y no se mezcla con las series que parten de la línea física del botón del ratón.

En CS2 se utiliza el mapa de workshop BXLAT, donde el clic provoca un cambio predecible de la zona de prueba. Un escenario visual análogo se aplica en Valorant. La posición del fotosensor, la resolución, la frecuencia del monitor, el límite de FPS, el modo display scaling, el presentation mode y el umbral de luz se fijan para toda la serie comparada.

El estándar actual exige no menos de 300 clics válidos por estado. En las nuevas series conservamos la media, la desviación estándar, el mínimo, el máximo, los percentiles, incluido el P90, y la distribución para construir gráficos. Las activaciones erróneas, los excesos del tiempo de espera y los valores fuera del rango establecido de antemano los marcamos y los tenemos en cuenta al verificar la idoneidad de la serie.

Las investigaciones en este banco se llevan a cabo desde hace varios años, y el formato de almacenamiento ha cambiado durante ese tiempo. En la tabla pública de mediciones históricas hay series de 300 clics y series más antiguas de 100. Para parte de las pruebas antiguas solo se conservan AVG, STDDEV, MIN y MAX; los P90 o gráficos ausentes no se reconstruyen a partir de los agregados y se marcan directamente como no disponibles. Las nuevas series se publicarán con estadísticas ampliadas.

Qué se publica como resultado

El artículo contiene:

• una respuesta breve;
• la afirmación verificada;
• el ámbito de la investigación;
• la metodología y el número de trazas independientes;
• los valores de las métricas y la dispersión;
• las conclusiones confirmadas y no confirmadas;
• las métricas excluidas o contaminadas;
• las limitaciones;
• una recomendación práctica sin garantía de un resultado idéntico;
• la confirmación del retorno del estado;
• las fuentes públicas primarias y la fecha de verificación.

Si el resultado no confirmó una recomendación popular o una función de BoosterX, aun así puede publicarse. La presencia de un ajuste en el producto no es prueba de su eficacia.

Cómo verificar por cuenta propia

Una parte significativa de las observaciones dinámicas de nuestras investigaciones se reproduce con herramientas públicas: Sysinternals ProcMon para las trazas del sistema y WinDbg con los símbolos públicos de Microsoft. La ruta básica de verificación es así.

1. Lectura del parámetro — ProcMon. Abra Options → Configure Symbols e indique el servidor público de símbolos de Microsoft para que las pilas muestren los nombres de módulos y funciones. Luego añada un filtro Path contains — por ejemplo SystemResponsiveness de HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfile. Por los eventos de lectura se ve si el valor se lee, cuándo y por qué proceso.
2. Quién lee — la pila de llamadas. Un doble clic en el evento abre sus propiedades; en la pestaña Stack se muestra la cadena de módulos — ese es el «lector» del parámetro. Por ejemplo, una cadena de user32.dll a win32kfull.sys significa que el valor es responsabilidad del subsistema Win32k.
3. Comportamiento en runtime — WinDbg. Con los símbolos públicos de Microsoft se puede poner un punto de interrupción en funciones de la pila y ver cómo se aplica el valor leído.
4. Pruebas sintéticas. Cambie el valor y mida el comportamiento observado. Por ejemplo, los intervalos de entrada del ratón se miden con testers públicos de frecuencia de sondeo.

Frontera honesta. El análisis estático de binarios y las trazas completas no se publican en los artículos. La ruta anterior reproduce la parte dinámica de nuestras observaciones, pero no sustituye el análisis estático — sus conclusiones se refieren a la compilación investigada.

Límites de la medición de la latencia

La latencia por software, la profundidad de la cola, el periodo del motor de audio, el tiempo de planificación del hilo y la latencia física completa describen magnitudes distintas. Por ejemplo, la cola de XAudio2 no determina todo el intervalo desde la acción del usuario hasta el sonido del altavoz. Para medirlo se necesita equipo externo.

De forma análoga, el tiempo de CPU de un proceso concreto no equivale a la influencia total en los FPS, el frametime, el consumo de energía o la capacidad de respuesta del sistema. Tales conclusiones se verifican con métricas separadas.

Protección de datos

Los ETL, PML, registros de eventos, volcados de memoria y exportaciones del registro originales no se publican por defecto. Las trazas del sistema pueden contener nombres de usuario, rutas, líneas de comandos, direcciones de red y otros datos sensibles. Microsoft lo advierte por separado en las condiciones de Sysinternals.

En el sitio se publican únicamente tablas seleccionadas manualmente y anonimizadas. Eliminamos los identificadores únicos de dispositivos e instalaciones, las rutas de usuario, los datos de cuentas, los identificadores de red, los datos de inicio de sesión y la información sobre procesos no relacionados con la investigación.

Corrección de conclusiones

Windows, los controladores y las aplicaciones cambian. Cada artículo recibe la fecha de la última verificación y el ámbito de aplicabilidad. Si una nueva medición contradice una conclusión antigua, el artículo se actualiza con la explicación del motivo. El resultado antiguo no se traslada automáticamente a una nueva compilación.

Independencia y marcas registradas

Las investigaciones las publica el equipo de BoosterX y pueden referirse a funciones del producto. Este posible conflicto de intereses se tiene en cuenta separando la metodología, los valores medidos, las limitaciones y los resultados negativos de la recomendación del producto.

BoosterX Wiki es una publicación independiente y no está vinculada, autorizada, patrocinada ni aprobada por Microsoft Corporation. Los nombres Microsoft y Windows se utilizan solo para describir con precisión el objeto de la investigación. Más detalles: Microsoft Trademark and Brand Guidelines.

Historial de cambios

• 2026-08-24: metodología publicada.
• 2026-09-20: añadida la sección «Cómo verificar por cuenta propia»; corregido el enlace a la fuente de datos del ratón.

Última verificación de la metodología: 2026-09-20.