Sådan undersøger vi Windows

I afsnittet “Windows-forskning” verificerer vi konkrete tekniske påstande. I hver artikel forklarer vi, hvad vi undersøgte, under hvilke betingelser, og hvilke systemer resultatet gælder for.

Tilstedeværelsen af en parameter, dens indvirkning på systemets funktion og ydeevneforbedringen kræver separate beviser.

Hvad betragtes som bevis

Vi bruger flere uafhængige typer af evidens:

1. Primær dokumentation. Officielle Microsoft-dokumenter, specifikationer og dokumentation fra producenten af hardware eller applikationen.
2. Statisk observation. Tegn på implementering i en specifik version af komponenten. En sådan observation er begrænset til den undersøgte build og beviser ikke i sig selv, at stien udføres under kørsel.
3. Dynamisk observation. Systemhændelser, komponenttilstande og traces opnået i det beskrevne scenarie.
4. Kontrolleret måling. Sammenligning af en på forhånd valgt metrik ved en kendt ændring og verificeret tilbagevenden af tilstanden.
5. Reproduktion. Gentagelse af resultatet i en uafhængig kørsel, på et andet system eller en anden build.

Interne metoder til automatisering af indsamling og behandling offentliggøres ikke. Det ændrer ikke kravet om at redegøre for det undersøgte spørgsmål, konfigurationen, metrikkerne, antallet af gennemløb og begrænsningerne.

Status for materialer

Status	Betydning
Dokumenteret	Adfærden er beskrevet i en primær offentlig kilde.
Observeret	Hændelsen eller tilstanden er fundet i det angivne miljø.
Målt	Der er opnået en numerisk forskel efter den beskrevne metode.
Reproduceret	Resultatet er gentaget uafhængigt.
Ikke reproduceret	Den påståede effekt er ikke fundet under de angivne betingelser.
Utilstrækkelige data	Metoden eller stikprøven gør det ikke muligt at drage en konklusion.

Status vedrører en enkelt påstand, ikke automatisk hele artiklen. Vi bruger ikke en vilkårlig tillidsprocent og kalder ikke et resultat universelt bevist uden verifikation på andre systemer.

Hvordan eksperimentet opbygges

Før målingen fastlægges:

• ét undersøgt spørgsmål;
• den uafhængige variabel;
• den primære metrik og dens enhed;
• Windows build, væsentlig hardware, drivere og applikationsversioner;
• en praktisk relevant tærskel;
• metoden til at gendanne den oprindelige tilstand.

Vi sammenligner den oprindelige og den ændrede tilstand og kontrollerer derefter tilbagevenden. Når det er muligt, skifter vi rækkefølgen af parrede gennemløb. Vi kontrollerer opvarmning, strømforsyning, temperaturer og baggrundsbelastning; hvis det ikke er muligt, angiver vi begrænsningen.

Enkelte intervaller i en trace viser ændringer over tid, men betragtes ikke som uafhængige gentagelser. Resultatet fra en virtuel maskine kan ikke automatisk overføres til en fysisk computer. For at konkludere om alle enheder i en klasse er det ikke tilstrækkeligt at teste én enhed.

Fysisk click-to-photon-stand

Til spilundersøgelser bruger vi en egen hardwarestand. Den måler fysisk den fulde forsinkelse fra det elektriske signal fra museknappen til ændringen i pixelens lysstyrke på skærmen, uden softwaremæssig vurdering af dette interval.

Hovedforløbet er opbygget sådan:

1. En ledning er loddet til linjen for venstre knap på en Logitech G PRO X SUPERLIGHT af første generation. Den elektriske flanke starter en timer på en Arduino Uno.
2. Det samme klik passerer gennem musens controller, USB, Windows, spillet, renderingskøen, GPU’en og skærmen.
3. En fotosensor fastgjort på skærmen stopper timeren, når lysstyrken i testområdet krydser en på forhånd valgt tærskel.
4. Ét resultat indeholder det fulde click-to-photon-interval i millisekunder.

En sådan start inkluderer bevidst musens controllerbehandling og dens click debounce, men inkluderer ikke knappens mekaniske vandring frem til kontaktens lukning. Vi trækker ikke musens forsinkelse fra i den endelige værdi. I den aktuelle metode til uafhængige målinger angiver RTINGS for G PRO X SUPERLIGHT 2.5 ms via kabel og 3.1 ms via receiver. Den lave målte click latency gør denne mus til en velegnet stabil del af standen, men forvandler ikke resultatet til en ren Windows- eller spilforsinkelse.

En separat HID-mikrocontroller i Arduino Nano-format kan sende klik til Windows automatisk. Denne rute bruges, når man vil fjerne forskellene ved manuel trykning og gentage inputsignalet i et kontrolleret tempo. Den svarer på et andet spørgsmål og blandes ikke med serier, der starter fra museknappens fysiske linje.

I CS2 bruges workshop-kortet BXLAT, hvor et klik fremkalder en forudsigelig ændring i testområdet. Et tilsvarende visuelt scenarie anvendes i Valorant. Fotosensorens placering, opløsning, skærmens frekvens, FPS-grænse, display scaling-tilstand, presentation mode og lystærskel fastlåses for hele den sammenlignede serie.

Den aktuelle standard kræver mindst 300 gyldige klik pr. tilstand. I nye serier gemmer vi gennemsnit, standardafvigelse, minimum, maksimum, percentiler, inklusive P90, og fordelingen til at bygge grafer. Fejlagtige udløsninger, overskridelser af ventetiden og værdier uden for det på forhånd fastsatte interval markeres og tages i betragtning ved vurderingen af seriens anvendelighed.

Forskning på denne stand har stået på i flere år, og formatet til lagring er ændret i den tid. I den offentlige tabel over historiske målinger findes serier med 300 klik og tidligere serier med 100. For en del af de gamle tests er kun AVG, STDDEV, MIN og MAX bevaret; manglende P90 eller grafer genskabes ikke ud fra aggregater og markeres direkte som utilgængelige. Nye serier vil blive offentliggjort med udvidet statistik.

Hvad offentliggøres i resultatet

Artiklen indeholder:

• et kort svar;
• den undersøgte påstand;
• undersøgelsens område;
• metoden og antallet af uafhængige traces;
• metrikværdier og spredning;
• bekræftede og ubekræftede konklusioner;
• udeladte eller forurenede metrikker;
• begrænsninger;
• en praktisk anbefaling uden garanti for samme resultat;
• bekræftelse af tilbagevenden af tilstanden;
• primære offentlige kilder og verifikationsdato.

Hvis resultatet ikke bekræftede en populær anbefaling eller en BoosterX-funktion, kan det stadig offentliggøres. Tilstedeværelsen af en indstilling i produktet er ikke et bevis for dens effektivitet.

Sådan verificerer du selv

En betydelig del af de dynamiske observationer fra vores undersøgelser kan gentages med offentlige værktøjer: Sysinternals ProcMon til systemtraces og WinDbg med offentlige Microsoft-symboler. Den grundlæggende verifikationsvej ser sådan ud.

1. Læsning af parameteren — ProcMon. Åbn Options → Configure Symbols og angiv Microsofts offentlige symbolserver, så stackene viser modul- og funktionsnavne. Tilføj derefter et filter Path contains — for eksempel SystemResponsiveness fra HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfile. Ud fra læsehændelserne kan man se, om værdien læses, hvornår og af hvilken proces.
2. Hvem læser — call stack. Et dobbeltklik på en hændelse åbner dens egenskaber; på fanen Stack vises kæden af moduler — det er netop parameterens “læser”. For eksempel betyder en kæde fra user32.dll til win32kfull.sys, at det er Win32k-undersystemet, der står for værdien.
3. Adfærd i runtime — WinDbg. Med offentlige Microsoft-symboler kan man sætte et breakpoint på en funktion fra stacken og se, hvordan den læste værdi anvendes.
4. Syntetiske tests. Ændr værdien og mål den observerede adfærd. For eksempel måles intervaller for musens input med offentlige testere af polling rate.

Den ærlige grænse. Statisk analyse af binære filer og fulde traces offentliggøres ikke i artiklerne. Vejen ovenfor gentager den dynamiske del af vores observationer, men erstatter ikke den statiske analyse — dens konklusioner vedrører den undersøgte build.

Grænser for måling af forsinkelse

Softwareforsinkelse, kødybde, lydmotorens periode, trådplanlægningstid og den fulde fysiske forsinkelse beskriver forskellige størrelser. For eksempel bestemmer XAudio2-køen ikke hele intervallet fra brugerens handling til lyden fra højttaleren. Til at måle det kræves eksternt udstyr.

Tilsvarende er CPU-tiden for en enkelt proces ikke lig med den samlede indvirkning på FPS, frametime, energiforbrug eller systemets responsivitet. Sådanne konklusioner verificeres med separate metrikker.

Databeskyttelse

Rå ETL, PML, hændelseslogs, hukommelsesdumps og registreringsdatabaseeksporter offentliggøres som standard ikke. Systemtraces kan indeholde brugernavne, stier, kommandolinjer, netværksadresser og andre følsomme data. Microsoft advarer særskilt om dette i Sysinternals-betingelserne.

På webstedet offentliggøres kun manuelt udvalgte og anonymiserede tabeller. Vi fjerner unikke identifikatorer for enheder og installationer, brugerstier, kontooplysninger, netværksidentifikatorer, loginoplysninger og oplysninger om processer, der ikke er relateret til undersøgelsen.

Rettelse af konklusioner

Windows, drivere og applikationer ændrer sig. Hver artikel får en dato for sidste verifikation og et anvendelsesområde. Hvis en ny måling modsiger en gammel konklusion, opdateres artiklen med en forklaring på årsagen. Det gamle resultat overføres ikke automatisk til en ny build.

Uafhængighed og varemærker

Undersøgelserne offentliggøres af BoosterX-teamet og kan vedrøre produktets funktioner. Denne mulige interessekonflikt håndteres ved, at metoden, de målte værdier, begrænsningerne og de negative resultater holdes adskilt fra produktanbefalingen.

BoosterX Wiki er en uafhængig publikation og er ikke forbundet med, autoriseret af, sponsoreret af eller godkendt af Microsoft Corporation. Navnene Microsoft og Windows bruges kun til præcist at beskrive undersøgelsens genstand. Mere information: Microsoft Trademark and Brand Guidelines.

Ændringshistorik

• 2026-08-24: metoden offentliggjort.
• 2026-09-20: afsnittet “Sådan verificerer du selv” tilføjet; linket til musens datakilde rettet.

Sidste verifikation af metoden: 2026-09-20.