Hur vi undersöker Windows

I avsnittet “Windows-forskning” granskar vi specifika tekniska påståenden. I varje artikel förklarar vi vad vi undersökte, under vilka förutsättningar och vilka system resultatet gäller för.

Förekomsten av en parameter, dess inverkan på systemets funktion och prestandavinsten kräver separata bevis.

Vad som räknas som bevis

Vi använder flera oberoende typer av belägg:

1. Primär dokumentation. Officiella dokument från Microsoft, specifikationer och dokumentation från tillverkaren av hårdvaran eller programmet.
2. Statisk observation. Tecken på implementering i en specifik version av komponenten. En sådan observation är begränsad till den undersökta byggversionen och bevisar i sig inte att körvägen används under drift.
3. Dynamisk observation. Systemhändelser, komponenttillstånd och spårningar som erhållits i det beskrivna scenariot.
4. Kontrollerad mätning. Jämförelse av ett i förväg valt mätvärde vid en känd förändring och en verifierad återställning av tillståndet.
5. Reproduktion. Upprepning av resultatet i en oberoende körning, på ett annat system eller en annan byggversion.

Interna metoder för automatisering av insamling och bearbetning publiceras inte. Detta ändrar inte kravet att redovisa den undersökta frågan, konfigurationen, mätvärdena, antalet körningar och begränsningarna.

Status för material

Status	Betydelse
Dokumenterat	Beteendet beskrivs i en primär offentlig källa.
Observerat	Händelsen eller tillståndet upptäcktes i den angivna miljön.
Uppmätt	En numerisk skillnad erhölls enligt den beskrivna metoden.
Reproducerat	Resultatet upprepades oberoende.
Ej reproducerat	Den påstådda effekten upptäcktes inte under de angivna förutsättningarna.
Otillräckliga data	Metoden eller urvalet tillåter inte en slutsats.

Statusen avser ett enskilt påstående, inte automatiskt hela artikeln. Vi använder inte en godtycklig tillitsprocent och kallar inte ett resultat universellt bevisat utan verifiering på andra system.

Hur ett experiment byggs upp

Före mätningen fastställs:

• en undersökt fråga;
• en oberoende variabel;
• ett huvudmätvärde och dess enhet;
• Windows build, väsentlig hårdvara, drivrutiner och programversioner;
• en praktiskt signifikant tröskel;
• ett sätt att återställa utgångstillståndet.

Vi jämför utgångstillståndet och det ändrade tillståndet och verifierar sedan återställningen. När det är möjligt varvar vi ordningen på parade körningar. Vi kontrollerar uppvärmning, strömförsörjning, temperaturer och bakgrundsbelastning; om detta inte är möjligt anger vi begränsningen.

Enskilda intervall i en spårning visar förändringar över tid men räknas inte som oberoende upprepningar. Resultatet från en virtuell maskin kan inte automatiskt överföras till en fysisk dator. För en slutsats om alla enheter av en klass räcker det inte att testa en enhet.

Fysisk click-to-photon-rigg

För spelundersökningar använder vi en egen hårdvarurigg. Den mäter fysiskt den fullständiga fördröjningen från den elektriska signalen från musknappen till förändringen i pixelns ljusstyrka på skärmen, utan programvarubaserad uppskattning av detta intervall.

Huvudkedjan är uppbyggd så här:

1. En ledning är lödad till den vänstra knappens ledning på en Logitech G PRO X SUPERLIGHT av första generationen. Den elektriska flanken startar en timer på en Arduino Uno.
2. Samma klick passerar genom musens kontroller, USB, Windows, spelet, renderingskön, GPU och monitorn.
3. En fotosensor fäst på skärmen stoppar timern när ljusstyrkan i testområdet passerar en i förväg vald tröskel.
4. Ett resultat innehåller det fullständiga click-to-photon-intervallet i millisekunder.

En sådan start inkluderar medvetet musens kontrollerbearbetning och dess click debounce, men inkluderar inte knappens mekaniska rörelse fram till kontaktens slutning. Vi drar inte av musens fördröjning från slutvärdet. I den aktuella metoden för oberoende mätningar anger RTINGS 2.5 ms via kabel och 3.1 ms via receiver för G PRO X SUPERLIGHT. Den låga uppmätta click latency gör denna mus lämplig som en stabil del av riggen, men förvandlar inte resultatet till en ren fördröjning för Windows eller spelet.

En separat HID-mikrokontroller av formatet Arduino Nano kan skicka klick till Windows automatiskt. Denna väg används när man vill ta bort skillnader från manuellt nedtryckande och upprepa insignalen i en kontrollerad takt. Den svarar på en annan fråga och blandas inte med serier som börjar från musknappens fysiska ledning.

I CS2 används workshop-kartan BXLAT, där ett klick orsakar en förutsägbar förändring i testområdet. Ett liknande visuellt scenario används i Valorant. Fotosensorns position, upplösning, monitorns frekvens, FPS-gräns, läget display scaling, presentation mode och ljuströskeln fastställs för hela den jämförda serien.

Den aktuella standarden kräver minst 300 giltiga klick per tillstånd. I nya serier bevarar vi medelvärde, standardavvikelse, minimum, maximum, percentiler, inklusive P90, och fördelning för att skapa grafer. Felaktiga utlösningar, överskridanden av tidsgränsen och värden utanför ett i förväg fastställt intervall markeras och beaktas vid kontrollen av seriens lämplighet.

Forskning på denna rigg har pågått i flera år, och lagringsformatet har förändrats under denna tid. I den offentliga tabellen med historiska mätningar finns serier med 300 klick och äldre serier med 100. För en del äldre tester har endast AVG, STDDEV, MIN och MAX bevarats; saknade P90 eller grafer kan inte återskapas från aggregaten och markeras direkt som otillgängliga. Nya serier kommer att publiceras med utökad statistik.

Vad som publiceras i resultatet

Artikeln innehåller:

• ett kort svar;
• ett undersökt påstående;
• undersökningens omfattning;
• metod och antal oberoende spårningar;
• mätvärden och spridning;
• bekräftade och obekräftade slutsatser;
• uteslutna eller förorenade mätvärden;
• begränsningar;
• en praktisk rekommendation utan garanti om ett identiskt resultat;
• bekräftelse av återställning av tillståndet;
• primära offentliga källor och verifieringsdatum.

Om resultatet inte bekräftade en populär rekommendation eller en funktion i BoosterX kan det ändå publiceras. Förekomsten av en inställning i produkten är inte ett bevis för dess effektivitet.

Hur man verifierar själv

En betydande del av de dynamiska observationerna från vår forskning kan upprepas med offentliga verktyg: Sysinternals ProcMon för systemspårningar och WinDbg med Microsofts offentliga symboler. Den grundläggande verifieringsvägen ser ut så här.

1. Läsa parametern — ProcMon. Öppna Options → Configure Symbols och ange Microsofts offentliga symbolserver så att stackarna visar modul- och funktionsnamn. Lägg sedan till ett filter Path contains — till exempel SystemResponsiveness från HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfile. Via läsningshändelserna syns det om värdet läses, när och av vilken process.
2. Vem som läser — anropsstacken. Dubbelklicka på händelsen för att öppna dess egenskaper; på fliken Stack visas kedjan av moduler — det är parameterns “läsare”. Till exempel innebär en kedja från user32.dll till win32kfull.sys att det är Win32k-undersystemet som ansvarar för värdet.
3. Beteende i runtime — WinDbg. Med Microsofts offentliga symboler kan man sätta en brytpunkt på en funktion från stacken och se hur det lästa värdet tillämpas.
4. Syntetiska tester. Ändra värdet och mät det observerade beteendet. Till exempel mäts intervall för musinmatning med offentliga testare för polling rate.

Ärlig gräns. Statisk analys av binärfiler och fullständiga spårningar publiceras inte i artiklarna. Vägen ovan upprepar den dynamiska delen av våra observationer men ersätter inte statisk analys — dess slutsatser gäller den undersökta byggversionen.

Gränser för mätning av fördröjning

Programvarufördröjning, ködjup, ljudmotorns period, trådens schemaläggningstid och den fullständiga fysiska fördröjningen beskriver olika storheter. Till exempel bestämmer XAudio2-kön inte hela intervallet från användarens handling till ljudet från högtalaren. För att mäta det behövs extern utrustning.

På samma sätt är en enskild process CPU-tid inte lika med den totala inverkan på FPS, frametime, energiförbrukning eller systemets responsivitet. Sådana slutsatser verifieras med separata mätvärden.

Dataskydd

Rå ETL, PML, händelseloggar, minnesdumpar och registerexporter publiceras inte som standard. Systemspårningar kan innehålla användarnamn, sökvägar, kommandorader, nätverksadresser och andra känsliga data. Microsoft varnar särskilt för detta i villkoren för Sysinternals.

På webbplatsen publiceras endast manuellt utvalda och avidentifierade tabeller. Vi tar bort unika identifierare för enheter och installationer, användarsökvägar, kontodata, nätverksidentifierare, inloggningsuppgifter och information om processer som inte är relaterade till undersökningen.

Rättelse av slutsatser

Windows, drivrutiner och program förändras. Varje artikel får ett datum för senaste verifiering och ett tillämpningsområde. Om en ny mätning motsäger en gammal slutsats uppdateras artikeln med en förklaring av orsaken. Ett gammalt resultat överförs inte automatiskt till en ny byggversion.

Oberoende och varumärken

Undersökningarna publiceras av BoosterX-teamet och kan avse produktens funktioner. Denna möjliga intressekonflikt beaktas genom att metoden, de uppmätta värdena, begränsningarna och de negativa resultaten hålls åtskilda från produktrekommendationen.

BoosterX Wiki är en oberoende publikation och är inte knuten till, auktoriserad av, sponsrad av eller godkänd av Microsoft Corporation. Namnen Microsoft och Windows används endast för att exakt beskriva undersökningens föremål. Mer information: Microsoft Trademark and Brand Guidelines.

Ändringshistorik

• 2026-08-24: metoden publicerades.
• 2026-09-20: avsnittet “Hur man verifierar själv” lades till; länken till musens datakälla korrigerades.

Senaste verifiering av metoden: 2026-09-20.