콘텐츠로 이동

Win32PrioritySeparation: 전체 CPU 부하 시 지연 시간과 FPS

목차

짧은 답변: Win32PrioritySeparation는 실제로 foreground boost와 CPU quantum 정책의 일부를 제어합니다. 당사의 과거 테스트에서는 보편적으로 더 나은 값이 확인되지 않았습니다. Windows default는 평균 click-to-photon 지연이 약간 더 낮았고, 0x1A는 CPU 100% 부하에서 한 테스트의 최고 FPS 및 P1과 일치했습니다. 독립적인 FPS 반복 측정과 원시 click sample이 없기 때문에 default를 권장하며, 0x1A는 CPU 시나리오에 대한 검증 가능한 가설로만 간주합니다.

상태: 이 매개변수와 foreground boost의 관계는 Microsoft에 의해 문서화되어 있습니다. 매개변수 읽기는 이전에 수집된 Windows 11 24H2 및 25H2 시스템 추적에서 관찰되었습니다. 사용자 효과는 과거 Windows 10 22H2 시리즈에서 측정되었지만, 다른 시스템이나 독립 실행에서는 재현되지 않았습니다.

검증 가능한 주장

섹션 제목: “ 검증 가능한 주장”

당사는 함께 묶을 수 없는 세 가지 서로 다른 주장을 검증했습니다:

  1. 이 매개변수는 존재하며 Windows 스케줄러 정책과 관련이 있습니다.
  2. 0x02와 0x1A 값은 동일한 최대 foreground boost에서 서로 다른 quantum 정책을 나타냅니다.
  3. 0x1A는 CPU가 완전히 부하된 상태에서 FPS 또는 게임 지연을 개선합니다.

처음 두 주장은 공개 문서와 조사된 빌드에서의 관찰로 확인됩니다. 세 번째는 측정이 필요하며, 매개변수의 구조만으로는 참이 되지 않습니다.

연구 범위

섹션 제목: “ 연구 범위”
계층 환경 결과
공개 문서 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로 간주하지 않습니다. 이는 이미지 수정, 수동 삭제 또는 타사 도구의 동작 후에 나타날 수 있지만, 현재 연구에서 DWORD가 없는 clean-install 시나리오는 동적으로 재현되지 않았습니다. 행의 부재를 자동으로 0로 해석할 수 없습니다.

매개변수의 구조

섹션 제목: “ 매개변수의 구조”

Microsoft는 Win32_OperatingSystem.ForegroundApplicationBoost 속성을 Win32PrioritySeparation와 대응시키고 0, 1 및 2 값을 문서화합니다: boost 없음, 최소 및 최대 foreground application boost.

공식 Windows Internals Sixth Edition sample은 이 매개변수를 필드 집합으로 설명합니다:

비트 용도
0-1 foreground boost 정도
2-3 가변 또는 고정 quantum
4-5 짧은 또는 긴 quantum

0x02는 client Windows의 문서화된 초기 값입니다: 최대 foreground boost를 설정하고 나머지 필드는 시스템 정책에 맡깁니다. 클라이언트 Windows의 경우 역사적으로 이는 짧은 가변 quantum에 해당하며, 이를 0x26로 명시적으로 표현할 수 있습니다. 0x1A는 동일한 최대 foreground boost에서 긴 고정 quantum을 설정합니다.

공개 프로젝트 Win32PSCalculator는 이 동등성을 직접 보여줍니다. 이는 입력을 0x3F로 마스킹하고, 세 개의 2비트 필드를 파싱하며, 서로 다른 기록을 12개의 정규 조합 중 하나로 환원합니다. 이는 다르게 보이지만 새로운 scheduler mode를 만들지 않는 placebo 값을 발견하는 데 도움이 됩니다.

Windows Internals 문서는 역사적입니다. 당사는 이를 필드 해석에 사용하지만, 모든 내부 quantum table이 모든 현대 빌드에서 불변이라고 주장하지는 않습니다.

값 계산기

섹션 제목: “ 값 계산기”

6비트 디코더

실제 모드 확인

Win32PSCalculator ↗

tweak 목록에서 찾은 값을 입력하세요. 계산기는 사용된 6비트와 동일한 모드의 표준 조합만 표시합니다. 컴퓨터의 어떤 것도 변경하지 않습니다.

0x 접두사가 있는 Hex, 접두사 없으면 decimal.

동등 모드0x26

Windows default: 클라이언트 Windows에서 명시적 모드 0x26에 해당합니다.

000010
입력됨
0x00000002 · 2
0x3F 마스크 후
0x02 · 2
퀀텀
시스템 default → 짧은 것
유형
시스템 default → 가변
foreground 부스트
최대 · 3:1

계산기는 브라우저에서만 작동하며 Registry를 읽거나 수정하지 않습니다. 그 결과는 비트 조합의 동등성을 보여주며, 예상 FPS나 지연을 보여주지 않습니다. 동일한 버전을 BoosterX 설정 페이지에서 사용할 수 있습니다.

결과가 부하에 따라 달라질 수 있는 이유

섹션 제목: “ 결과가 부하에 따라 달라질 수 있는 이유”

스케줄러는 priority, affinity, 상태 및 남은 quantum을 고려하여 준비된 스레드를 선택합니다. quantum이 소진된 후 스레드는 동일한 priority의 다른 준비된 스레드에 프로세서를 양보할 수 있습니다. 컨텍스트 전환에는 비용이 발생하므로, 더 긴 quantum은 scheduler turnover를 줄이고 CPU 경합이 심할 때 throughput을 유지할 수 있습니다.

이는 효과의 가능한 방향을 설명하지만, 게임 성능 향상을 약속하지는 않습니다. 더 긴 고정 quantum은 동시에 다른 스레드의 응답성을 악화시킬 수 있습니다. CPU가 제한 요인이 아니라면 측정 가능한 이득이 없을 수 있습니다.

과거 테스트 방법론

섹션 제목: “ 과거 테스트 방법론”

테스트는 Windows 10 22H2에서 기록된 CPU 100% 부하 상태로 Valorant에서 수행되었습니다. 각 Registry 값에 대해 BoosterX 하드웨어 스탠드로 300회의 click-to-photon 측정을 수행했습니다. Logitech G PRO X SUPERLIGHT 버튼의 전기 신호가 타이머를 시작하고, 광센서가 화면 밝기 변화 후 타이머를 정지시킵니다. 전체 경로는 연구 방법론에 설명되어 있습니다.

표에는 AVG, STDDEV, MIN 및 MAX 지연이 보존되어 있습니다. FPS에는 CapFrameX를 사용했지만, 사용 가능한 블록에는 구성당 capture가 하나뿐입니다. 일부 값의 경우 capture가 정지되었으므로 해당 FPS 행은 사용 불가로 표시되며 추측으로 복원되지 않습니다.

원시 300 click sample, 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 n/a n/a n/a
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 n/a n/a n/a
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 n/a n/a n/a
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 n/a n/a n/a

н/д는 0의 결과가 아니라 사용 불가하거나 누락된 FPS capture를 의미합니다.

default와 0x1A 비교

섹션 제목: “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의 분산보다 현저히 작습니다. 원시 sample 없이는 신뢰 구간을 올바르게 구성하거나 분포 형태를 검증할 수 없습니다. FPS 차이는 서술적 수치로는 크지만, 상태당 capture 하나로는 재현성을 증명하지 못하며 실행 순서나 백그라운드 부하의 영향을 배제하지 못합니다.

확인된 사항

섹션 제목: “ 확인된 사항”
  • 이 매개변수는 foreground boost 및 Windows 스케줄러 quantum 정책과 관련이 있습니다.
  • 그 읽기는 조사된 Windows 11 24H2 및 25H2에서 관찰되었습니다.
  • 과거 Windows 10 22H2 시리즈에서 값당 300회의 click-to-photon 측정이 수행되었습니다.
  • 높은 foreground boost 상태 중에서 default 등가 0x26가 가장 낮은 평균 지연을 보였습니다.
  • 동일한 과거 capture에서 0x1A가 높은 boost 상태 중 가장 높은 FPS AVG 및 P1을 보였습니다.

확인되지 않은 사항

섹션 제목: “ 확인되지 않은 사항”
  • 0x1A가 항상 FPS, P1 또는 프레임 부드러움을 높인다는 것.
  • 0x1A가 click-to-photon 또는 input latency를 줄인다는 것.
  • 그 결과가 Windows 11, 다른 CPU, 다른 게임 또는 CPU 완전 부하가 아닌 상태에서 반복된다는 것.
  • 다른 사람의 tweak 목록에 있는 임의의 값이 유용하거나 안전하다는 것.
  • 차이가 통계적으로 유의하다는 것: 오래된 시리즈에는 원시 sample과 독립적인 FPS 반복 측정이 없습니다.

제한 사항

섹션 제목: “ 제한 사항”

과거 표에는 완전히 연결된 하드웨어 manifest, 드라이버 및 게임 버전, 온도, power state 및 실행 순서가 포함되어 있지 않습니다. 하나의 capture 내 창은 독립적인 반복으로 간주되지 않습니다. CapFrameX 오류는 주로 foreground boost가 없는 상태에 영향을 미쳤으므로 전체 FPS 행렬을 비교할 수 없습니다.

연구와 사용된 도구는 이 설정을 제공하는 BoosterX 개발자에게 속하므로, 개발자는 결과에 직접적인 이해관계가 있습니다. 방법론과 적용 범위는 위에 설명되어 있으며, 결론은 공개 데이터와 나열된 공개 출처를 통해 검증할 수 있습니다. 따라서 default가 권장 사항으로 남으며, 더 높은 과거 FPS 0x1A는 평균 지연에 대한 부정적 결과와 모든 제한 사항과 함께 게시됩니다.

실용적 결론

섹션 제목: “ 실용적 결론”

대부분의 클라이언트 Windows 10 및 11 시스템에서는 **Windows default (0x02)**를 유지하십시오. 0x1A를 보편적인 “스케줄러 최적화”로 적용하지 마십시오. Windows Server는 다른 scheduler policy를 가지며, 측정되지 않았고 이 권장 사항에 포함되지 않습니다.

0x1A의 검증은 재현 가능한 CPU saturation에서만 정당화됩니다. 여러 쌍의 실행을 사용하고, 순서를 섞고, 평균 FPS, P1, P0.1, frametime spike 및 click-to-photon을 기록하십시오. 새로운 악화 없이 대상 지표가 반복적으로 개선될 때만 변경을 유지하십시오.

무료 설정 페이지 및 정확한 복원 방법: BoosterX의 Win32PrioritySeparation.

상태 복원

섹션 제목: “ 상태 복원”

비교 후 BoosterX를 통해 매개변수를 **Windows default (0x02)**로 되돌리고 인터페이스에서 제안하는 재시작을 수행하십시오. 과거 데이터 세트에는 복원 검증에 대한 별도의 기록이 보존되지 않았으므로, 이 연구는 recovery를 오래된 실험의 확인된 부분으로 간주하지 않습니다.

공개 1차 출처

섹션 제목: “ 공개 1차 출처”

공개 출처와 문구는 2026-08-24에 검증되었습니다.

변경 이력

섹션 제목: “변경 이력”
  • 2026-09-20: 이해관계 충돌에 대한 면책 조항이 연구 및 도구의 소유권을 포함한 완전한 문구로 강화되었습니다.
  • 2026-08-24: 정확한 Registry value 위치, 문서화된 초기 값 0x02, Win32PSCalculator 및 누락된 DWORD 해석의 경계가 추가되었습니다.
  • 2026-08-24: 최초 게시; 전체 과거 행렬, 메커니즘과 사용자 효과의 분리, 그리고 default 권장 사항이 추가되었습니다.