Cara kami meneliti Windows

Di bagian «Riset Windows» kami memverifikasi klaim teknis yang spesifik. Di setiap artikel kami menjelaskan apa yang diuji, dalam kondisi apa, dan pada sistem mana hasilnya berlaku.

Keberadaan sebuah parameter, pengaruhnya terhadap kerja sistem, dan peningkatan performa memerlukan pembuktian tersendiri.

Apa yang dianggap sebagai bukti

Kami menggunakan beberapa jenis bukti yang independen:

1. Dokumentasi primer. Dokumen resmi Microsoft, spesifikasi, dan dokumentasi produsen perangkat keras atau aplikasi.
2. Pengamatan statis. Indikasi implementasi pada versi komponen tertentu. Pengamatan semacam ini terbatas pada build yang diteliti dan dengan sendirinya tidak membuktikan bahwa jalur tersebut dijalankan saat runtime.
3. Pengamatan dinamis. Peristiwa sistem, status komponen, dan trace yang diperoleh dalam skenario yang dijelaskan.
4. Pengukuran terkendali. Perbandingan metrik yang dipilih sebelumnya pada perubahan yang diketahui dan pengembalian status yang terverifikasi.
5. Reproduksi. Pengulangan hasil pada proses independen, pada sistem atau build lain.

Cara internal untuk mengotomatiskan pengumpulan dan pemrosesan tidak dipublikasikan. Hal ini tidak mengubah kewajiban untuk mengungkapkan pertanyaan yang diuji, konfigurasi, metrik, jumlah percobaan, dan batasannya.

Status materi

Status	Arti
Terdokumentasi	Perilaku dijelaskan dalam sumber publik primer.
Teramati	Peristiwa atau status ditemukan di lingkungan yang disebutkan.
Terukur	Selisih numerik diperoleh menurut metodologi yang dijelaskan.
Tereproduksi	Hasil diulang secara independen.
Tidak tereproduksi	Efek yang diklaim tidak ditemukan dalam kondisi yang disebutkan.
Data tidak cukup	Metodologi atau sampel tidak memungkinkan penarikan kesimpulan.

Status merujuk pada klaim tertentu, bukan secara otomatis pada keseluruhan artikel. Kami tidak menggunakan persentase kepercayaan yang arbitrer dan tidak menyebut hasil sebagai terbukti secara universal tanpa pengujian pada sistem lain.

Bagaimana eksperimen disusun

Sebelum pengukuran, hal-hal berikut ditetapkan:

• satu pertanyaan yang diuji;
• variabel independen;
• metrik utama dan satuannya;
• Windows build, perangkat keras yang signifikan, driver, dan versi aplikasi;
• ambang batas yang signifikan secara praktis;
• cara mengembalikan status awal.

Kami membandingkan status awal dan status yang diubah, lalu memverifikasi pengembaliannya. Jika memungkinkan, kami bergantian urutan percobaan berpasangan. Kami mengendalikan pemanasan, daya, suhu, dan beban latar belakang; jika hal ini tidak memungkinkan, kami menyebutkan batasannya.

Interval terpisah dalam satu trace menunjukkan perubahan sepanjang waktu, tetapi tidak dianggap sebagai pengulangan independen. Hasil dari mesin virtual tidak dapat secara otomatis diterapkan pada komputer fisik. Untuk menyimpulkan tentang semua perangkat dalam satu kelas, menguji satu perangkat saja tidak cukup.

Stand click-to-photon fisik

Untuk riset game kami menggunakan stand perangkat keras kami sendiri. Stand ini mengukur secara fisik total latensi dari sinyal listrik tombol mouse hingga perubahan kecerahan piksel di layar, tanpa estimasi perangkat lunak atas interval tersebut.

Jalur utamanya disusun sebagai berikut:

1. Kabel disolder ke jalur tombol kiri Logitech G PRO X SUPERLIGHT generasi pertama. Sinyal listrik memulai timer Arduino Uno.
2. Klik yang sama melewati controller mouse, USB, Windows, game, antrean rendering, GPU, dan monitor.
3. Sensor foto yang dipasang di layar menghentikan timer ketika kecerahan area uji melewati ambang batas yang dipilih sebelumnya.
4. Satu hasil berisi interval click-to-photon lengkap dalam milidetik.

Awal pengukuran semacam ini sengaja mencakup pemrosesan oleh controller mouse dan click debounce-nya, tetapi tidak mencakup gerakan mekanis tombol hingga kontak tertutup. Kami tidak mengurangi latensi mouse dari nilai akhir. Dalam metodologi pengukuran independen terkini RTINGS untuk G PRO X SUPERLIGHT tercatat 2.5 ms melalui kabel dan 3.1 ms melalui receiver. Click latency terukur yang rendah membuat mouse ini layak menjadi bagian stand yang stabil, tetapi tidak mengubah hasilnya menjadi latensi murni Windows atau game.

Mikrokontroler HID terpisah berformat Arduino Nano dapat mengirim klik ke Windows secara otomatis. Jalur ini digunakan ketika perlu menghilangkan perbedaan penekanan manual dan mengulang sinyal input pada tempo yang terkendali. Jalur ini menjawab pertanyaan yang berbeda dan tidak dicampur dengan seri yang dimulai dari jalur fisik tombol mouse.

Di CS2 digunakan workshop map BXLAT, di mana klik memicu perubahan area uji yang dapat diprediksi. Skenario visual serupa diterapkan di Valorant. Posisi sensor foto, resolusi, refresh rate monitor, batas FPS, mode display scaling, presentation mode, dan ambang cahaya ditetapkan untuk seluruh seri yang dibandingkan.

Standar saat ini mensyaratkan setidaknya 300 klik valid per kondisi. Pada seri baru kami menyimpan rata-rata, standar deviasi, minimum, maksimum, persentil, termasuk P90, dan distribusi untuk membuat grafik. Pemicuan yang salah, melebihi waktu tunggu, dan nilai di luar rentang yang ditetapkan sebelumnya kami tandai dan pertimbangkan saat memeriksa kelayakan seri.

Riset pada stand ini telah dilakukan selama beberapa tahun, dan format penyimpanannya berubah selama waktu itu. Di tabel publik pengukuran historis terdapat seri dengan 300 klik dan seri lama dengan 100 klik. Untuk sebagian tes lama hanya AVG, STDDEV, MIN, dan MAX yang tersimpan; P90 atau grafik yang hilang tidak direkonstruksi dari agregat dan ditandai secara langsung sebagai tidak tersedia. Seri baru akan dipublikasikan dengan statistik yang diperluas.

Apa yang dipublikasikan sebagai hasil

Artikel berisi:

• jawaban singkat;
• klaim yang diuji;
• cakupan riset;
• metodologi dan jumlah trace independen;
• nilai metrik dan sebarannya;
• kesimpulan yang terkonfirmasi dan tidak terkonfirmasi;
• metrik yang dikecualikan atau terkontaminasi;
• batasan;
• rekomendasi praktis tanpa jaminan hasil yang sama;
• konfirmasi pengembalian status;
• sumber publik primer dan tanggal pemeriksaan.

Jika hasilnya tidak mengonfirmasi rekomendasi populer atau fitur BoosterX, hasil tersebut tetap dapat dipublikasikan. Keberadaan sebuah pengaturan di produk bukanlah bukti efektivitasnya.

Cara memverifikasi sendiri

Sebagian besar pengamatan dinamis dari riset kami dapat diulang dengan alat publik: Sysinternals ProcMon untuk trace sistem dan WinDbg dengan simbol publik Microsoft. Jalur verifikasi dasarnya adalah sebagai berikut.

1. Membaca parameter — ProcMon. Buka Options → Configure Symbols dan tentukan server simbol publik Microsoft agar stack menampilkan nama modul dan fungsi. Lalu tambahkan filter Path contains — misalnya SystemResponsiveness dari HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfile. Dari peristiwa pembacaan terlihat apakah nilainya dibaca, kapan, dan oleh proses apa.
2. Siapa yang membaca — call stack. Klik ganda pada peristiwa akan membuka propertinya; pada tab Stack ditampilkan rantai modul — inilah «pembaca» parameter tersebut. Misalnya, rantai dari user32.dll ke win32kfull.sys berarti nilai tersebut ditangani oleh subsistem Win32k.
3. Perilaku saat runtime — WinDbg. Dengan simbol publik Microsoft, Anda dapat memasang breakpoint pada fungsi dari stack dan melihat bagaimana nilai yang dibaca diterapkan.
4. Tes sintetis. Ubah nilainya dan ukur perilaku yang teramati. Misalnya, interval input mouse diukur dengan penguji polling rate publik.

Batas yang jujur. Analisis statis biner dan trace lengkap tidak dipublikasikan dalam artikel. Jalur di atas mengulang bagian dinamis dari pengamatan kami, tetapi tidak menggantikan analisis statis — kesimpulannya berlaku untuk build yang diteliti.

Batas pengukuran latensi

Latensi perangkat lunak, kedalaman antrean, periode audio engine, waktu penjadwalan thread, dan latensi fisik total menggambarkan besaran yang berbeda. Misalnya, antrean XAudio2 tidak menentukan seluruh interval dari tindakan pengguna hingga suara dari speaker. Untuk mengukurnya diperlukan perangkat keras eksternal.

Demikian pula, waktu CPU satu proses tidak sama dengan pengaruh totalnya terhadap FPS, frametime, konsumsi daya, atau responsivitas sistem. Kesimpulan semacam itu diverifikasi dengan metrik terpisah.

Perlindungan data

ETL, PML, log peristiwa, dump memori, dan ekspor registry mentah secara default tidak dipublikasikan. Trace sistem dapat berisi nama pengguna, path, command line, alamat jaringan, dan data sensitif lainnya. Microsoft secara khusus memperingatkan hal ini dalam ketentuan Sysinternals.

Di situs hanya ditempatkan tabel yang dipilih secara manual dan telah dianonimkan. Kami menghapus pengenal unik perangkat dan instalasi, path pengguna, data akun, pengenal jaringan, data masuk, dan informasi tentang proses yang tidak terkait dengan riset.

Koreksi kesimpulan

Windows, driver, dan aplikasi berubah. Setiap artikel mendapatkan tanggal pemeriksaan terakhir dan cakupan keberlakuannya. Jika pengukuran baru bertentangan dengan kesimpulan lama, artikel diperbarui dengan penjelasan alasannya. Hasil lama tidak otomatis diterapkan pada build baru.

Independensi dan merek dagang

Riset dipublikasikan oleh tim BoosterX dan dapat berkaitan dengan fitur produk. Potensi konflik kepentingan ini diperhitungkan dengan memisahkan metodologi, nilai terukur, batasan, dan hasil negatif dari rekomendasi produk.

BoosterX Wiki adalah publikasi independen dan tidak terkait, tidak diotorisasi, tidak disponsori, dan tidak disetujui oleh Microsoft Corporation. Nama Microsoft dan Windows digunakan hanya untuk mendeskripsikan subjek riset secara akurat. Selengkapnya: Microsoft Trademark and Brand Guidelines.

Riwayat perubahan

• 2026-08-24: metodologi dipublikasikan.
• 2026-09-20: ditambahkan bagian «Cara memverifikasi sendiri»; diperbaiki tautan ke sumber data mouse.

Pemeriksaan metodologi terakhir: 2026-09-20.