Tartamudeos en juegos en PC rápido: latencia DPC y cómo solucionarlo

Qué es la latencia DPC (en términos simples del kernel)

Windows maneja eventos de hardware mediante interrupciones. Cuando tu tarjeta de red recibe paquetes, tu controlador USB detecta un evento de dispositivo o tu almacenamiento completa una E/S, el dispositivo genera una interrupción. La CPU interrumpe lo que hace, ejecuta una ISR (Rutina de Servicio de Interrupción) y luego normalmente programa una DPC (Llamada de Procedimiento Diferido) para hacer la mayor parte del trabajo más tarde a una prioridad de interrupción más baja.

Los DPC existen porque las ISR deben ser rápidas. Las ISR se ejecutan a un IRQL alto (nivel de petición de interrupción), donde el sistema no puede realizar muchas operaciones normales. Así que la ISR hace lo mínimo (reconocer el hardware, registrar estado) y encola una DPC, que se ejecuta después en DISPATCH_LEVEL. Sigue elevado. Sigue siendo crítico en tiempo. Y aún puede dejar sin CPU a otros trabajos si se ejecuta demasiado tiempo o con demasiada frecuencia.

Latencia DPC en el lenguaje cotidiano de tuning de PC realmente significa: “¿Cuánto tiempo tuvo que esperar trabajo importante porque otra cosa mantuvo la CPU en prioridad elevada?” A los juegos les importa porque necesitan tiempos de frame consistentes. Al audio le importa porque los buffers deben rellenarse a tiempo. La VR le importa porque perder fechas límite es náuseas, no solo molestia.

Una matiz clave: “latencia DPC” no es una sola métrica. Las herramientas reportan múltiples cosas relacionadas:

• Mayor tiempo de ejecución de ISR: un controlador pasó demasiado tiempo dentro de una ISR.
• Mayor tiempo de ejecución de DPC: la DPC de un controlador se ejecutó demasiado tiempo.
• Latencia interrupt-to-process: el tiempo desde que ocurre una interrupción hasta que un hilo en modo usuario vuelve a tener CPU.

Si te llevas una idea: el microtartamudeo suele ser una falla de frame pacing, y los picos de DPC/ISR son uno de los asesinos de pacing más comunes en máquinas por lo demás potentes.

Por qué un PC rápido sigue tartamudeando

Tu GPU puede estar ociosa y tu CPU al 20% y aún así puedes tartamudear. Eso es porque el problema no es el throughput; es la latencia. Throughput es “cuánto trabajo por segundo”. Latencia es “cuánto tarda en atenderse esta pieza específica de trabajo”. Los juegos son sistemas casi en tiempo real que fingen ser jobs por lotes. Funcionan hasta que dejan de hacerlo, y el modo de falla son tiempos de frame irregulares.

Los PCs modernos manejan muchas interrupciones. Polling USB, controladores RGB, ahorro de energía Wi‑Fi, pilas Bluetooth, mejoras de audio, telemetría del kernel, interrupciones de finalización de almacenamiento y la programación del driver de GPU todos quieren su porción. La mayor parte del tiempo, Windows arbitra bien. Pero un controlador que se comporta mal puede acaparar la prioridad elevada el tiempo suficiente para que un presupuesto de frame de 16.6 ms estalle a 40 ms y luego “se recupere” como si no hubiera pasado nada.

Otra cosa que sorprende: la gestión de energía es un intercambio. Estados C profundos, ahorro agresivo de paquete y gating de dispositivos pueden añadir latencia de activación. Esa latencia aparece como jitter. El sistema no está lento, está “dormido en los momentos equivocados”.

Realidad cruda: el mercado premia capturas de pantalla con FPS pico más que el aburrido pacing consistente. Los problemas DPC viven en la zona aburrida. Así que tienes que hacer tu propia operación.

Hechos y contexto histórico que puedes repetir en el trabajo

1. Los DPC fueron diseñados para mantener las ISR cortas. Por eso un “alto tiempo DPC” suele ser un controlador haciendo demasiado trabajo diferido en vez de bloquearse dentro de una ISR.
2. El audio hizo famosa a la latencia DPC. La primera oleada de reportes “mi laptop cruje” vino de cargas de audio en tiempo real que chocaban con malos controladores de Wi‑Fi y ACPI.
3. El scheduler multimedia de Windows (MMCSS) existe por una razón. Intenta priorizar hilos sensibles a tiempo (audio/video), pero no puede ganarle a una ISR/DPC que acapara un IRQL elevado.
4. Las interrupciones de finalización de almacenamiento son “baratas” hasta que no lo son. Dispositivos con altas IOPS pueden generar muchas interrupciones; si la ruta está mal afinada, obtienes jitter en vez de velocidad.
5. HPET se volvió un remedio popular. La gente activa/desactiva HPET porque a veces cambia el comportamiento del timer, pero no es una solución universal y puede ser placebo.
6. MSI (Message Signaled Interrupts) ayudó a escalar las interrupciones. MSI/MSI-X evita líneas de interrupción heredadas compartidas y puede reducir la contención—a menos que el driver o firmware tenga bugs.
7. La calidad del firmware ACPI varía mucho. Un “pequeño” bug de BIOS en un método de gestión de energía puede crear tormentas periódicas de DPC. Sí, tu placa base puede hacer eso.
8. Los controladores de red tienen una larga historia arruinando latencia. Offloads, coalescing y ahorro de energía son ganancias de throughput que pueden convertirse en pérdidas de latencia en cargas interactivas.
9. Los drivers de GPU son enormes y complejos. También están en modo kernel, y la complejidad no es una estrategia de optimización de latencia.

Síntomas y señales: cómo se manifiesta el “problema DPC”

En juegos

• “Cada 10–60 segundos, el juego se congela una fracción de segundo.”
• El contador de FPS parece alto, pero el gráfico de tiempo de frame muestra picos.
• Los tartamudeos empeoran cuando conectas/desconectas dispositivos USB, abres la superposición, te unes a chat de voz o cambias de ventana.
• Los tartamudeos desaparecen en un benchmark sintético pero aparecen en juego real (porque las interrupciones y E/S en segundo plano difieren).

En audio y streaming

• Chasquidos/pop en el audio, especialmente cuando el Wi‑Fi está activo.
• Desincronización de audio al grabar gameplay; el hilo del grabador falla en sus plazos.
• Voz en llamadas que suena “robotizada” bajo carga del sistema.

En comportamiento general del sistema

• Micro-titubeos del cursor que coinciden con eventos USB o actividad de almacenamiento.
• Picos periódicos en el uso de CPU del proceso “System” sin un culpable obvio en modo usuario.
• Advertencias en el Visor de Eventos sobre reinicios de controladores (gráficos, almacenamiento, red).

Broma #1: la latencia DPC es como una reunión que se pasa de tiempo—todos pueden ser brillantes, pero el horario igual muere.

Guía rápida de diagnóstico (primero/segundo/tercero)

Este es el “tienes una hora antes de rendirte y culpar al juego” camino. El objetivo no es perfeccionar el sistema; es aislar el dominio del cuello de botella.

Primero: confirma que es un problema de latencia/pacing, no de rendimiento bruto

• Usa un gráfico de tiempo de frame en el juego o una superposición que muestre tiempos de frame, no solo FPS.
• Si ves picos de ~8–16 ms a 30–100+ ms, estás en territorio de pacing.
• Si ves un aumento constante en el tiempo de frame con la temperatura, estás en territorio de throttling. Problema distinto.

Segundo: encuentra al mayor infractor ISR/DPC

• Ejecuta LatencyMon por 5–10 minutos mientras reproduces el tartamudeo.
• Ordena los controladores por mayor tiempo de ISR y DPC.
• Busca culpables familiares: controladores de red, pila del driver de GPU, ACPI, controlador de almacenamiento, bus de audio, controlador host USB.

Tercero: aisla deshabilitando/quitar clases enteras de dispositivos

• Prueba con Ethernet vs Wi‑Fi (o deshabilita Wi‑Fi por completo).
• Desconecta dispositivos USB no esenciales (especialmente interfaces de audio, dispositivos de captura, hubs, controladores RGB).
• Desactiva temporalmente overlays, “mejoras” de audio y utilidades de sistema de terceros.
• Cambia el plan de energía a Alto rendimiento (o equivalente) y vuelve a probar.

Si puedes hacer que el tartamudeo se detenga quitando un dispositivo o deshabilitando un driver, ya ganaste. Ahora solo queda limpiar.

Herramientas y métodos: qué usar y en qué no confiar

LatencyMon: bueno para “quién”, no para “por qué”

LatencyMon es una forma rápida de responder: ¿qué controlador muestra actualmente los peores tiempos de ISR/DPC? No es un profiler de grado forense. Muestrea e infiere. Pero para triage, es excelente.

Visor de eventos de Windows: bueno para “algo se reinició”

Los reinicios de controladores (como TDR de GPU) y los timeouts de almacenamiento dejan registros. Los logs no te dicen sobre cada microtartamudeo, pero pueden explicar los grandes.

ETW/WPR/WPA: lo mejor para “por qué”, pero más lento de aprender

Event Tracing for Windows (ETW) es el sustrato real de instrumentación. Windows Performance Recorder (WPR) recoge trazas; Windows Performance Analyzer (WPA) las visualiza. Si necesitas probar la causa raíz, ETW es la herramienta adulta.

Videos de “un ajuste que lo arregla todo”: entretenimiento, no operaciones

La mayoría de las guías de tuning masivo son montones de cambios en el registro que mueven problemas. En términos SRE, son deriva de configuración no revisada. Evítalas. Quieres cambios dirigidos vinculados a una medición.

Una cita, idea parafraseada: la mentalidad “duro y competente” de Gene Kranz aplica aquí: mantén disciplina, conserva la calma y arregla lo que puedas probar. (idea parafraseada)

Tareas prácticas (con comandos, salidas y decisiones)

Estas son tareas reales que puedes ejecutar en Windows. La mayoría usan herramientas integradas. Para herramientas de terceros como LatencyMon, el “comando” es básicamente “ejecutar la app”, pero aún puedes automatizar la recolección de evidencias alrededor.

Task 1: Identifica tu build de Windows y tiempo de actividad (los reinicios pendientes importan)

cr0x@server:~$ systeminfo | findstr /B /C:"OS Name" /C:"OS Version" /C:"System Boot Time"
OS Name:                   Microsoft Windows 11 Pro
OS Version:                10.0.22631 N/A Build 22631
System Boot Time:          2/5/2026, 8:14:22 AM

Qué significa: Si llevas semanas sin reiniciar, puedes arrastrar estado de drivers, problemas de energía de dispositivos o restos de actualizaciones.

Decisión: Si el uptime es alto y el problema es nuevo, reinicia antes de una cirugía más profunda. Sí, en serio.

Task 2: Busca throttling térmico/potencia obvio (elimina la guerra equivocada)

cr0x@server:~$ powercfg /energy /duration 10
Enabling tracing for 10 seconds...
Analyzing trace data...
Energy efficiency problems were found.
See C:\Windows\system32\energy-report.html for more details.

Qué significa: Este informe suele marcar dispositivos que se niegan a dormir, configuraciones de energía mal hechas y solicitudes de resolución de timer de plataforma.

Decisión: Si ves repetidas “Platform Timer Resolution” requests y persigues un tartamudeo, anota la app/driver culpable para correlación posterior—no lo elimines de inmediato.

Task 3: Confirma tu plan de energía activo (y deja de fingir que Balanced siempre está bien)

cr0x@server:~$ powercfg /getactivescheme
Power Scheme GUID: 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c  (High performance)

Qué significa: Balanced puede estar bien, pero los estados de inactividad agresivos pueden añadir jitter en algunos sistemas.

Decisión: Para diagnóstico, cambia a Alto rendimiento (o “Ultimate Performance” en estaciones) para reducir variables.

Task 4: Enumera drivers con fechas de instalación recientes (lista “¿qué cambió?”)

cr0x@server:~$ driverquery /v /fo table | findstr /I "Running"
nvlddmkm             Display                 Running   5/10/2025  NVIDIA Windows Kernel Mode Driver
rt640x64              Network                 Running   11/3/2025  Realtek PCIe GbE Family Controller
USBXHCI               USB                     Running   10/1/2025  USB xHCI Compliant Host Controller

Qué significa: Esto no es una medición de latencia. Es un inventario. El objetivo es identificar pilas candidatas (GPU, NIC, USB, audio, almacenamiento).

Decisión: Si el problema empezó después de actualizar un driver, esa es tu primera prueba de rollback—especialmente GPU y NIC.

Task 5: Busca errores WHEA (la inestabilidad silenciosa causa latencia “rara”)

cr0x@server:~$ wevtutil qe System /q:"*[System[(EventID=17 or EventID=18 or EventID=19) and Provider[@Name='Microsoft-Windows-WHEA-Logger']]]" /c:5 /f:text
Event[0]:
  Provider Name: Microsoft-Windows-WHEA-Logger
  Event ID: 17
  Level: Warning
  Description:
  A corrected hardware error has occurred.

Qué significa: Errores corregidos (a menudo PCIe) pueden crear reintentos, stalls y efectos colaterales en drivers. No siempre, pero lo suficiente como para respetarlo.

Decisión: Si aparecen advertencias WHEA durante el juego, reduce overclocks de CPU/RAM/GPU y actualiza BIOS/chipset antes de perseguir tweaks exóticos de DPC.

Task 6: Captura reinicios del driver GPU y errores gráficos

cr0x@server:~$ wevtutil qe System /q:"*[System[(EventID=4101) and Provider[@Name='Display']]]" /c:3 /f:text
Event[0]:
  Provider Name: Display
  Event ID: 4101
  Level: Warning
  Description:
  Display driver nvlddmkm stopped responding and has successfully recovered.

Qué significa: Este es un evento de martillo grande. Si ocurre, no tienes un “tartamudeo misterioso”, tienes un problema de driver/OC/estabilidad de energía.

Decisión: Arregla la estabilidad primero: revierte OC/undervolt de GPU, confirma PSU/cableado, instala limpiamente el driver de GPU y vuelve a probar la latencia.

Task 7: Comprueba rápidamente la salud del almacenamiento (los timeouts se sienten como tartamudeos)

cr0x@server:~$ wmic diskdrive get model,status
Model                               Status
Samsung SSD 990 PRO 2TB              OK
WDC WD10EZEX-08WN4A0                 OK

Qué significa: “OK” es superficial. No mostrará problemas límites de firmware NVMe o problemas de cable, pero detecta fallos obvios.

Decisión: Si algún disco no está OK, detente. Arregla la salud del almacenamiento antes de perseguir latencia. Si todo está OK, sigue pero mantén el almacenamiento en la lista de sospechosos.

Task 8: Busca timeouts de storport/disk en logs (generador clásico de hitch)

cr0x@server:~$ wevtutil qe System /q:"*[System[(EventID=129) and Provider[@Name='storahci']]]" /c:3 /f:text
Event[0]:
  Provider Name: storahci
  Event ID: 129
  Level: Warning
  Description:
  Reset to device, \Device\RaidPort0, was issued.

Qué significa: Los resets de almacenamiento causan stalls. Incluso si el juego está en otra unidad, el SO puede bloquearse en I/O del sistema.

Decisión: Actualiza drivers de chipset/almacenamiento, revisa cables SATA, actualiza firmware de SSD y considera mover unidades problemáticas fuera del sistema.

Task 9: Inspecciona ajustes avanzados del adaptador de red (la moderación de interrupciones puede ser tu enemigo)

cr0x@server:~$ netsh interface show interface
Admin State    State          Type             Interface Name
Enabled        Connected      Dedicated        Ethernet
Enabled        Disconnected   Dedicated        Wi-Fi

Qué significa: Muestra qué interfaces están arriba. Los drivers Wi‑Fi son frecuentes culpables de DPC cuando están conectados.

Decisión: Para diagnóstico, desactiva Wi‑Fi si estás en Ethernet, o viceversa. Reduce la pila activa.

Task 10: Desactiva Wi‑Fi temporalmente (prueba dura de aislamiento)

cr0x@server:~$ netsh interface set interface name="Wi-Fi" admin=disabled
Ok.

Qué significa: Has eliminado una pila de drivers entera de la ruta de interrupción.

Decisión: Si el tartamudeo desaparece, no “optimizas Windows”. Arreglas o reemplazas el driver/hardware Wi‑Fi, o ajustas sus parámetros.

Task 11: Comprueba si el Modo Juego está habilitado (no es magia, pero reduce algo de caos de fondo)

cr0x@server:~$ reg query "HKCU\Software\Microsoft\GameBar" /v AllowAutoGameMode
HKEY_CURRENT_USER\Software\Microsoft\GameBar
    AllowAutoGameMode    REG_DWORD    0x1

Qué significa: El Modo Juego puede reducir alguna actividad de fondo y mejorar decisiones de scheduling para juegos.

Decisión: Si está desactivado, actívalo para pruebas de consistencia. Si está activado y tienes problemas, no lo culpes inmediatamente—mide primero.

Task 12: Comprueba HAGS (Hardware-accelerated GPU scheduling)

cr0x@server:~$ reg query "HKLM\SYSTEM\CurrentControlSet\Control\GraphicsDrivers" /v HwSchMode
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\GraphicsDrivers
    HwSchMode    REG_DWORD    0x2

Qué significa: Los valores varían por versión; comúnmente, habilitado vs deshabilitado se representa por distintos DWORD. El punto es: puedes confirmar el estado.

Decisión: Si ves picos DPC relacionados con GPU, prueba A/B HAGS (cambias, reinicias, vuelves a medir). Mantén lo que produzca menos picos y mejor pacing.

Task 13: Comprueba aislamiento de núcleo / integridad de memoria (puede afectar comportamiento de drivers)

cr0x@server:~$ reg query "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v Enabled
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity
    Enabled    REG_DWORD    0x1

Qué significa: La integridad de memoria (HVCI) mejora seguridad pero puede cambiar características de ejecución de drivers y compatibilidad.

Decisión: No la apagues como primer movimiento. Solo prueba A/B si la evidencia apunta a un driver problemático y aceptas el intercambio de seguridad.

Task 14: Inventario rápido de dispositivos USB (elimina vecinos ruidosos)

cr0x@server:~$ pnputil /enum-devices /class USB | findstr /I "Device Description"
Device Description: USB Composite Device
Device Description: USB Root Hub (USB 3.0)
Device Description: USB Input Device

Qué significa: USB es un bosque. Esto te ayuda a recordar qué está conectado y qué puede generar interrupciones.

Decisión: Si tienes una cadena de hubs con audio + captura + RGB, simplifica. Conecta críticos directamente a la placa y prueba.

Task 15: Comprueba si el proceso “System” está subiendo de golpe (trabajo del kernel visible en herramientas de usuario)

cr0x@server:~$ typeperf "\Process(System)\% Processor Time" -sc 5
"(PDH-CSV 4.0)","\\DESKTOP\Process(System)\\% Processor Time"
"02/05/2026 09:12:01.123","0.000000"
"02/05/2026 09:12:02.125","3.000000"
"02/05/2026 09:12:03.126","28.000000"
"02/05/2026 09:12:04.128","4.000000"
"02/05/2026 09:12:05.129","2.000000"

Qué significa: Picos en CPU del proceso System pueden correlacionar con tormentas ISR/DPC, resets de almacenamiento, ráfagas de red o fallos de drivers.

Decisión: Si los picos del proceso System coinciden con los tartamudeos, procede a trazas ETW o a aislar pilas de drivers (NIC/USB/audio/almacenamiento/GPU).

Task 16: Captura una traza ETW base con WPR (modo “pruébalo”)

cr0x@server:~$ wpr -start generalprofile -filemode
WPR has started the profile.

cr0x@server:~$ wpr -stop C:\Temp\stutter.etl
WPR has stopped the profile.
The trace file has been saved as C:\Temp\stutter.etl.

Qué significa: Ahora tienes una traza que puedes abrir en Windows Performance Analyzer para ver DPC/ISR, scheduling de CPU, I/O de disco y más.

Decisión: Si LatencyMon apunta a un driver pero no puedes arreglarlo actualizando/revirtiendo/ajustando, ETW es cómo construyes un caso real (o decides reemplazar hardware).

Ruta de solución: drivers, BIOS, USB, audio, red, GPU, almacenamiento

1) Primero saneamiento de drivers: actualiza, luego revierte si hace falta

La mayoría de los problemas de latencia DPC son problemas de calidad de drivers. Tu primer movimiento es aburrido: asegúrate de usar versiones estables para chipset, NIC, audio y GPU. Pero “actualizar todo” también puede crear un nuevo problema. Trátalo como gestión de cambios:

• Actualiza una pila a la vez (GPU primero, luego chipset, luego NIC/audio).
• Reproduce el problema y mide después de cada cambio.
• Si no puedes reproducirlo después de un cambio, deja de cambiar cosas. Has terminado.

Sí, es más lento que actualizaciones a discreción. También es la forma de evitar convertir tu PC en un sitio de arqueología forense.

2) BIOS y chipset: donde la latencia va a esconderse

Si LatencyMon muestra ACPI.sys, Wdf01000.sys o picos periódicos extraños, el BIOS/firmware se vuelve sospechoso. Las actualizaciones de BIOS a menudo incluyen:

• Tablas ACPI mejoradas o métodos de gestión de energía.
• Actualizaciones AGESA/microcódigo que afectan el comportamiento de idle de la CPU.
• Fixes de compatibilidad PCIe para ciertas GPUs o unidades NVMe.

Pero no empieces a tocar cada ajuste del BIOS como si desactivaras una bomba. Usa un conjunto pequeño de pruebas de alto impacto:

• Desactiva “Global C-state control” como prueba A/B diagnóstica, no como estilo de vida.
• Desactiva spread spectrum solo si persigues inestabilidad de reloj (raro).
• Asegura que XMP/EXPO sea estable; RAM inestable puede parecer “tartamudeo aleatorio”.

3) Red: moderación de interrupciones vs latencia

Las NIC están optimizadas para throughput. El gaming es sensible a latencia. Dos perillas comunes dañan a la gente:

• Interrupt Moderation: agrupa interrupciones para reducir overhead de CPU. Genial para servidores. A veces malo para juegos/audio.
• Energy Efficient Ethernet / ahorro de energía: puede introducir retrasos o renegociación de enlace rara.

Estrategia de prueba: si deshabilitar Wi‑Fi o cambiar ajustes de NIC hace desaparecer el tartamudeo, conserva el cambio y documéntalo. Si necesitas Wi‑Fi, prueba otra versión del driver o un adaptador distinto. El hardware puede ser malo.

4) USB: el patrón del hub del doom

USB es engañosamente complejo. Hubs, endpoints isócronos de audio, ratones con alta tasa de muestreo, dispositivos de captura y periféricos “inteligentes” pueden generar interrupciones frecuentes. Dos tácticas funcionan en la práctica:

• Mueve dispositivos críticos (ratón, teclado) a puertos de placa base, no a hubs frontales.
• Evita apilar: no pongas interfaz de audio + webcam + captura + controlador RGB en el mismo hub/controlador si puedes evitarlo.

A veces la solución es literalmente: desenchufa el controlador de tiras LED de 12€. Humillante, pero efectivo.

5) Audio: mejoras, modo exclusivo y la victoria del “pipeline simple”

El crujido de audio es uno de los indicadores más limpios de problemas DPC. El audio de Windows corre con plazos. Si fallas, lo oyes. Ojo con:

• “Mejoras” (surround virtual, supresión de ruido, capas DSP del fabricante) que añaden CPU y complejidad de drivers.
• Dispositivos de audio virtual de terceros.
• Auriculares Bluetooth (pila compleja, negociación de códecs, ahorro de energía).

Si el audio forma parte de tus síntomas, simplifica el pipeline de audio como prueba: desactiva mejoras, elimina dispositivos no usados y prueba con unos auriculares cableados básicos en otro puerto.

6) GPU: drivers estables, overlays sensatos y consistencia de potencia

Las pilas de drivers de GPU son pesadas. También interactúan con cada overlay y herramienta de captura que instales. Si LatencyMon apunta a drivers GPU (nombres comunes incluyen dxgkrnl.sys y el módulo kernel del proveedor), tu ruta de solución es:

• Instalación limpia del driver GPU (evita “opcional/beta” mientras solucionas).
• Desactiva overlays uno por uno (Steam, Discord, GeForce Experience, herramientas de grabación).
• Comprueba eventos TDR (Event ID 4101). Si aparecen, trátalos como estabilidad.
• Prueba A/B HAGS y ajustes de modo de presentación.

Broma #2: el software RGB es la única carga que puede bajar tanto tus FPS como tu dignidad al mismo tiempo.

7) Almacenamiento: el tartamudeo no necesita alto uso de disco para ser relacionado con disco

El almacenamiento puede causar tartamudeo de tres maneras:

1. Eventos de timeout/reset (advertencias storahci/storport): el sistema pausa para recuperar una ruta de dispositivo.
2. Quirks de firmware/driver: bugs de firmware NVMe, estados de ahorro de energía del controlador o drivers con fallos pueden crear picos de latencia.
3. I/O en segundo plano: indexación, escaneos antivirus, escrituras de caché de shaders, actualizadores de juegos y herramientas de sincronización en la nube compitiendo en el momento equivocado.

Consejos prácticos de almacenamiento que aguantan en producción:

• Mantén firmware actualizado en NVMe, pero otra vez: un cambio a la vez.
• Asegura que el juego y su caché de shaders no estén en una unidad USB defectuosa o fallando.
• Vigila Event ID 129 resets; si los ves, deja de culpar al motor del juego.

8) El agujero de conejo de “modo MSI” y enrutamiento de interrupciones (usar con cuidado)

Message Signaled Interrupts puede reducir la contención por interrupciones compartidas, pero forzar el modo MSI vía herramientas de registro sin entenderlo también puede romper dispositivos o complicar el debug. Mi regla:

• Si no te sientes cómodo revirtiendo el cambio, no lo hagas.
• Si lo haces, fíjalo a un dispositivo a la vez (comúnmente GPU o NIC) y vuelve a medir.

Tres microrelatos corporativos (por qué esto no es solo un problema de jugadores)

Incidente causado por una suposición equivocada: “La red no puede afectar al audio”

En una empresa mediana con muchas reuniones remotas, el helpdesk empezó a recibir quejas: “Mi auricular USB cruje en las llamadas, pero solo por la tarde.” Las máquinas eran nuevas y rápidas, y el equipo de audio seguía cambiando auriculares como si fuera un problema de suministro.

La suposición equivocada fue sutil: trataban el audio como un problema de capa de aplicación. Los drivers eran “tuberías invisibles”. La primera pista real vino de un usuario que notó que el crujido empeoraba cuando empezaban sincronizaciones grandes de archivos. Un técnico ejecutó una herramienta de latencia durante una llamada y vio picos frecuentes atribuidos al driver Wi‑Fi y a un componente ACPI.

El patrón de la tarde no era un misterio. Era el entorno RF del edificio volviéndose más ruidoso a medida que llegaba gente, más una ventana programada de sincronización en segundo plano. El comportamiento de moderación de interrupciones y ahorro de energía del driver Wi‑Fi creó ráfagas de actividad ISR/DPC, que dejaron sin CPU al hilo de audio el tiempo justo para perder los deadlines de buffer.

La solución no fue “comprar mejores auriculares”. Desplegaron una versión estable del driver Wi‑Fi, desactivaron un ajuste específico de ahorro de energía en la política del adaptador y movieron las ventanas de sincronización pesadas fuera de las horas de reunión. El crujido desapareció. El pipeline de audio estaba bien; el pipeline de interrupciones no lo estaba.

Una optimización que salió mal: “Activemos todas las funciones de offload”

En otro entorno—piensa en estaciones de trabajo de ingeniería y virtualización local—alguien decidió “optimizar el rendimiento de red” habilitando un conjunto de funciones NIC en toda la flota. El objetivo era legítimo: reducir uso de CPU durante transferencias grandes y mejorar throughput para builds e imágenes de VM.

El throughput mejoró en el papel. El uso de CPU cayó en el dashboard. Todos se felicitaron y siguieron adelante, porque a los dashboards les encantan los promedios.

Luego llegaron las quejas: lag interactivo en sesiones de escritorio remoto, titubeos en demos y glitches de audio durante screen sharing. Las máquinas seguían “rápidas”, pero la experiencia humana se degradó. Las cargas sensibles a latencia pagaron el precio por el batching y coalescing.

Revirtieron un subconjunto de ajustes: la moderación de interrupciones quedó en “adaptive”, se deshabilitaron algunos offloads para adaptadores específicos y se suavizó el ahorro de energía. El throughput siguió siendo suficiente y la experiencia interactiva se recuperó. La lección fue clásica SRE: optimizar una métrica sin un SLO de latencia es cómo creas dolor de usuario invisible.

Una práctica aburrida pero correcta que salvó el día: “Control de cambios y baselines”

Las máquinas de build de un estudio de juegos también hacían de rigs de captura para material de marketing. Cada pocas semanas, alguien actualizaba “los drivers que parecían viejos”, porque los rigs no se consideraban producción. Entonces, justo antes de una entrega, las sesiones de captura empezaron a mostrar picos en el pacing de frames y fotogramas de audio perdidos.

Un ingeniero finalmente impuso una regla aburrida: cada rig tendría una imagen base, un manifiesto de drivers y un registro de cambios. Las actualizaciones ocurrirían solo en ventana de mantenimiento, un componente a la vez, con una prueba de captura reproducible corta y una traza guardada.

La siguiente vez que apareció el tartamudeo, llevaría menos de una hora aislarlo: un driver de un dispositivo USB de captura actualizado recientemente empezó a generar mayores tiempos DPC bajo ciertas resoluciones. Revirtieron el driver, abrieron ticket al proveedor con una traza adjunta y cumplieron el plazo.

Esto no fue heroísmo. Fue la disciplina poco sexy de las baselines. En sistemas de producción, lo aburrido suele ser sinónimo de fiable.

Errores comunes: síntoma → causa raíz → arreglo

• Síntoma: “Tartamudeos cada pocos segundos, especialmente online.”
  Causa raíz: picos DPC del driver NIC/Wi‑Fi; moderación de interrupciones/ahorro de energía; versión de driver con bug.
  Arreglo: Desactiva Wi‑Fi para probar; actualiza o revierte driver NIC; ajusta interrupt moderation; desactiva EEE/ahorro de energía para diagnóstico.
• Síntoma: “El audio cruje al jugar o en llamadas.”
  Causa raíz: starvation DPC desde Wi‑Fi, USB o ACPI; mejoras de audio que añaden procesamiento; tamaño de buffer demasiado pequeño para un sistema inestable.
  Arreglo: Simplifica la cadena de audio (desactiva mejoras), mueve el dispositivo a otro controlador USB, prueba Ethernet cableado, actualiza chipset/BIOS.
• Síntoma: “Hitch enorme aleatorio, luego todo bien.”
  Causa raíz: reset de almacenamiento (Event ID 129) o TDR de GPU (Event ID 4101).
  Arreglo: Para almacenamiento: firmware, cables, drivers del controlador. Para GPU: revierte OC/undervolt, instalación limpia del driver, revisa entrega de energía.
• Síntoma: “Solo tartamudea con muchos dispositivos USB conectados.”
  Causa raíz: sobrecarga de hub/controlador USB; driver problemático de periférico; contención de dispositivos isócronos.
  Arreglo: Reduce la cadena de hubs, conecta dispositivos críticos directamente, elimina software de control RGB, actualiza drivers del controlador USB/chipset.
• Síntoma: “Los tartamudeos empezaron tras una actualización de BIOS.”
  Causa raíz: cambios en defaults de gestión de energía; entrenamiento de memoria inestable; comportamiento PCIe alterado.
  Arreglo: Restaura BIOS a valores por defecto, reaplica solo ajustes necesarios, confirma estabilidad de RAM, considera revertir BIOS si existe una opción estable.
• Síntoma: “LatencyMon muestra ACPI.sys o Wdf01000.sys.”
  Causa raíz: A menudo un proxy: un driver de dispositivo que interactúa con ACPI, gestión de energía o un driver de framework causando stalls.
  Arreglo: Correlaciona con cambios de dispositivo (USB/NIC), actualiza BIOS/chipset, desactiva C-states profundos como prueba y luego reduce dispositivos deshabilitándolos para estrechar el culpable.
• Síntoma: “Solo tartamudea al grabar/streaming.”
  Causa raíz: hooks de overlay/captura, presión en la programación de GPU, escrituras de almacenamiento, picos DPC de dispositivo de captura USB.
  Arreglo: Prueba sin overlays, cambia método de captura, mueve la grabación a otra unidad, actualiza drivers del dispositivo de captura, traza ETW para confirmar.
• Síntoma: “Todo bien en benchmarks pero no en juego real.”
  Causa raíz: Los benchmarks no disparan las mismas interrupciones (voz, red, anti‑cheat, escrituras de caché de shaders).
  Arreglo: Mide mientras reproduces el escenario real; aísla desactivando red/USB/overlays; usa traza WPR.

Listas de verificación / plan paso a paso

Checklist A: triage de 30 minutos (sanidad mínima viable)

1. Reinicia. No negocies este paso.
2. Cambia el plan de energía a Alto rendimiento para las pruebas.
3. Desactiva overlays (un clic cada uno) y vuelve a probar.
4. Desconecta USB no esenciales y vuelve a probar.
5. Desactiva Wi‑Fi (o Ethernet) y vuelve a probar con una sola ruta de red.
6. Ejecuta LatencyMon durante 10 minutos mientras reproduces el tartamudeo; anota los 3 principales infractores ISR/DPC.
7. Revisa el Visor de Eventos por TDR GPU (4101), advertencias WHEA (17/18/19) y resets storport/storahci (129).

Checklist B: progresión de arreglos (control de cambios para un PC)

1. Haz una baseline: registra versiones de drivers (GPU/NIC/chipset), versión de BIOS, build de Windows.
2. Estabilidad primero: elimina overclocks/undervolts; confirma que WHEA esté quieto bajo carga.
3. Actualiza BIOS/chipset si ACPI/drivers de framework aparecen y estás varias versiones atrás.
4. Driver GPU A/B: instalación limpia, luego prueba HAGS on/off, luego prueba overlays.
5. Tunning de red: elige un adaptador, una versión de driver; ajusta interrupt moderation si hace falta.
6. Simplificación USB: reestructura puertos y hubs; elimina suites de control del fabricante temporalmente.
7. Validación de almacenamiento: busca resets/timeouts; actualiza firmware SSD; mueve juego/grabación fuera de dispositivos sospechosos.
8. Prueba con ETW: si sigues atascado, captura una traza e identifica el cuello de botella de scheduling.

Checklist C: lista de “no hagas esto” (cómo la gente pierde días)

• No apliques 30 tweaks de registro de un video y luego preguntes cuál ayudó.
• No desactives características de seguridad primero. Arregla drivers y estabilidad primero.
• No cambies ajustes de BIOS al azar. Prueba A/B una variable y mide.
• No culpes al juego hasta verificar que el sistema no registre resets de hardware o drivers.

Preguntas frecuentes

1) ¿Cuál es un número “malo” de latencia DPC?

No hay un umbral universal porque las cargas difieren. Para juegos/audio, te importan los picos. Un sistema que está bajo la mayor parte del tiempo pero salta a ejecuciones DPC/ISR de varios milisegundos aún puede tartamudear.

2) ¿Por qué LatencyMon culpa tan seguido a ACPI.sys?

Porque ACPI participa en gestión de energía y control de dispositivos. ACPI.sys puede ser el mensajero, no el criminal. Busca qué correlaciona: eventos de energía de dispositivos, picos periódicos y qué pilas de dispositivos cambiaron recientemente.

3) ¿Puede el almacenamiento realmente causar microtartamudeo aunque el uso de disco sea bajo?

Sí. Un evento de timeout/reset trata sobre latencia, no utilización. Un reset de ruta puede bloquear hilos que esperan la finalización de una E/S, aunque los MB/s totales sean ínfimos.

4) ¿Debo desactivar los C-states?

Como prueba A/B diagnóstica, sí—a veces. Como optimización permanente “para jugar”, generalmente no. Puede aumentar consumo y calor en idle. Úsalo para confirmar que la latencia de wake está involucrada, luego busca una actualización de firmware o mejor afinamiento.

5) ¿Es HPET on/off la solución?

A veces cambia el comportamiento del timer lo suficiente como para alterar los síntomas, pero no es una solución fiable de causa raíz. Si alternar HPET ayuda, tómalo como una pista de que el comportamiento de timing/scheduling importa y luego investiga drivers y gestión de energía.

6) ¿Por qué los overlays y herramientas de captura causan tartamudeos?

Enganchan pipelines de render, programan trabajo GPU/CPU y añaden componentes de driver. Si se comportan mal o pelean con anti‑cheat o la programación de la GPU, pueden añadir jitter. Desactívalos para aislar.

7) Mi PC solo tartamudea cuando el Wi‑Fi está activado. ¿Cuál es la solución real?

Primero, confirma desactivando Wi‑Fi y volviendo a probar. Luego: prueba otra versión del driver, desactiva ahorro de energía del adaptador, ajusta interrupt moderation o reemplaza el adaptador. Si usas un dongle Wi‑Fi USB barato, esa es la señal.

8) ¿El plan “Alto rendimiento” siempre ayuda?

Reduce algunas transiciones de ahorro de energía y puede reducir jitter, así que suele ayudar en diagnóstico. Para uso diario puedes volver a Balanced una vez arregles el culpable real, o mantener un plan por juego si prefieres consistencia.

9) ¿Es seguro desinstalar drivers aleatorios que aparecen en LatencyMon?

No. “Aparece” no es “seguro de eliminar”. Prefiere deshabilitar dispositivos temporalmente, revertir drivers o actualizar desde el OEM/proveedor del chipset. Si quitas algo incorrecto, puedes romper suspensión, audio, red o almacenamiento.

10) ¿Cuándo debo usar ETW (WPR/WPA) en vez de LatencyMon?

Cuando necesitas pruebas, cuando LatencyMon apunta a algo ambiguo o cuando los cambios no mueven la aguja. ETW puede mostrar scheduling de CPU, I/O de disco, timelines DPC/ISR y correlación con la ventana del tartamudeo.

Conclusión: próximos pasos que no desperdiciarán tu fin de semana

El tartamudeo en un PC rápido suele no ser un problema de potencia bruta. Es un problema de plazos. Algo en modo kernel mantiene la CPU en prioridad elevada el tiempo justo para arruinar el pacing de frames. Tu trabajo es identificar qué pila: red, USB, audio, GPU, almacenamiento o gestión de energía del firmware.

Haz esto a continuación:

1. Reproduce el tartamudeo a demanda (la misma escena del juego, mismos ajustes, mismos periféricos conectados).
2. Ejecuta LatencyMon durante 10 minutos durante la reproducción y anota los principales infractores.
3. Revisa el Visor de Eventos por reinicios GPU, advertencias WHEA y resets de almacenamiento.
4. Aísla desactivando Wi‑Fi, desenchufando dispositivos USB y desactivando overlays—un cambio a la vez.
5. Aplica arreglos dirigidos: rollback/actualización de drivers, actualización BIOS/chipset, ajuste del plan de energía, limpieza de topología USB.
6. Si aún estás atascado, captura una traza ETW con WPR y analiza DPC/ISR + scheduling de CPU alrededor del momento del tartamudeo.

Si tratas esto como respuesta a incidentes en vez de superstición, lo arreglarás—y sabrás exactamente qué arreglaste. Esa es la diferencia entre “tuneado” y “estable”.