Win32PrioritySeparation: затримка та FPS при повному завантаженні CPU

Коротка відповідь: Win32PrioritySeparation справді керує foreground boost і частиною політики квантів CPU. Наш історичний тест не виявив універсально кращого значення. Windows default показав трохи меншу середню click-to-photon затримку, а 0x1A збігся з найкращими FPS і P1 в одному тесті при 100% завантаженні CPU. Через відсутність незалежних FPS-повторів і сирих click samples рекомендуємо default, а 0x1A вважаємо лише перевірюваною гіпотезою для CPU-сценарію.

Статус: зв’язок параметра з foreground boost документовано Microsoft. Читання параметра спостерігалося в раніше зібраних системних трасуваннях Windows 11 24H2 і 25H2. Користувацький ефект виміряно в історичній серії Windows 10 22H2, але на іншій системі або в незалежному запуску не відтворено.

Перевірюване твердження

Ми перевіряли три різні твердження, які не можна об’єднувати:

1. Параметр існує і пов’язаний з політикою планувальника Windows.
2. Значення 0x02 і 0x1A представляють різні політики квантів при однаковому максимальному foreground boost.
3. 0x1A покращує FPS або затримку гри при повному завантаженні CPU.

Перші два твердження підтверджуються публічною документацією і спостереженням на досліджених збірках. Третє потребує вимірювань і не стає істинним лише через устрій параметра.

Область дослідження

Шар	Середовище	Результат
Публічна документація	Microsoft WMI, CPU Analysis і Windows Internals	Описано foreground boost, quantum і історичну бітову структуру
Системне спостереження	Windows 11 24H2 і 25H2	Читання параметра спостерігалося в раніше зібраних трасуваннях
Click-to-photon	Windows 10 22H2, Valorant, CPU 100%	По 300 вимірювань на значення, збережено агрегати
FPS	Та сама історична серія	Один CapFrameX capture на конфігурацію; частина рядків непридатна через зависання capture

Windows 10 22H2 dynamic trace для цієї публікації відсутній. Для Windows 11 26H1 також немає придатної трасування. Вимірювання Windows 10 не переносяться на Windows 11 без повторення.

Де знаходиться параметр

Поле	Значення
Hive і шлях	HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\PriorityControl
Ім’я значення	Win32PrioritySeparation
Тип	REG_DWORD
Документоване початкове значення client Windows	0x02 (2)

Windows Internals називає 2 початковим значенням на клієнтській Windows і на сервері, який не налаштований як application server. У нашій трасуванні Windows 11 25H2 DWORD також був присутній явно зі значенням 2.

Тому ми не вважаємо відсутність значення універсальним Windows default. Воно може зустрітися після зміни образу, ручного видалення або дій стороннього інструмента, але в поточному дослідженні clean-install сценарій з відсутнім DWORD динамічно не відтворено. Відсутність рядка не можна автоматично трактувати як 0.

Як влаштований параметр

Microsoft зіставляє властивість Win32_OperatingSystem.ForegroundApplicationBoost з Win32PrioritySeparation і документує значення 0, 1 і 2: без boost, мінімальний і максимальний boost foreground application.

Офіційний sample Windows Internals Sixth Edition описує параметр як набір полів:

Біти	Призначення
0-1	Ступінь foreground boost
2-3	Змінні або фіксовані кванти
4-5	Короткі або довгі кванти

0x02 є документованим початковим значенням client Windows: воно задає максимальний foreground boost, а інші поля залишає системній політиці. Для клієнтської Windows історично це відповідає коротким змінним квантам, які можна явно виразити як 0x26. 0x1A задає довгі фіксовані кванти при тому самому максимальному foreground boost.

Відкритий проєкт Win32PSCalculator показує цю еквівалентність напряму. Він маскує вхід через 0x3F, розбирає три двобітових поля і зводить різні записи до однієї з 12 канонічних комбінацій. Це допомагає виявити placebo-значення, які виглядають інакше, але не створюють нового scheduler mode.

Документ Windows Internals є історичним. Ми використовуємо його для інтерпретації полів, але не стверджуємо, що всі внутрішні quantum tables незмінні у всіх сучасних збірках.

Калькулятор значень

Декодер 6 біт

Перевірка реального режиму

Win32PSCalculator ↗

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

Значення Registry

Розібрати

Hex із префіксом 0x, без префікса — decimal.

Default 0x02Явний default 0x26За ситуацією 0x1A

Еквівалентний режим0x26

Windows default: на клієнтській Windows відповідає явному режиму 0x26.

000010

Введено

0x00000002 · 2

Після маски 0x3F

0x02 · 2

Кванти

Системний default → короткі

Тип

Системний default → змінні

Посилення foreground

Максимальний · 3:1

Калькулятор працює лише в браузері і не читає і не змінює Registry. Його результат показує еквівалентність бітових комбінацій, а не очікуваний FPS або затримку. Та сама версія доступна на сторінці налаштування BoosterX.

Чому результат може залежати від навантаження

Планувальник вибирає готовий потік з урахуванням priority, affinity, стану і залишкового quantum. Після вичерпання quantum потік може поступитися процесором іншому готовому потоку того самого priority. Перемикання контексту має вартість, тому довші кванти здатні зменшити scheduler turnover і підтримати throughput при сильній конкуренції за CPU.

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

Методика історичного тесту

Тест виконувався у Valorant на Windows 10 22H2 при записаному 100% завантаженні CPU. Для кожного Registry-значення виконано 300 click-to-photon вимірювань апаратним стендом BoosterX. Електричний сигнал кнопки Logitech G PRO X SUPERLIGHT запускає таймер, а фотодатчик зупиняє його після зміни яскравості на екрані. Повний тракт описано в методиці досліджень.

У таблиці збереглися AVG, STDDEV, MIN і MAX затримки. Для FPS використовувався CapFrameX, але в доступному блоці є лише один capture на конфігурацію. Для частини значень capture зависав, тому ці FPS-рядки позначені як недоступні і не відновлюються припущеннями.

Вихідні 300 click samples, P90, розподіли, точний hardware/driver manifest і незалежні FPS-повтори до цієї старої серії не прив’язані. Це обмежує статистичний висновок.

Результати

Значення	Політика	AVG, ms	SD, ms	MIN, ms	MAX, ms	FPS AVG	P1	P0.1
0x2A	коротка, фіксована, високий boost	16.61	2.69	10.53	21.96	351.3	226.2	43.9
0x29	коротка, фіксована, середній boost	17.08	3.02	10.31	25.09	336.8	254.9	14.3
0x28	коротка, фіксована, без boost	17.62	4.94	10.19	47.04	н/д	н/д	н/д
0x26	явний еквівалент default 0x02	15.28	3.12	9.30	23.08	334.4	111.6	36.9
0x25	коротка, змінна, середній boost	16.90	2.73	11.42	23.97	334.7	102.6	27.6
0x24	коротка, змінна, без boost	18.71	4.66	11.88	32.48	н/д	н/д	н/д
0x1A	довга, фіксована, високий boost	15.68	3.31	9.97	23.30	355.1	256.0	41.0
0x19	довга, фіксована, середній boost	16.80	2.61	10.08	21.95	352.0	272.9	21.5
0x18	довга, фіксована, без boost	22.74	8.81	11.65	55.10	н/д	н/д	н/д
0x16	довга, змінна, високий boost	16.77	2.88	11.32	23.97	346.4	200.1	34.0
0x15	довга, змінна, середній boost	16.13	2.34	10.08	20.95	332.1	144.4	17.8
0x14	довга, змінна, без boost	19.87	5.55	12.43	52.31	н/д	н/д	н/д

н/д означає непридатний або відсутній FPS capture, а не нульовий результат.

Порівняння default і 0x1A

Метрика	Default / еквівалент 0x26	0x1A	Спостережувана різниця
Click-to-photon AVG	15.28 ms	15.68 ms	0x1A вище на 0.40 ms, близько 2.6%
Click-to-photon SD	3.12 ms	3.31 ms	0x1A вище на 0.19 ms
FPS AVG	334.4	355.1	0x1A вище на 20.7, близько 6.2%
P1	111.6	256.0	0x1A вище на 144.4
P0.1	36.9	41.0	0x1A вище на 4.1

Різниця середньої затримки 0.40 ms помітно менша за збережений розкид близько 3 ms. Без сирих samples не можна коректно побудувати довірчий інтервал або перевірити форму розподілу. FPS-різниця велика за описовими числами, але один capture на стан не доводить відтворюваність і не виключає вплив порядку прогонів або фонового навантаження.

Що підтверджено

• Параметр пов’язаний з foreground boost і політикою квантів планувальника Windows.
• Його читання спостерігалося в досліджених Windows 11 24H2 і 25H2.
• В історичній Windows 10 22H2 серії виконано по 300 click-to-photon вимірювань на значення.
• Серед станів з високим foreground boost default-еквівалент 0x26 показав найменшу середню затримку.
• У тому самому історичному capture 0x1A показав найбільший FPS AVG і P1 серед станів з високим boost.

Що не підтверджено

• Що 0x1A завжди підвищує FPS, P1 або плавність кадрів.
• Що 0x1A зменшує click-to-photon або input latency.
• Що результат повторюється на Windows 11, іншому CPU, в іншій грі або без повного завантаження CPU.
• Що довільні значення з чужих tweak-списків корисні або безпечні.
• Що різниці статистично значущі: для старої серії немає сирих samples і незалежних FPS-повторів.

Обмеження

Історична таблиця не містить повного прив’язаного manifest обладнання, версій драйвера і гри, температури, power state і порядку прогонів. Вікна одного capture не вважаються незалежними повторами. Помилки CapFrameX зачепили переважно стани без foreground boost, тому повну FPS-матрицю порівнювати не можна.

Дослідження і використані інструменти належать розробнику BoosterX, який надає це налаштування, тому в розробника є прямий інтерес до результатів. Методика і межі застосовності описані вище, а висновки можна перевірити за відкритими даними і переліченими публічними джерелами. Тому default залишається рекомендацією, а вищий історичний FPS 0x1A публікується разом з негативним результатом щодо середньої затримки і всіма обмеженнями.

Практичний висновок

Залишайте Windows default (0x02) на більшості клієнтських систем Windows 10 і 11. Не застосовуйте 0x1A як універсальну «оптимізацію планувальника». Windows Server має іншу scheduler policy, не вимірювався і не входить до цієї рекомендації.

Перевірка 0x1A виправдана лише при відтворюваному CPU saturation. Використовуйте кілька парних прогонів, перемішуйте порядок, фіксуйте середній FPS, P1, P0.1, frametime spikes і click-to-photon. Залишайте зміну лише при повторюваному покращенні цільової метрики без нового погіршення.

Сторінка безкоштовного налаштування і точний спосіб повернення: Win32PrioritySeparation в BoosterX.

Відновлення стану

Після порівняння поверніть параметр у Windows default (0x02) через BoosterX і виконайте запропонований інтерфейсом перезапуск. В історичному наборі окремий запис про перевірку повернення не зберігся, тому це дослідження не вважає recovery підтвердженою частиною старого експерименту.

Публічні первинні джерела

• Win32_OperatingSystem.ForegroundApplicationBoost, Microsoft Learn - Registry mapping і значення foreground boost.
• CPU Analysis, Microsoft Learn - quantum, priority, processor selection і вартість context switches.
• Scheduling Priorities, Microsoft Learn - round-robin, preemption і dynamic priority.
• Context Switches, Microsoft Learn - що відбувається при перемиканні потоку.
• Windows Internals Sixth Edition sample chapters, Microsoft Press - історичний опис полів параметра і клієнтських квантів.
• Публічна таблиця click-to-photon вимірювань BoosterX - вихідні опубліковані агрегати цієї історичної серії.
• Win32PSCalculator - відкрита реалізація декодування молодших шести біт і пошуку еквівалентного режиму.

Публічні джерела і формулювання перевірені: 2026-08-24.

Історія змін

• 2026-09-20: дисклеймер про конфлікт інтересів посилено до повного формулювання з належністю дослідження і інструментів.
• 2026-08-24: додано точне розташування Registry value, документоване початкове значення 0x02, Win32PSCalculator і межі трактування відсутнього DWORD.
• 2026-08-24: перша публікація; додано повну історичну матрицю, розділення механізму і користувацького ефекту, а також default-рекомендацію.