Как мы исследуем 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.