Як ми досліджуємо Windows

У розділі «Дослідження Windows» ми перевіряємо конкретні технічні твердження. У кожній статті пояснюємо, що перевіряли, за яких умов і на які системи поширюється результат.

Наявність параметра, його вплив на роботу системи та приріст продуктивності потребують окремих доказів.

Що вважається доказом

Ми використовуємо кілька незалежних типів свідчень:

1. Первинна документація. Офіційні документи Microsoft, специфікації та документація виробника обладнання або застосунку.
2. Статичне спостереження. Ознаки реалізації в конкретній версії компонента. Таке спостереження обмежене дослідженою збіркою і саме собою не доводить виконання шляху під час роботи.
3. Динамічне спостереження. Системні події, стан компонентів і трасування, отримані в описаному сценарії.
4. Контрольоване вимірювання. Порівняння заздалегідь вибраної метрики за відомої зміни та перевіреного повернення стану.
5. Відтворення. Повтор результату в незалежному запуску, на іншій системі або збірці.

Внутрішні способи автоматизації збору та обробки не публікуються. Це не змінює вимоги розкривати досліджуване питання, конфігурацію, метрики, число прогонів і обмеження.

Статуси матеріалів

Статус	Значення
Документовано	Поведінка описана в первинному публічному джерелі.
Спостерігалося	Подію або стан виявлено у зазначеному середовищі.
Виміряно	Отримано числову різницю за описаною методикою.
Відтворено	Результат повторено незалежно.
Не відтворено	Заявлений ефект не виявлено в зазначених умовах.
Недостатньо даних	Методика або вибірка не дозволяють зробити висновок.

Статус стосується окремого твердження, а не автоматично всієї статті. Ми не використовуємо довільний відсоток довіри і не називаємо результат універсально доведеним без перевірки на інших системах.

Як будується експеримент

До вимірювання фіксуються:

• одне досліджуване питання;
• незалежна змінна;
• основна метрика та її одиниця;
• Windows build, суттєве обладнання, драйвери та версії застосунків;
• практично значущий поріг;
• спосіб повернення вихідного стану.

Ми порівнюємо вихідний і змінений стани, потім перевіряємо повернення. За можливості чергуємо порядок парних прогонів. Контролюємо прогрів, живлення, температури та фонове навантаження; якщо це неможливо, зазначаємо обмеження.

Окремі інтервали однієї траси показують зміни в часі, але не вважаються незалежними повторами. Результат віртуальної машини не можна автоматично переносити на фізичний комп’ютер. Для висновку про всі пристрої одного класу недостатньо перевірити один пристрій.

Фізичний click-to-photon стенд

Для ігрових досліджень ми використовуємо власний апаратний стенд. Він фізично вимірює повну затримку від електричного сигналу кнопки миші до зміни яскравості пікселя на екрані, без програмної оцінки цього інтервалу.

Основний тракт влаштований так:

1. Провід припаяний до лінії лівої кнопки Logitech G PRO X SUPERLIGHT першого покоління. Електричний фронт запускає таймер Arduino Uno.
2. Той самий клік проходить через контролер миші, USB, Windows, гру, чергу рендерингу, GPU і монітор.
3. Закріплений на екрані фотодатчик зупиняє таймер, коли яскравість тестової області перетинає заздалегідь вибраний поріг.
4. Один результат містить повний інтервал click-to-photon у мілісекундах.

Такий старт навмисно включає обробку контролером миші та її click debounce, але не включає механічний хід кнопки до замикання контакту. Ми не віднімаємо затримку миші з підсумкового значення. В актуальній методиці незалежних вимірювань RTINGS для G PRO X SUPERLIGHT зазначено 2.5 ms по кабелю і 3.1 ms через receiver. Низька виміряна click latency робить цю мишу придатною стабільною частиною стенда, але не перетворює результат на чисту затримку Windows або гри.

Окремий HID-мікроконтролер формату Arduino Nano може надсилати кліки в Windows автоматично. Цей маршрут використовується, коли потрібно прибрати відмінності ручного натискання і повторити вхідний сигнал у контрольованому темпі. Він відповідає на інше питання і не змішується із серіями, що починаються від фізичної лінії кнопки миші.

У CS2 використовується workshop-карта BXLAT, де клік викликає передбачувану зміну тестової області. Аналогічний візуальний сценарій застосовується у Valorant. Положення фотодатчика, роздільна здатність, частота монітора, ліміт FPS, режим display scaling, presentation mode і поріг світла фіксуються на всю порівнювану серію.

Поточний стандарт вимагає не менше 300 валідних кліків на стан. У нових серіях ми зберігаємо середнє, стандартне відхилення, мінімум, максимум, перцентилі, включно з P90, і розподіл для побудови графіків. Помилкові спрацювання, перевищення часу очікування та значення поза заздалегідь встановленим діапазоном позначаємо і враховуємо під час перевірки придатності серії.

Дослідження на цьому стенді ведуться кілька років, а формат зберігання за цей час змінювався. У публічній таблиці історичних вимірювань є серії по 300 кліків і раніші серії по 100. Для частини старих тестів збережено лише AVG, STDDEV, MIN і MAX; відсутні P90 або графіки не відновлюються з агрегатів і прямо позначаються як недоступні. Нові серії публікуватимуться з розширеною статистикою.

Що публікується в результаті

Стаття містить:

• коротку відповідь;
• досліджуване твердження;
• область дослідження;
• методику та число незалежних трас;
• значення метрик і розкид;
• підтверджені та непідтверджені висновки;
• виключені або забруднені метрики;
• обмеження;
• практичну рекомендацію без гарантії однакового результату;
• підтвердження повернення стану;
• первинні публічні джерела та дату перевірки.

Якщо результат не підтвердив популярну рекомендацію або функцію BoosterX, він усе одно може бути опублікований. Наявність налаштування в продукті не є доказом її ефективності.

Як перевірити самостійно

Значна частина динамічних спостережень з наших досліджень повторюється публічними інструментами: Sysinternals ProcMon для системних трасувань і WinDbg з публічними символами Microsoft. Базовий шлях перевірки виглядає так.

1. Читання параметра — ProcMon. Відкрийте Options → Configure Symbols і вкажіть публічний сервер символів Microsoft, щоб стеки показували імена модулів і функцій. Потім додайте фільтр Path contains — наприклад SystemResponsiveness з HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfile. За подіями читання видно, чи читається значення, коли і яким процесом.
2. Хто читає — стек виклику. Подвійний клік по події відкриває його властивості; на вкладці Stack показано ланцюжок модулів — це і є «читач» параметра. Наприклад, ланцюжок від user32.dll до win32kfull.sys означає, що за значення відповідає підсистема Win32k.
3. Поведінка в рантаймі — WinDbg. З публічними символами Microsoft можна поставити точку зупину на функції зі стека і подивитися, як прочитане значення застосовується.
4. Синтетичні тести. Змініть значення і виміряйте спостережувану поведінку. Наприклад, інтервали введення миші вимірюються публічними тестерами частоти опитування.

Честная межа. Статичний розбір бінарників і повні трасування у статтях не публікуються. Шлях вище повторює динамічну частину наших спостережень, але не замінює статичний аналіз — його висновки стосуються дослідженої збірки.

Межі вимірювання затримки

Програмна затримка, глибина черги, період аудіодвижка, час планування потоку і повна фізична затримка описують різні величини. Наприклад, черга XAudio2 не визначає весь інтервал від дії користувача до звуку з динаміка. Для його вимірювання потрібне зовнішнє обладнання.

Аналогічно, час CPU окремого процесу не дорівнює загальному впливу на FPS, frametime, витрату енергії або відзивчивість системи. Такі висновки перевіряються окремими метриками.

Захист даних

Вихідні ETL, PML, журнали подій, дампи пам’яті та експорти реєстру за замовчуванням не публікуються. Системні трасування можуть містити імена користувачів, шляхи, командні рядки, мережеві адреси та інші чутливі дані. Microsoft окремо попереджає про це в умовах Sysinternals.

На сайті розміщуються лише вручну відібрані та обезличені таблиці. Ми видаляємо унікальні ідентифікатори пристроїв і встановлень, користувацькі шляхи, дані облікових записів, мережеві ідентифікатори, дані для входу та відомості про процеси, не пов’язані з дослідженням.

Виправлення висновків

Windows, драйвери та застосунки змінюються. Кожна стаття отримує дату останньої перевірки та область застосовності. Якщо нове вимірювання суперечить старому висновку, стаття оновлюється з поясненням причини. Старий результат не переноситься на нову збірку автоматично.

Незалежність і торгові марки

Дослідження публікуються командою BoosterX і можуть стосуватися функцій продукту. Цей можливий конфлікт інтересів враховується тим, що методика, виміряні значення, обмеження та негативні результати відокремлюються від продуктової рекомендації.

BoosterX Wiki є незалежною публікацією і не пов’язана, не авторизована, не спонсорується і не схвалена Microsoft Corporation. Назви Microsoft і Windows використовуються лише для точного опису предмета дослідження. Докладніше: Microsoft Trademark and Brand Guidelines.

Історія змін

• 2026-08-24: методику опубліковано.
• 2026-09-20: додано розділ «Як перевірити самостійно»; виправлено посилання на джерело даних миші.

Остання перевірка методики: 2026-09-20.