pc-perf-audit

pc-perf-audit - auditoría de rendimiento medida, para cualquier PC

Destilado de meses de trabajo en una máquina real (Ryzen 7 5700X + RTX 2060, Valorant competitivo). Sirve para cualquier juego, cualquier CPU (Intel/AMD) y cualquier GPU (NVIDIA/AMD/Intel): el método es agnóstico; lo que cambia por juego (exe, config, log, anti-cheat, escenario de reclamo) está en references/juegos.md. Lo que vale aquí es el método y el catálogo de lo que ya se ha medido; los números de esa máquina son ejemplos, no receta para otra. Cuando un ejemplo mencione Valorant, léelo como "ejemplo de un juego".

Reglas que valen más que cualquier tweak

1. Tú no decides lo que es mejor para el dueño. Tú montas la prueba. Hipótesis, cambio reversible, él juega, tú recoges el veredicto.
2. Dos tipos de veredicto, nunca mezclar:
   • Medible (frametime, 1% low, hitches, latencia, estabilidad): decide el número.
   • Juzgable (nitidez, contraste, sonido, "feeling", visibilidad): decide solo el dueño, un cambio a la vez. Reporta ambas cosas por separado.
3. Una variable a la vez. Una sola partida no decide nada. Mínimo dos partidas, descartar el calentamiento, mirar la desviación minuto a minuto, no solo la media.
4. ¿No superó la línea base? Revierte. La ganancia visual no compra la caída de frametime (a menos que el dueño diga lo contrario, y aun así mide y reporta el costo).
5. Camino que no cuesta nada, siempre. Antes de proponer algo que cueste CPU/GPU/latencia/ riesgo, busca lo mismo en una capa más cercana a la salida de video o que no cobre (ej.: vibrance digital en el panel en lugar de filtro por cuadro; escalar en la GPU en lugar de en el monitor; limitador de FPS nativo del juego en lugar de limitador en el driver; cerrar app en lugar de tocar la prioridad).
6. NUNCA concluyas "la máquina está entregando lo que puede". "Dónde está el costo" y "se puede ejecutar más rápido" son preguntas diferentes: el código secuencial corre más rápido con mayor clock efectivo, menor latencia de memoria, menor disputa de caché.
7. Evidencia antes de afirmación. La teoría plausible ya ha tumbado varias rondas. No presentes hipótesis como resultado, no declares ganancia sin medición.
8. El instrumento también es carga. El medidor, recolector, vigía, overlay, y el propio agente (Claude, terminal, PowerShell) gastan CPU. Durante una captura: no uses la máquina.
9. Cuando la medición discrepe del usuario por días, sospecha de la medición antes de la percepción de él. Esto se repitió 4 veces (ver references/trampas.md).
10. Confirma solo lo que es arriesgado o irreversible (firmware, BIOS, seguridad, borrar datos). El resto: elige, di el porqué en una línea, sigue.
11. Reversibilidad: antes de cualquier cambio, registra el valor original y el comando de deshacer. Nada de dry-run que deje rastro; la simulación no toca el disco.

Etapas (sigue en orden; cada una tiene criterio de salida)

Etapa 0 - Perfil y objetivo (entrevista corta)

Pregunta (de una vez, con AskUserQuestion, no en conversación larga):

• Juego(s) principal(es), modo (competitivo/casual), meta (FPS objetivo, tasa del monitor). Para cada juego completa la ficha de references/juegos.md (exe, API, engine, config, log, anti-cheat, modo de prueba).
• Síntomas: microtartamudeos, caída al cambiar de disparo, congelación total, BSOD, corte de audio, input lag, parpadeo/serrado, pantalla negra. ¿Qué minuto/mapa/momento? (ancla la captura)
• Innegociables del dueño (no se toca ni se discute): sensibilidad, DPI, resolución, modo de pantalla estirada, mirilla, vibrance, apps que necesita abiertas (ej.: Discord).
• Lo que ya ha intentado y lo que ya ha estado bien/mal. ¿Hubo un día "perfecto"? ¿Cuándo?
• Anti-cheat del juego (Vanguard, EAC, BattlEye, FACEIT): limita afinidad, prioridad, inyección de overlay y drivers de terceros. Consulta references/catalogo-palancas.md sec. 11. Salida: perfil escrito en el diario (modelo en references/template-diario.md).

Etapa 1 - Inventario (solo lectura)

Ejecuta scripts/inventario.ps1 -Salida <carpeta> (PowerShell 5.1, preferiblemente elevado; sin elevación algunos campos salen vacíos y el script avisa). Recoge CPU, GPU, RAM (velocidad configurada vs nominal, voltaje), BIOS/placa, SO, plan de energía y EPP, MPO, HAGS, VBS/HVCI, Modo Juego, GameDVR, Secure Boot, Defender, servicios de actualización, NICs, discos, monitores, resolución/refresco, inicio, servicios y procesos de terceros, overlays conocidos, y conteo de eventos 6008/1001/WHEA. Lee inventario.txt y clasifica la plataforma: CPU: AMD Zen2/3/4/5 (X3D?) | Intel Core híbrido (P+E) | Intel Core no-híbrido, GPU: NVIDIA | AMD | Intel Arc | iGPU. Esto elige las secciones del catálogo. Salida: tabla "ítem -> valor -> ¿normal? -> hipótesis" en el diario. No cambies nada aún.

Etapa 2 - Higiene del entorno (lo que se ejecuta durante la partida)

Objetivo: entorno de partida conocido y limpio. Usa el inventario + Get-Process.

• Enumera lo que consume CPU en segundo plano (navegador, launcher, cloud sync, updaters, overlays, RGB, capturadores, el propio agente). Separa: cerrar, impedir que nazca, dejar (decisión del dueño).
• Prefiere impedir que nazca (StartupApproved, política, permiso de segundo plano de app de la Store) a matar cada N minutos. Verifica que el elemento de tu lista coincide de verdad con el nombre del proceso (un 'WhatsApp' que nunca coincidió con WhatsApp.Root sobrevivió 17 días).
• Updaters/servicios que se reinician solos (Windows Update, vendor updaters): decide contención y verifica que persista (ver trampas: el instalador recrea tarea/servicio).
• Overlays que inyectan DLL en el Present (RTSS/Afterburner OSD, Discord overlay, Steam, GeForce, Medal, OBS hook): costo pequeño pero en el hilo de render. Enuméralos, no los mates sin que el dueño lo sepa; medir el efecto es opcional (en esta máquina la ganancia no fue demostrable). Salida: lista de "apps durante la partida" + mecanismo de contención + cómo verificar.

Etapa 3 - Línea base medida

Protocolo completo en references/metodo.md. Resumen:

1. Juego cerrado, máquina asentada (5+ min tras arranque), nada nuevo abierto.
2. scripts/capturar.ps1 -Proceso <exe> -Segundos 420 -Rotulo <texto> durante una partida real en el modo/mapa de reclamo (DM descartable si PresentMon es riesgo). La captura no analiza (análisis en CPU/RAM durante la partida y carga).
3. Después de la partida, juego cerrado: python scripts/analizar-frametime.py <csv>.
4. Mínimo dos partidas, mismo mapa. La primera tras arranque/patch/driver es fría.
5. Pregunta el veredicto (nota/frase) y anótalo junto al número. Con 8+ capturas y veredictos, valida qué métrica correlaciona (rango) con lo que él siente y usa esa. Salida: línea base por escenario (¡DM y 5v5 son diferentes!) con hitches/min, peor cuadro, 1%/0.1% low, p99, desviación por minuto, y el veredicto de él.

Etapa 4 - Diagnóstico

Árbol en references/diagnostico.md. Preguntas en orden:

1. ¿CPU-bound o GPU-bound? (MsCPUBusy vs MsGPUBusy, mediana y en los cuadros malos)
2. ¿El problema es media o cola? (hitches/min, peor cuadro, graves >20 ms)
3. ¿Los hitches tienen desencadenante? (cambio de ronda, carga, reaparición, mapa, habilidad, fin de partida, patch/driver reciente = sombreado recompilando) - cruza con el log del juego.
4. ¿Algo externo disputa? (traza de kernel/ETW; ISR/DPC; I/O de disco; memoria libre; temperatura y clock) - solo concluye con el instrumento correcto.
5. Si es congelación/BSOD/corte de audio, es otro árbol (hardware/estabilidad/radio). Salida: hipótesis ordenadas por (probabilidad x costo de probar x reversibilidad).

Etapa 5 - Palancas (de la más barata a la más cara)

Consulta references/catalogo-palancas.md, solo las secciones de la plataforma detectada, y la lista de refutados antes de proponer cualquier cosa. Orden de ataque:

1. Capa que no cobra: scanout/display (escala en GPU, vibrance digital, tiempo de respuesta del monitor), Windows (MPO, plan de energía/EPP, actualización contenida, apps de fondo).
2. Velocidad del núcleo que ejecuta el hilo del juego: EPP/boost, límites de energía, SMT/E-cores, latencia y voltaje de memoria, FCLK/ring, Curve Optimizer/undervolt, refrigeración.
3. Estabilidad: voltaje de memoria, XMP/DOCP, BIOS, C-states, fuente, temperatura.
4. Config del juego: solo lo que reduce CPU por personaje (sombras, cuerpos, contadores); respetando los innegociables y lo que es información competitiva (sonido, sombra de enemigo).
5. Red/audio/periféricos: medir antes; los tweaks de red ya han empeorado 5x. Para cada palanca: valor original, comando de aplicar, comando de deshacer, hipótesis medible y lo que el dueño necesita juzgar.

Etapa 6 - Prueba A/B y veredicto

Para cada palanca (una a la vez): aplicar -> dos capturas en el mismo escenario -> comparar contra la línea base del mismo mapa/modo -> preguntar qué sintió -> decidir: ADOPTAR | REVERTIR | SIN VEREDICTO (más datos). Registra incluso las refutadas, con el número: la lista de refutados es el activo más valioso del proyecto. Regla de comparación: filtra la línea base por el estado de la máquina, no por la fecha. Si tocaste algo entre dos partidas, la serie se convierte en anécdota - rehaz.

Etapa 7 - Congelar el estado aprobado

Cuando el dueño diga "está bien, no quiero que regrese": fotografía el estado (BIOS, drivers, servicios, tareas, registro, energía, config del juego, inicio) en una lista de sondas con valor esperado, ejecútala periódicamente y después de parche/driver/BIOS. Reglas:

• Antes de congelar, ejecuta la comparación sin congelar y resuelve cada desviación (deliberada -> congela; regresión -> arregla). Congelar con desviación graba la regresión como oro.
• Congela con el juego cerrado y con la sesión elevada.
• Sonda que genera falsa alarma enseña a ignorar sonda: investiga el historial del valor.
• Sonda con nombre/valor de clave incorrecto es peor que sonda ausente: verifica contra el archivo real.
• Documenta lo que una grabación de BIOS/CMOS reseteado deshace en silencio (SMT, C-state, DOCP, voltaje de DRAM, Secure Boot, Resizable BAR, PBO) y la ruta de regreso.

Etapa 8 - Documentación viva

Mantén un diario (references/template-diario.md): estado actual, línea base, lista de refutados, trampas pagadas, pendientes en orden. Corrige entradas erróneas con retractación explícita al inicio, no borrando: el historial de errores evita reincidencia.

Cómo entregar resultados al usuario

• En español (o el idioma del dueño), directo. Una línea de por qué por decisión.
• Tabla por captura: escenario, hitches/min, peor cuadro, graves >20 ms, 1%/0.1% low, desviación, veredicto de él. Separa "lo que dice el número" de "lo que solo tú puedes decir".
• Nunca reportes FPS por segundo fijo como "lo que él ve": el contador del juego usa ventana corta.
• Marca cada afirmación: MEDIDO, HIPÓTESIS, LITERATURA (fuente), DECISIÓN DEL DUEÑO.

Archivos de esta skill

• references/metodo.md - protocolo de captura, métricas, recortes, validación de métrica.
• references/juegos.md - ficha por juego, marcadores de log, perfiles por género/engine, qué es universal vs específico.
• references/diagnostico.md - árbol de síntomas -> instrumento -> causa probable.
• references/catalogo-palancas.md - todo lo que se ha intentado/medido, por capa y fabricante.
• references/trampas.md - errores de instrumento y de razonamiento que ya costaron iteración.
• references/template-diario.md - modelo del diario/AGENTS.md de la máquina auditada.
• scripts/inventario.ps1 - inventario solo lectura (PS 5.1, ASCII).
• scripts/capturar.ps1 - captura PresentMon sin analizar + instantáneas de procesos.
• scripts/analizar-frametime.py - análisis offline robusto (Python 3 stdlib).