Wie wir Windows untersuchen

Im Abschnitt „Windows-Forschung“ prüfen wir konkrete technische Aussagen. In jedem Artikel erklären wir, was geprüft wurde, unter welchen Bedingungen und für welche Systeme das Ergebnis gilt.

Das Vorhandensein eines Parameters, sein Einfluss auf den Systembetrieb und der Performance-Zuwachs erfordern separate Belege.

Was als Beleg gilt

Wir verwenden mehrere unabhängige Arten von Belegen:

1. Primärdokumentation. Offizielle Dokumente von Microsoft, Spezifikationen und Dokumentation des Herstellers von Hardware oder Anwendung.
2. Statische Beobachtung. Hinweise auf die Implementierung in einer konkreten Version der Komponente. Eine solche Beobachtung ist auf den untersuchten Build beschränkt und beweist für sich genommen nicht die Ausführung des Pfads während des Betriebs.
3. Dynamische Beobachtung. Systemereignisse, Zustand der Komponenten und Traces, die im beschriebenen Szenario gewonnen wurden.
4. Kontrollierte Messung. Vergleich einer im Voraus gewählten Metrik bei bekannter Änderung und geprüfter Rückkehr des Zustands.
5. Reproduktion. Wiederholung des Ergebnisses in einem unabhängigen Lauf, auf einem anderen System oder Build.

Interne Methoden zur Automatisierung der Erfassung und Verarbeitung werden nicht veröffentlicht. Das ändert nichts an der Anforderung, die geprüfte Frage, die Konfiguration, die Metriken, die Anzahl der Durchläufe und die Einschränkungen offenzulegen.

Status der Materialien

Status	Bedeutung
Dokumentiert	Verhalten ist in einer primären öffentlichen Quelle beschrieben.
Beobachtet	Ereignis oder Zustand wurde in der angegebenen Umgebung festgestellt.
Gemessen	Numerische Differenz nach der beschriebenen Methodik ermittelt.
Reproduziert	Ergebnis wurde unabhängig wiederholt.
Nicht reproduziert	Der behauptete Effekt wurde unter den angegebenen Bedingungen nicht festgestellt.
Unzureichende Daten	Methodik oder Stichprobe erlauben keine Schlussfolgerung.

Der Status bezieht sich auf eine einzelne Aussage und nicht automatisch auf den gesamten Artikel. Wir verwenden keinen willkürlichen Vertrauensprozentsatz und bezeichnen ein Ergebnis nicht als universell bewiesen ohne Prüfung auf anderen Systemen.

Wie ein Experiment aufgebaut wird

Vor der Messung werden festgelegt:

• eine zu prüfende Frage;
• die unabhängige Variable;
• die Hauptmetrik und ihre Einheit;
• Windows build, wesentliche Hardware, Treiber und Anwendungsversionen;
• eine praktisch bedeutsame Schwelle;
• die Methode zur Rückkehr in den Ausgangszustand.

Wir vergleichen den Ausgangs- und den geänderten Zustand und prüfen anschließend die Rückkehr. Nach Möglichkeit wechseln wir die Reihenfolge der paarweisen Durchläufe. Wir kontrollieren Aufwärmphase, Stromversorgung, Temperaturen und Hintergrundlast; wenn dies nicht möglich ist, geben wir die Einschränkung an.

Einzelne Intervalle eines Traces zeigen Änderungen über die Zeit, gelten aber nicht als unabhängige Wiederholungen. Das Ergebnis einer virtuellen Maschine lässt sich nicht automatisch auf einen physischen Computer übertragen. Für eine Aussage über alle Geräte einer Klasse reicht es nicht, ein Gerät zu prüfen.

Physischer click-to-photon-Prüfstand

Für Spielestudien verwenden wir einen eigenen Hardware-Prüfstand. Er misst physisch die vollständige Latenz vom elektrischen Signal der Maustaste bis zur Änderung der Pixelhelligkeit auf dem Bildschirm, ohne softwarebasierte Schätzung dieses Intervalls.

Der Hauptpfad ist folgendermaßen aufgebaut:

1. Ein Draht ist an die Leitung der linken Taste einer Logitech G PRO X SUPERLIGHT der ersten Generation gelötet. Die elektrische Flanke startet den Timer eines Arduino Uno.
2. Derselbe Klick durchläuft den Mauscontroller, USB, Windows, das Spiel, die Rendering-Warteschlange, GPU und Monitor.
3. Ein am Bildschirm befestigter Fotosensor stoppt den Timer, wenn die Helligkeit des Testbereichs eine im Voraus gewählte Schwelle überschreitet.
4. Ein Ergebnis enthält das vollständige click-to-photon-Intervall in Millisekunden.

Ein solcher Start umfasst absichtlich die Verarbeitung durch den Mauscontroller und dessen click debounce, nicht jedoch den mechanischen Weg der Taste bis zum Schließen des Kontakts. Wir ziehen die Mauslatenz nicht vom Endergebnis ab. In der aktuellen Methodik unabhängiger Messungen von RTINGS für die G PRO X SUPERLIGHT sind 2.5 ms über Kabel und 3.1 ms über receiver angegeben. Die niedrige gemessene click latency macht diese Maus zu einem geeigneten stabilen Teil des Prüfstands, verwandelt das Ergebnis aber nicht in eine reine Latenz von Windows oder des Spiels.

Ein separater HID-Mikrocontroller im Format Arduino Nano kann Klicks automatisch an Windows senden. Dieser Weg wird verwendet, wenn Unterschiede beim manuellen Drücken beseitigt und das Eingangssignal in kontrolliertem Tempo wiederholt werden sollen. Er beantwortet eine andere Frage und wird nicht mit Serien vermischt, die von der physischen Leitung der Maustaste ausgehen.

In CS2 wird eine workshop-Karte BXLAT verwendet, bei der ein Klick eine vorhersehbare Änderung des Testbereichs auslöst. Ein analoges visuelles Szenario wird in Valorant angewendet. Position des Fotosensors, Auflösung, Monitorfrequenz, FPS-Limit, Modus display scaling, presentation mode und Lichtschwelle werden für die gesamte verglichene Serie festgelegt.

Der aktuelle Standard erfordert mindestens 300 gültige Klicks pro Zustand. In neuen Serien speichern wir Mittelwert, Standardabweichung, Minimum, Maximum, Perzentile, einschließlich P90, und die Verteilung zur Erstellung von Diagrammen. Fehlerhafte Auslösungen, Überschreitungen der Wartezeit und Werte außerhalb des im Voraus festgelegten Bereichs markieren wir und berücksichtigen sie bei der Prüfung der Eignung der Serie.

Die Forschung an diesem Prüfstand wird seit mehreren Jahren betrieben, und das Speicherformat hat sich in dieser Zeit geändert. In der öffentlichen Tabelle historischer Messungen gibt es Serien mit 300 Klicks und frühere Serien mit 100. Für einen Teil der alten Tests sind nur AVG, STDDEV, MIN und MAX erhalten; fehlende P90 oder Diagramme werden nicht aus den Aggregaten rekonstruiert und ausdrücklich als nicht verfügbar gekennzeichnet. Neue Serien werden mit erweiterter Statistik veröffentlicht.

Was im Ergebnis veröffentlicht wird

Der Artikel enthält:

• eine kurze Antwort;
• die geprüfte Aussage;
• den Untersuchungsbereich;
• die Methodik und die Anzahl unabhängiger Traces;
• die Werte der Metriken und die Streuung;
• bestätigte und nicht bestätigte Schlussfolgerungen;
• ausgeschlossene oder verfälschte Metriken;
• Einschränkungen;
• eine praktische Empfehlung ohne Garantie auf ein identisches Ergebnis;
• die Bestätigung der Rückkehr des Zustands;
• primäre öffentliche Quellen und das Datum der Prüfung.

Wenn ein Ergebnis eine populäre Empfehlung oder eine Funktion von BoosterX nicht bestätigt hat, kann es trotzdem veröffentlicht werden. Das Vorhandensein einer Einstellung im Produkt ist kein Beleg für ihre Wirksamkeit.

Wie man selbst prüft

Ein bedeutender Teil der dynamischen Beobachtungen aus unseren Untersuchungen lässt sich mit öffentlichen Werkzeugen wiederholen: Sysinternals ProcMon für System-Traces und WinDbg mit öffentlichen Symbolen von Microsoft. Der grundlegende Prüfpfad sieht so aus.

1. Lesen des Parameters — ProcMon. Öffnen Sie Options → Configure Symbols und geben Sie den öffentlichen Symbolserver von Microsoft an, damit die Stapel Modul- und Funktionsnamen anzeigen. Fügen Sie dann einen Filter Path contains hinzu — zum Beispiel SystemResponsiveness aus HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfile. Anhand der Leseereignisse ist erkennbar, ob der Wert gelesen wird, wann und durch welchen Prozess.
2. Wer liest — Aufrufstapel. Ein Doppelklick auf ein Ereignis öffnet seine Eigenschaften; auf der Registerkarte Stack wird die Kette der Module angezeigt — das ist der „Leser“ des Parameters. Zum Beispiel bedeutet eine Kette von user32.dll zu win32kfull.sys, dass die Win32k-Subsystem für den Wert verantwortlich ist.
3. Verhalten zur Laufzeit — WinDbg. Mit den öffentlichen Symbolen von Microsoft kann man einen Haltepunkt auf Funktionen aus dem Stapel setzen und beobachten, wie der gelesene Wert angewendet wird.
4. Synthetische Tests. Ändern Sie den Wert und messen Sie das beobachtete Verhalten. Zum Beispiel werden die Intervalle der Mauseingabe mit öffentlichen Testern der Abfragefrequenz gemessen.

Ehrliche Grenze. Die statische Analyse von Binärdateien und vollständige Traces werden in den Artikeln nicht veröffentlicht. Der obige Pfad wiederholt den dynamischen Teil unserer Beobachtungen, ersetzt aber nicht die statische Analyse — ihre Schlussfolgerungen beziehen sich auf den untersuchten Build.

Grenzen der Latenzmessung

Software-Latenz, Warteschlangentiefe, Periode der Audio-Engine, Planungszeit des Threads und vollständige physische Latenz beschreiben unterschiedliche Größen. Zum Beispiel bestimmt die XAudio2-Warteschlange nicht das gesamte Intervall von der Benutzeraktion bis zum Ton aus dem Lautsprecher. Für dessen Messung ist externe Hardware erforderlich.

Analog dazu ist die CPU-Zeit eines einzelnen Prozesses nicht gleich dem Gesamteinfluss auf FPS, frametime, Energieverbrauch oder Systemreaktionsfähigkeit. Solche Schlussfolgerungen werden mit separaten Metriken geprüft.

Datenschutz

Rohe ETL, PML, Ereignisprotokolle, Speicherabbilder und Registry-Exporte werden standardmäßig nicht veröffentlicht. System-Traces können Benutzernamen, Pfade, Kommandozeilen, Netzwerkadressen und andere sensible Daten enthalten. Microsoft warnt gesondert davor in den Bedingungen von Sysinternals.

Auf der Website werden nur manuell ausgewählte und anonymisierte Tabellen veröffentlicht. Wir entfernen eindeutige Identifikatoren von Geräten und Installationen, Benutzerpfade, Kontodaten, Netzwerkidentifikatoren, Anmeldedaten und Informationen zu Prozessen, die nicht mit der Untersuchung zusammenhängen.

Korrektur von Schlussfolgerungen

Windows, Treiber und Anwendungen ändern sich. Jeder Artikel erhält ein Datum der letzten Prüfung und einen Geltungsbereich. Wenn eine neue Messung einer alten Schlussfolgerung widerspricht, wird der Artikel mit Erklärung der Ursache aktualisiert. Ein altes Ergebnis wird nicht automatisch auf einen neuen Build übertragen.

Unabhängigkeit und Marken

Die Untersuchungen werden vom BoosterX-Team veröffentlicht und können sich auf Produktfunktionen beziehen. Dieser mögliche Interessenkonflikt wird dadurch berücksichtigt, dass Methodik, gemessene Werte, Einschränkungen und negative Ergebnisse von der Produktempfehlung getrennt werden.

BoosterX Wiki ist eine unabhängige Veröffentlichung und ist nicht mit Microsoft Corporation verbunden, nicht von ihr autorisiert, nicht gesponsert und nicht von ihr gebilligt. Die Namen Microsoft und Windows werden nur zur genauen Beschreibung des Untersuchungsgegenstands verwendet. Mehr dazu: Microsoft Trademark and Brand Guidelines.

Änderungsverlauf

• 2026-08-24: Methodik veröffentlicht.
• 2026-09-20: Abschnitt „Wie man selbst prüft“ hinzugefügt; Link zur Datenquelle der Maus korrigiert.

Letzte Prüfung der Methodik: 2026-09-20.