pc-perf-audit

pc-perf-audit – Leistungsaudit mit Messung, für jeden PC

Destilliert aus monatelanger Arbeit an einem realen System (Ryzen 7 5700X + RTX 2060, Valorant Wettkampf). Gilt für jedes Spiel, jede CPU (Intel/AMD) und jede GPU (NVIDIA/AMD/Intel): die Methode ist agnostisch; was sich pro Spiel ändert (EXE, Konfiguration, Log, Anti-Cheat, Beschwerde-Szenario) steht in references/jogos.md. Hier zählt die Methode und der Katalog des bereits Gemessenen; die Zahlen jener Maschine sind Beispiele, kein Rezept für eine andere. Wenn ein Beispiel Valorant nennt, lies es als „Beispiel für ein Spiel“.

Regeln, die mehr wert sind als jeder Tweak

1. Du entscheidest nicht, was für den Besitzer am besten ist. Du baust den Test auf. Hypothese, reversible Änderung, er spielt, du holst das Urteil ein.
2. Zwei Arten von Urteilen, niemals vermischen:
   • Messbar (Frametime, 1%-Low, Hitches, Latenz, Stabilität): entscheidet die Zahl.
   • Beurteilbar (Schärfe, Kontrast, Ton, „Gefühl“, Sichtbarkeit): entscheidet nur der Besitzer, eine Änderung nach der anderen. Berichte beides getrennt.
3. Eine Variable nach der anderen. Ein einziger Durchlauf entscheidet nichts. Mindestens zwei Durchläufe, Aufwärmphase verwerfen, die Abweichung Minute für Minute betrachten, nicht nur den Durchschnitt.
4. Baseline nicht erreicht? Rückgängig machen. Visueller Gewinn erkauft keinen Frametime-Einbruch (es sei denn, der Besitzer sagt etwas anderes, und selbst dann miss und berichte die Kosten).
5. Immer den Weg, der nichts kostet. Bevor du etwas vorschlägst, das CPU/GPU/Latenz/Risiko kostet, suche dasselbe in einer Schicht näher am Videoausgang oder das nichts verlangt (z.B. Digital Vibrance im Treiber-Panel statt Framefilter; Skalierung auf der GPU statt am Monitor; nativer FPS-Limiter des Spiels statt Treiber-Limiter; App schließen statt Priorität ändern).
6. NIE schlussfolgern „die Maschine gibt, was sie kann“. „Wo liegen die Kosten“ und „Kann man sie schneller ausführen“ sind unterschiedliche Fragen: serieller Code läuft schneller mit höherem effektivem Takt, geringerer Speicherlatenz, weniger Cache-Konkurrenz.
7. Beweis vor Behauptung. Plausible Theorie hat schon viele Durchläufe gekippt. Präsentiere keine Hypothese als Ergebnis, erkläre keinen Gewinn ohne Messung.
8. Auch das Messinstrument ist eine Last. Messprogramm, Sammler, Wächter, Overlay und der Agent selbst (Claude, Terminal, PowerShell) verbrauchen CPU. Während einer Aufnahme: benutze die Maschine nicht.
9. Wenn die Messung tagelang vom Benutzer abweicht, verdächtige zuerst die Messung, nicht seine Wahrnehmung. Das hat sich 4 Mal wiederholt (siehe references/armadilhas.md).
10. Bestätige nur, was riskant oder irreversibel ist (Firmware, BIOS, Sicherheit, Daten löschen). Alles andere: Entscheidung, erkläre warum in einer Zeile, mach weiter.
11. Reversibilität: Vor jeder Änderung notiere den Originalwert und den Rückgängig-Befehl. Kein Dry-Run, der Spuren hinterlässt; Simulation berührt keine Festplatte.

Schritte (in der Reihenfolge; jeder hat ein Ausstiegskriterium)

Schritt 0 – Profil und Ziel (kurzes Interview)

Frage (auf einmal, mit AskUserQuestion, nicht in einem langen Gespräch):

• Hauptspiel(e), Modus (Wettkampf/Casual), Ziel (angestrebte FPS, Monitor-Refresh). Fülle für jedes Spiel das Blatt in references/jogos.md aus (EXE, API, Engine, Konfiguration, Log, Anti-Cheat, Testmodus).
• Symptome: Mikroruckler, Ruckler beim Schusswechsel, komplettes Einfrieren, BSOD, Audioaussetzer, Input-Lag, Flimmern/Kantenflimmern, schwarzer Bildschirm. Welche Minute/Karte/Moment? (verankert die Aufnahme)
• Unverhandelbares des Besitzers (wird nicht verändert oder diskutiert): Empfindlichkeit, DPI, Auflösung, gestreckter Bildschirmmodus, Fadenkreuz, Vibrance, Apps, die er offen haben muss (z.B. Discord).
• Was hat er bereits versucht und was war gut/schlecht? Gab es einen „perfekten“ Tag? Wann?
• Anti-Cheat des Spiels (Vanguard, EAC, BattlEye, FACEIT): schränkt Affinität, Priorität, Overlay-Injektion und Treiber von Drittanbietern ein. Siehe references/catalogo-alavancas.md Abschnitt 11. Ausgabe: Profil im Tagebuch (Vorlage in references/template-diario.md).

Schritt 1 – Inventur (nur lesen)

Führe scripts/inventario.ps1 -Saida <pfad> aus (PowerShell 5.1, bevorzugt erhöht; ohne Erhöhung bleiben einige Felder leer und das Skript warnt). Es sammelt CPU, GPU, RAM (konfigurierte vs. nominale Geschwindigkeit, Spannung), BIOS/Board, OS, Energieplan und EPP, MPO, HAGS, VBS/HVCI, Spielmodus, GameDVR, Secure Boot, Defender, Update-Dienste, NICs, Festplatten, Monitore, Auflösung/Refresh, Autostart, Dienste und Prozesse von Drittanbietern, bekannte Overlays und Zählung der Ereignisse 6008/1001/WHEA. Lies inventario.txt und klassifiziere die Plattform: CPU: AMD Zen2/3/4/5 (X3D?) | Intel Core Hybrid (P+E) | Intel Core nicht-Hybrid, GPU: NVIDIA | AMD | Intel Arc | iGPU. Dies wählt die Abschnitte des Katalogs. Ausgabe: Tabelle „Element -> Wert -> normal? -> Hypothese“ im Tagebuch. Ändere noch nichts.

Schritt 2 – Umgebungshygiene (was während des Spiels läuft)

Ziel: bekannte und saubere Spielumgebung. Nutze das Inventar + Get-Process.

• Liste auf, was im Hintergrund CPU verbraucht (Browser, Launcher, Cloud-Sync, Updater, Overlays, RGB, Capture-Programme, der Agent selbst). Trenne: schließen, am Starten hindern, lassen (Entscheidung des Besitzers).
• Bevorzuge am Starten hindern (StartupApproved, Richtlinie, Hintergrund-App-Berechtigung aus dem Store), anstatt es alle N Minuten zu töten. Prüfe, ob der Eintrag deiner Liste wirklich mit dem Prozessnamen übereinstimmt (ein 'WhatsApp', das nie mit WhatsApp.Root übereinstimmte, überlebte 17 Tage).
• Updater/Dienste, die sich selbst neu starten (Windows Update, Vendor-Updater): entscheide über Eindämmung und überprüfe, dass sie anhält (siehe Fallstricke: Installer erstellt Aufgabe/Dienst neu).
• Overlays, die eine DLL in Present injizieren (RTSS/Afterburner OSD, Discord Overlay, Steam, GeForce, Medal, OBS Hook): kleine Kosten, aber im Rendering-Thread. Liste sie, töte sie nicht ohne Wissen des Besitzers; den Effekt zu messen ist optional (auf dieser Maschine war der Gewinn nicht nachweisbar). Ausgabe: Liste „Apps während des Spiels“ + Eindämmungsmechanismus + wie man es überprüft.

Schritt 3 – Gemessene Baseline

Vollständiges Protokoll in references/metodo.md. Zusammenfassung:

1. Spiel geschlossen, Maschine beruhigt (5+ Minuten nach Boot), nichts Neues geöffnet.
2. scripts/capturar.ps1 -Processo <exe> -Segundos 420 -Rotulo <text> während einer echten Partie im Beschwerde-Modus/Karte (DM ist entbehrlich, wenn PresentMon ein Risiko darstellt). Die Aufnahme analysiert nicht (CPU/RAM-Analyse während des Spiels ist eine Last).
3. Nach der Partie, Spiel geschlossen: python scripts/analisar-frametime.py <csv>.
4. Mindestens zwei Durchläufe, gleiche Karte. Der erste nach Boot/Patch/Treiber ist kalt.
5. Frage nach dem Urteil (Note/Satz) und notiere es neben der Zahl. Mit 8+ Aufnahmen und Urteilen validiere, welche Metrik (Rang) mit dem korreliert, was er fühlt, und verwende diese. Ausgabe: Baseline pro Szenario (DM und 5v5 sind unterschiedlich!) mit Hitches/min, schlechtestem Frame, 1%/0,1%-Low, p99, Abweichung pro Minute und seinem Urteil.

Schritt 4 – Diagnose

Baum in references/diagnostico.md. Fragen in der Reihenfolge:

1. CPU- oder GPU-gebunden? (MsCPUBusy vs MsGPUBusy, Median und bei schlechten Frames)
2. Ist das Problem der Durchschnitt oder der Ausreißer? (Hitches/min, schlechtester Frame, schwere >20 ms)
3. Haben die Hitches einen Auslöser? (Rundenwechsel, Laden, Respawn, Karte, Fähigkeit, Spielende, kürzlicher Patch/Treiber = Shader-Neukompilierung) – kreuz mit dem Spiellog.
4. Konkurriert etwas Externes? (Kernel/ETW-Trace; ISR/DPC; Festplatten-I/O; freier Arbeitsspeicher; Temperatur und Takt) – nur mit dem richtigen Instrument schlussfolgern.
5. Wenn es sich um Einfrieren/BSOD/Audioaussetzer handelt, ist es ein anderer Baum (Hardware/Stabilität/Funk). Ausgabe: Hypothesen geordnet nach (Wahrscheinlichkeit x Testkosten x Reversibilität).

Schritt 5 – Stellhebel (vom günstigsten zum teuersten)

Konsultiere references/catalogo-alavancas.md, nur die Abschnitte der erkannten Plattform, und die Liste der Widerlegten, bevor du etwas vorschlägst. Angriffsreihenfolge:

1. Schicht, die nichts kostet: Scanout/Display (GPU-Skalierung, Digital Vibrance, Monitor-Reaktionszeit), Windows (MPO, Energieplan/EPP, Updates eingedämmt, Hintergrund-Apps).
2. Geschwindigkeit des Kerns, der den Spielthread ausführt: EPP/Boost, Energie-Grenzen, SMT/E-Cores, Speicherlatenz und -spannung, FCLK/Ring, Curve Optimizer/Undervolt, Kühlung.
3. Stabilität: Speicherspannung, XMP/DOCP, BIOS, C-States, Netzteil, Temperatur.
4. Spielkonfiguration: nur das, was CPU pro Charakter reduziert (Schatten, Körper, Zähler); unter Respektierung des Unverhandelbaren und dessen, was Wettbewerbsinformation ist (Ton, Schatten des Gegners).
5. Netzwerk/Audio/Peripherie: vorher messen; Netzwerk-Tweaks haben bereits 5x verschlechtert. Für jeden Stellhebel: Originalwert, Anwendungsbefehl, Rückgängig-Befehl, messbare Hypothese und was der Besitzer beurteilen muss.

Schritt 6 – A/B-Test und Urteil

Für jeden Stellhebel (einer nach dem anderen): anwenden -> zwei Aufnahmen im gleichen Szenario -> mit der Baseline derselben Karte/Modus vergleichen -> fragen, was er gefühlt hat -> entscheiden: ÜBERNEHMEN | RÜCKGÄNGIG | KEIN URTEIL (mehr Daten). Dokumentiere auch die Widerlegten mit der Zahl: die Liste der Widerlegten ist der wertvollste Aktivposten des Projekts. Vergleichsregel: Filtere die Baseline nach dem Maschinenzustand, nicht nach dem Datum. Wenn sich zwischen zwei Durchläufen etwas geändert hat, ist die Serie eine Anekdote – wiederhole sie.

Schritt 7 – Genehmigten Zustand einfrieren

Wenn der Besitzer sagt „ist gut, ich will keinen Rückschritt“: fotografiere den Zustand (BIOS, Treiber, Dienste, Aufgaben, Registrierung, Energie, Spielkonfiguration, Autostart) in einer Liste von Sonden mit erwartetem Wert, führe sie regelmäßig und nach Patch/Treiber/BIOS aus. Regeln:

• Vor dem Einfrieren, führe den Vergleich ohne Einfrieren durch und behebe jede Abweichung (bewusst -> einfrieren; Regression -> reparieren). Einfrieren mit Abweichung zementiert die Regression als Gold.
• Friere bei geschlossenem Spiel und erhöhter Sitzung ein.
• Eine Sonde, die einen Fehlalarm auslöst, lehrt, die Sonde zu ignorieren: untersuche den Werteverlauf.
• Eine Sonde mit falschem Schlüsselnamen/-wert ist schlimmer als keine Sonde: überprüfe gegen die echte Datei.
• Dokumentiere, was ein geleertes BIOS/CMOS stillschweigend rückgängig macht (SMT, C-State, DOCP, DRAM-Spannung, Secure Boot, Resizable BAR, PBO) und den Weg zurück.

Schritt 8 – Lebendige Dokumentation

Führe ein Tagebuch (references/template-diario.md): aktueller Zustand, Baseline, Liste der Widerlegten, bezahlte Fallstricke, ausstehende Punkte in Reihenfolge. Korrigiere falsche Einträge mit explizitem Widerruf oben, nicht löschen – die Fehlerhistorie verhindert Wiederholung.

Wie man Ergebnisse an den Benutzer liefert

• Auf Deutsch (oder der Sprache des Besitzers), direkt. Eine Zeile Begründung pro Entscheidung.
• Tabelle pro Aufnahme: Szenario, Hitches/min, schlechtester Frame, schwere >20 ms, 1%/0,1%-Low, Abweichung, sein Urteil. Trenne „was die Zahl sagt“ von „was nur du sagen kannst“.
• Melde niemals FPS als festen Sekundenwert als „was er sieht“: der Zähler des Spiels verwendet ein kurzes Fenster.
• Markiere jede Aussage: GEMESSEN, HYPOTHESE, LITERATUR (Quelle), ENTSCHEIDUNG DES BESITZERS.

Dateien dieser Skill

• references/metodo.md – Aufnahmeprotokoll, Metriken, Ausschnitte, Metrikvalidierung.
• references/jogos.md – Blatt pro Spiel, Log-Marker, Profile pro Genre/Engine, was universell vs. spezifisch ist.
• references/diagnostico.md – Baum von Symptomen -> Instrument -> wahrscheinliche Ursache.
• references/catalogo-alavancas.md – alles, was versucht/gemessen wurde, nach Schicht und Hersteller.
• references/armadilhas.md – Fehler bei Instrumentierung und Denkweise, die bereits Iterationen gekostet haben.
• references/template-diario.md – Vorlage für das Tagebuch/AGENTS.md der auditierten Maschine.
• scripts/inventario.ps1 – Nur-Lese-Inventur (PS 5.1, ASCII).
• scripts/capturar.ps1 – PresentMon-Aufnahme ohne Analyse + Prozess-Snapshots.
• scripts/analisar-frametime.py – Robuste Offline-Analyse (Python 3 Stdlib).