Kā mēs pētām Windows

Sadaļā “Windows pētījumi” mēs pārbaudām konkrētus tehniskus apgalvojumus. Katrā rakstā skaidrojam, ko pārbaudījām, kādos apstākļos un uz kurām sistēmām attiecas rezultāts.

Parametra esamība, tā ietekme uz sistēmas darbību un veiktspējas pieaugums prasa atsevišķus pierādījumus.

Kas tiek uzskatīts par pierādījumu

Mēs izmantojam vairākus neatkarīgus pierādījumu veidus:

1. Primārā dokumentācija. Microsoft oficiālie dokumenti, specifikācijas un aparatūras vai lietotnes ražotāja dokumentācija.
2. Statiska novērošana. Implementācijas pazīmes konkrētā komponenta versijā. Šāda novērošana ir ierobežota ar pētīto būvējumu un pati par sevi nepierāda ceļa izpildi darbības laikā.
3. Dinamiska novērošana. Sistēmas notikumi, komponentu stāvoklis un trasējumi, kas iegūti aprakstītajā scenārijā.
4. Kontrolēts mērījums. Iepriekš izvēlētas metrikas salīdzinājums pie zināmām izmaiņām un pārbaudītas stāvokļa atgriešanas.
5. Reproducēšana. Rezultāta atkārtojums neatkarīgā palaišanā, citā sistēmā vai būvējumā.

Iekšējās vākšanas un apstrādes automatizācijas metodes netiek publicētas. Tas nemaina prasību atklāt pārbaudāmo jautājumu, konfigurāciju, metrikas, palaišanu skaitu un ierobežojumus.

Materiālu statusi

Statuss	Nozīme
Dokumentēts	Uzvedība aprakstīta primārā publiskā avotā.
Novērots	Notikums vai stāvoklis atklāts norādītajā vidē.
Izmērīts	Iegūta skaitliska atšķirība pēc aprakstītās metodikas.
Reproducēts	Rezultāts atkārtots neatkarīgi.
Nav reproducēts	Apgalvotais efekts nav atklāts norādītajos apstākļos.
Nepietiekami dati	Metodika vai izlase neļauj izdarīt secinājumu.

Statuss attiecas uz atsevišķu apgalvojumu, nevis automātiski uz visu rakstu. Mēs neizmantojam patvaļīgu uzticības procentu un nesaucam rezultātu par universāli pierādītu bez pārbaudes citās sistēmās.

Kā tiek veidots eksperiments

Pirms mērījuma tiek fiksēti:

• viens pārbaudāmais jautājums;
• neatkarīgais mainīgais;
• galvenā metrika un tās vienība;
• Windows build, būtiskā aparatūra, draiveri un lietotņu versijas;
• praktiski nozīmīgs slieksnis;
• sākotnējā stāvokļa atgriešanas veids.

Mēs salīdzinām sākotnējo un izmainīto stāvokli, pēc tam pārbaudām atgriešanos. Ja iespējams, mainām pāru palaišanu secību. Kontrolējam iesildīšanu, barošanu, temperatūras un fona slodzi; ja tas nav iespējams, norādām ierobežojumu.

Atsevišķi viena trasējuma intervāli parāda izmaiņas laikā, bet netiek uzskatīti par neatkarīgiem atkārtojumiem. Virtuālās mašīnas rezultātu nevar automātiski pārnest uz fizisku datoru. Lai izdarītu secinājumu par visām vienas klases ierīcēm, nepietiek pārbaudīt vienu ierīci.

Fiziskais click-to-photon stends

Spēļu pētījumiem mēs izmantojam savu aparatūras stendu. Tas fiziski mēra pilnu aizturi no peles pogas elektriskā signāla līdz pikseļa spilgtuma izmaiņai ekrānā, bez šī intervāla programmatūras novērtējuma.

Galvenais ceļš ir veidots šādi:

1. Vads ir pielodēts pie Logitech G PRO X SUPERLIGHT pirmās paaudzes kreisās pogas līnijas. Elektriskais fronts palaiž Arduino Uno taimeri.
2. Tas pats klikšķis iet caur peles kontrolieri, USB, Windows, spēli, renderēšanas rindu, GPU un monitoru.
3. Uz ekrāna piestiprināts fotosensors aptur taimeri, kad testa apgabala spilgtums šķērso iepriekš izvēlēto slieksni.
4. Viens rezultāts satur pilnu click-to-photon intervālu milisekundēs.

Šāds starts apzināti iekļauj peles kontroliera apstrādi un tās click debounce, bet neiekļauj pogas mehānisko gaitu līdz kontakta aizvēršanai. Mēs neatņemam peles aizturi no gala vērtības. Aktuālajā neatkarīgo mērījumu metodikā RTINGS G PRO X SUPERLIGHT norādīts 2.5 ms pa kabeli un 3.1 ms caur receiver. Zemā izmērītā click latency padara šo peli par piemērotu stabilu stenda daļu, bet nepārvērš rezultātu par tīru Windows vai spēles aizturi.

Atsevišķs Arduino Nano formāta HID mikrokontrolleris var sūtīt klikšķus uz Windows automātiski. Šis maršruts tiek izmantots, kad nepieciešams novērst manuāla nospieduma atšķirības un atkārtot ievades signālu kontrolētā tempā. Tas atbild uz citu jautājumu un netiek jaukts ar sērijām, kas sākas no peles pogas fiziskās līnijas.

CS2 tiek izmantota workshop karte BXLAT, kur klikšķis izraisa paredzamu testa apgabala izmaiņu. Līdzīgs vizuālais scenārijs tiek izmantots Valorant. Fotosensora novietojums, izšķirtspēja, monitora frekvence, FPS limits, display scaling režīms, presentation mode un gaismas slieksnis tiek fiksēti visai salīdzināmajai sērijai.

Pašreizējais standarts prasa vismaz 300 derīgus klikšķus uz stāvokli. Jaunās sērijās mēs saglabājam vidējo, standartnovirzi, minimumu, maksimumu, procentiles, tostarp P90, un sadalījumu grafiku veidošanai. Kļūdainus nostrādes gadījumus, gaidīšanas laika pārsniegumus un vērtības ārpus iepriekš noteiktā diapazona atzīmējam un ņemam vērā sērijas piemērotības pārbaudē.

Pētījumi ar šo stendu tiek veikti vairākus gadus, un glabāšanas formāts šajā laikā ir mainījies. Publiskajā vēsturisko mērījumu tabulā ir sērijas ar 300 klikšķiem un agrākas sērijas ar 100. Daļai veco testu ir saglabāti tikai AVG, STDDEV, MIN un MAX; trūkstošās P90 vai grafikas no agregātiem netiek atjaunotas un tiek tieši atzīmētas kā nepieejamas. Jaunās sērijas tiks publicētas ar paplašinātu statistiku.

Kas tiek publicēts rezultātā

Raksts satur:

• īsu atbildi;
• pārbaudāmo apgalvojumu;
• pētījuma jomu;
• metodiku un neatkarīgo trasējumu skaitu;
• metrikas vērtības un izkliedi;
• apstiprinātus un neapstiprinātus secinājumus;
• izslēgtas vai piesārņotas metrikas;
• ierobežojumus;
• praktisku ieteikumu bez garantijas par vienādu rezultātu;
• stāvokļa atgriešanas apstiprinājumu;
• primāros publiskos avotus un pārbaudes datumu.

Ja rezultāts neapstiprināja populāru ieteikumu vai BoosterX funkciju, tas tik un tā var tikt publicēts. Iestatījuma esamība produktā nav tā efektivitātes pierādījums.

Kā pārbaudīt patstāvīgi

Nozīmīga daļa dinamisko novērojumu no mūsu pētījumiem tiek atkārtota ar publiskiem rīkiem: Sysinternals ProcMon sistēmas trasējumiem un WinDbg ar Microsoft publiskajiem simboliem. Pamata pārbaudes ceļš izskatās šādi.

1. Parametra nolasīšana — ProcMon. Atveriet Options → Configure Symbols un norādiet Microsoft publisko simbolu serveri, lai steiki rādītu moduļu un funkciju nosaukumus. Pēc tam pievienojiet filtru Path contains — piemēram, SystemResponsiveness no HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfile. Pēc nolasīšanas notikumiem redzams, vai vērtība tiek nolasīta, kad un ar kuru procesu.
2. Kas nolasa — izsaukuma steks. Dubultklikšķis uz notikuma atver tā rekvizītus; cilnē Stack ir redzama moduļu ķēde — tas arī ir parametra “lasītājs”. Piemēram, ķēde no user32.dll uz win32kfull.sys nozīmē, ka par vērtību atbild Win32k apakšsistēma.
3. Uzvedība izpildes laikā — WinDbg. Ar Microsoft publiskajiem simboliem var uzstādīt pārtraukuma punktu uz funkcijas no steka un apskatīt, kā nolasītā vērtība tiek piemērota.
4. Sintētiskie testi. Mainiet vērtību un izmēriet novērojamo uzvedību. Piemēram, peles ievades intervāli tiek mērīti ar publiskiem aptaujas frekvences testeriem.

Godīga robeža. Bināro failu statiskā analīze un pilni trasējumi rakstos netiek publicēti. Iepriekš minētais ceļš atkārto mūsu novērojumu dinamisku daļu, bet neaizstāj statisko analīzi — tās secinājumi attiecas uz pētīto būvējumu.

Aiztures mērīšanas robežas

Programmatūras aizture, rindas dziļums, audio dzinēja periods, pavediena plānošanas laiks un pilna fiziskā aizture apraksta dažādus lielumus. Piemēram, XAudio2 rinda nenosaka visu intervālu no lietotāja darbības līdz skaņai no skaļruņa. Tā mērīšanai nepieciešams ārējs aprīkojums.

Līdzīgi atsevišķa procesa CPU laiks nav vienāds ar kopējo ietekmi uz FPS, frametime, enerģijas patēriņu vai sistēmas atsaucību. Šādi secinājumi tiek pārbaudīti ar atsevišķām metrikām.

Datu aizsardzība

Sākotnējie ETL, PML, notikumu žurnāli, atmiņas izgāztuves un reģistra eksporti pēc noklusējuma netiek publicēti. Sistēmas trasējumi var saturēt lietotājvārdus, ceļus, komandrindas, tīkla adreses un citus sensitīvus datus. Microsoft par to atsevišķi brīdina Sysinternals noteikumos.

Vietnē tiek ievietotas tikai manuāli atlasītas un anonimizētas tabulas. Mēs noņemam unikālos ierīču un instalāciju identifikatorus, lietotāja ceļus, kontu datus, tīkla identifikatorus, pieteikšanās datus un informāciju par procesiem, kas nav saistīti ar pētījumu.

Secinājumu labošana

Windows, draiveri un lietotnes mainās. Katrs raksts saņem pēdējās pārbaudes datumu un piemērojamības jomu. Ja jauns mērījums ir pretrunā ar vecu secinājumu, raksts tiek atjaunināts ar cēloņa skaidrojumu. Vecais rezultāts netiek automātiski pārnests uz jaunu būvējumu.

Neatkarība un preču zīmes

Pētījumus publicē BoosterX komanda, un tie var attiekties uz produkta funkcijām. Šis iespējamais interešu konflikts tiek ņemts vērā, jo metodika, izmērītās vērtības, ierobežojumi un negatīvie rezultāti tiek atdalīti no produkta ieteikuma.

BoosterX Wiki ir neatkarīga publikācija un nav saistīta, autorizēta, sponsorēta vai apstiprināta no Microsoft Corporation puses. Nosaukumi Microsoft un Windows tiek izmantoti tikai pētījuma priekšmeta precīzai aprakstīšanai. Sīkāk: Microsoft Trademark and Brand Guidelines.

Izmaiņu vēsture

• 2026-08-24: metodika publicēta.
• 2026-09-20: pievienota sadaļa “Kā pārbaudīt patstāvīgi”; izlabota saite uz peles datu avotu.

Metodikas pēdējā pārbaude: 2026-09-20.