소프트웨어 IRQ설정으로 시스템 속도향상의 진실

10여년 전에 처음 퍼졌던 헛소문이 아직 까지도 사실 처럼 떠돌고 있다는 것을 보니까
너무 놀랍다는걸 다시 느낀 답니다.
글을 쓸까 말까 하다가 이제서야 쓴답니다.

그 논란을 종결 시켰던 기사에서 원문을 뽑아 번역해 드리는 거랍니다.

원문:
10. IRQ8Priority

An Interrupt Request (IRQ) is a signal used by devices to grab the attention of your CPU. A common speed-up tweak says you can improve your PCs performance by changing the priority of some of these IRQs, particularly #8, the system clock. And to do this you must point REGEDIT at KEY_LOCAL_MACHINE\SystemCurrentControlSetControlPriorityControl, create a new DWORD value called IRQ8Priority and set it to 1 (for the highest priority).

There are problems with this idea, though.

Like, it doesn't make any sense: there's no reason to believe that somehow boosting the priority of the system clock would help your system speed (and no-one suggesting this ever offers an explanation).

And we couldn't find a single reference to the setting on Microsoft's site.

Still, we couldn't find anything from Microsoft debunking the tip, either, so we decided to try it out for ourselves. We benchmarked a Windows Vista PC using Passmark PerformanceTest, and it scored 756.0.

We applied the IRQ8Priority tweak, rebooted, ran PerformanceTest again and scored: 748.1, fractionally slower. It hadn't really cut our performance, this was within the benchmark's margin of error, but it hadn't improved our system speeds, either. Like so many PC optimisation tweaks, IRQ8Priority turned out to do nothing useful at all.

10. IRQ8Priority

번역:
IRQ는 CPU 의 명령을 잡아채기 위한 장치들에 의해 이용되는 하나의 신호이다.
(역주.한마디로 cpu의 인터럽트 신호를 전달해주는 역할)
알려진 속도향상 트윅은 이런 IRQ들 가운데 일부 우선순위 변경에 의해 컴퓨터 퍼포먼스를 향상시킬 수 있다고 한다.(특히 시스템 시계가 사용하는 IRQ 8번)
이렇게 하기 위해서는 레지스트리 HKEY_LOCAL_MACHINE\SystemCurrentControlSetControlPriorityControl 위치에서 IRQ8Priority 라 불리는 새 DWORD 값을 만들고 그 값을 1로 지정해 줘야 한다.
(1이란 값은 가장 높은 우선 순위로 할당해 주는 것)
그렇다고는 하지만 이 아이디어에는 문제점들이 있다.
저건 말도 안된다: 어떻게 해서든 시스템 시계의 우선순위를 끌어 올리는 것이 시스템 속도 향상을 돕는다는 것은 아무래도 믿을 수 없다라고 하는 말 처럼.
(지금 까지 그 누구도 하나의 설명 조차 내놓은 적도 없다)
그리고 마이크로소프트 사이트에서 조차 단 하나의 참고할 만한 것들을 찾을 수도 없었다.
여전히 그 팁의 실체를 벗겨낼만한 것들 역시 마이크로소프트에서 찾을 수 가 없었다.
그래서 우린 직접 그걸 실험해 보기로 결심 했다.
Passmark 퍼포먼스테스트를 이용해 윈도우 비스타 컴퓨터를 벤치마크 해봤다, 그 결과 756.0 점을 기록했다.
그리고 나서 IRQ8Priority 트윅을 적용해 준 뒤 리부팅하고 퍼포먼스테스트를 다시 실행 시켰다.
그 결과 748.1 점을 기록 했고 약간 느려졌다.
그러나 이것은 벤치마크 허용 오차 범위에 속하므로 퍼포먼스를 실제로 잘라 먹지는 않았지만 그렇다고 시스템 속도가 향상 향상된 것도 아니었다.
이렇듯 아주 많은 컴퓨터 최적화 트윅들과 IRQ8Priority 는 전혀 유용하지 않다는 것으로 밝혀졌다.
(역주. 여기서 말하는 트윅들은 기사 내용 중 1번 부터 10번(IRQ8Priority)항목 까지를 말함)

참고.
https://www.techradar.com/news/software/operating-systems/10-windows-speed-tips-that-don-t-work-686087?artc_pg=2

그러나 위의 기사로는 만족 못하는 사람들이 있자 새로운 종결자가 나타났었답니다.
지금 부터 그 논란의 종결자인 Jamie Hanrahan를 소개 합니다.

주의!
컴퓨터 시스템에 대한 전반적인 지식과 개념이 하나라도 부족한 분들은 이해 하기 힘들답니다.
(논란이 시작된 아래 글에 달린 리플 중에서 https://qaos.com/article.php?sid=1114 를 링크 하셨는데 그 링크에 나온 설명을 쓴 사람 조차 윈도우 시스템에 대한 지식과 개념이 부족하답니다.)
그런 분들은 위의 기사 정도로 만족하셔도 된답니다.

원문:

Jamie Hanrahan of Windows Driver Consulting and Training (www.cmkrnl.com) provides a compelling explanation for why this does not work:

"There is an easy (although I must admit not definitive) way to demonstrate that the system is unaware of this registry value. To do this requires the www.sysinternals.com utility called "strings". If you're not familiar with it, it's a Win32 character-mode version of something Unix has had for decades (not that I'm a Unix fan...) You use it like so:
c:> strings file.d a t

and it emits all printable sequences of characters from file.d a t, one per line. It's very useful when searching exe's and the like for things like file names, registry keys and values, etc. (And it's a favorite cracker's tool.) Much better than examining diskprobe output looking for printable strings! And unlike the Unix version this one works for either Unicode or Ascii.

Ok, so we do this:
c:> strings \windows\system32\ntoskrnl.e x e > ntstrings.txt

Actually that produces more output than is useful. Let's try a minimum string length of 8, that being the number of characters in "priority":
c:> strings \windows\system32\ntoskrnl.e x e -n 8 > ntstrings.txt

Add the -a option to get the ascii strings instead:
c:> strings \windows\system32\ntoskrnl.e x e -a -n 8 > ntstringsa.txt

Now of course we open ntstrings.txt and ntstringsa.txt in Notepad, or your favorite other text editor.

If you search in the files for, for example, "LargeSystemCache" or "DisablePagingExecutive", you WILL find them. Those are the constant strings compiled into the exec by which it looks up those well-known registry values.

But you WON'T find "IRQ8Priority". In fact you won't even find "priority" by itself, in either the ASCII or unicode strings -- otherwise we could still think that the system was building up the name "IRQ8Priority" from shorter strings, perhaps looking for IRQ0Priority, IRQ1Priority, etc., with the number being a variable.

Actually we could still think that; the string could be "assembled" from even smaller fragments, and that's why I say this isn't absolutely definitive -- but I think this is very unlikely. Some other data points:

Interrupts -- IRQs -- don't even HAVE a concept of "priority" in the NT family; they do have something called "IRQL" (interrupt request level) associated with them.
But the interval timer interrupt is already assigned a higher IRQL than any IO devices, second only to the inter-processor interrupt used in an MP machine.

The NT family of OSs don't even use the real-time clock (IRQ8) for timekeeping in the first place!
They use programmable interval timer (8254, on IRQ0) for driving system timekeeping, CPU time accounting, and so on.
IRQ8 is used for profiling, but profiling is almost never turned on except in very rare development environments.

The same "strings" output will show that another long-written-about registry hack, IoPageLockLimit, is also missing in action.
This one at least used to be there, in Win2K RTM and earlier; in Win2K SP1 they kept the mechanism but the limit was then spec'd by a new value, IoPageLockPercentage; in Win2K SP2 and later they dropped the whole thing.
I have to conclude that all reports of increased performance after making the IRQ8Priority registry change,
and IoPageLockLimit on Win2K SP1 and later, are due to _post hoc_ fallacy and/or placebo effect.
IoPageLockLimit at least worked at one time (though the values suggested on almost every web site that mentions it actually cause the system to end up using its default of 512K anyway!).
I don't know where the IRQ8Priority thing came from; it's too obscure to have been made up out of whole cloth -- maybe it was valid for some version of Win9x?"

번역:

Windows Driver Consulting and Training(www.cmkrnl.com , Kernel Mode Systems) 사의 사장인
Jamie Hanrahan은  왜 이것이 작동하지 않는지에 대한 강력한 설명을 제공해 준다.
시스템이 이 레지스트리 값을 인식하지 못한다는 것을 증명하기 쉬운(명확한 것은 아니란 것을 인정해야 하겠지만 말이다) 방법이 있다.
이렇게 하기 위해서는 "strings"라 불리는 the www.sysinternals.com의 유틸리티가 필요하다.

여러분이 그게 뭔지 잘 모른다면 그것은 바로 수십 년 동안 써온 유닉스류의 Win32 문자모드 버전이라고 알아 두면 된다.
사용법은 이렇다:

c:> strings file.d a t

그러면 file.d a t 로 부터 라인 하나당 하나씩 출력 할 수 있는 문자 배열을 내보낸다.  이것은 exe와 그밖에 파일명, 레지스트리키와 값 등을 찾을 때 아주 유용하다.
(인기 있는 크레커의 툴 중 하나다)
출력할 수 있는 string들을 찾는 DiskProbe 출력 시험하는 것 보다 훨씬 낫다! (역주. DiskProbe- 윈도우시스템에서 사용 할 수 있는 디스크 섹터 에디터)
그리고 유닉스 버전과는 달리 이 녀석은 유니코드나 아스키 문자에 대해서도 동작한다.

좋다 이제 이렇게 해본다:

c:> strings \windows\system32\ntoskrnl.e x e > ntstrings.txt

실제 저것은 유용한 것 이상의 출력물을 산출한다. 자 이제 "priority"의 문자들의 수가 되는 8 자리의 길이인 최소 string를 시도해 보자:

c:> strings \windows\system32\ntoskrnl.e x e -n 8 > ntstrings.txt

ascii string을 얻기 위한 옵션인 -a를 추가 해라:

c:> strings \windows\system32\ntoskrnl.e x e -a -n 8 > ntstringsa.txt

이제 메모장이나 다른 텍스트 에디터에서 ntstrings.txt 와 ntstringsa.txt를 열어 봐라. 
 
예를 들어 "LargeSystemCache" 또는 "DisablePagingExecutive" 대한 파일들을 찾는 다면 그 것들을 찾을 수 있을 것이다.
그것들은 exec 안에 컴파일된 상수 string들이면서 잘 알려진 레지스트리 값을 검색한다.
그러나 여러분은 "IRQ8Priority" 는 찾을 수 없을 것이다. 사실 여러분은 그것만으로도 ASCII 나 unicode string 으로 된 "priority" 조차 찾을 수 없을 것이다.
그 밖에 우리는 여전히 그 시스템은 아마도 변수로 존재하는 수로 만들어진 IRQ0Priority, IRQ1Priority 등을 찾는 더 짧은 string 들로 부터 "IRQ8Priority"란 이름을 만들었을 수 도 있다고 생각 할 수 있다.
실제로 우리는 그 string이 더 작은 조각들로 부터 어셈블 되어져 있을 수 있다고 생각 할 수 있다, 그래서 내가 절대적으로 명확하지는 않다고 말하는 이유다.
-- 그러나 나는 이것이 전혀 있을 수 없는 것이라고 생각한다.

몇 가지 또 다른 데이터 포인트:
 
 IRQ의 인터럽트는 NT계열에서 "priority"란 컨셉트 조차 가지고 있지 않다; 그것들과 연관이 있는 "IRQL" (interrupt request level)이라 불리는 것을 가지고는 있다.
그러나 오로지 MP 기기에 이용되는 inter-processor 인터럽트가 할당 되어져 있는 것을 제외하고는 interval timer 인터럽트는 이미 그 어떤 IO 장치들 보다 더 위의 IRQL로 할당 되어져 있다.

 NT 계열의 운영제체는 제일 높은 위치에서 시간을 맞추기 위해 실시간 시계(IRQ8)를 이용하지 조차 않는다! NT 계열의 운영체제들은 작동하는 시스템 시간을 맞추고 CPU time 통계를 내거나 그 밖에 여러 가지에 대해
프로그래밍이 가능한 interval timer(8254, on IRQ0) 를 이용한다.
IRQ8은 프로파일링에 이용 되지만 이 프로파일링은 아주 희귀한 개발 환경을 제외하고는 절대 실행되지 않는다.

동일한 string 출력은 실행에서 찾을 수 없는 레지스트리 핵이나 IoPageLockLimit에 대해 길게 작성된 다른 것들을 보여 줄 것이다.
이것은 적어도 윈도우2000 RTM과 이전 버전의 윈도우에서 이용되어 졌다; 윈도우2000 SP1에서 그것들은 그 메카니즘을 유지했지만 그 제한은 IoPageLockPercentage(윈도우2000 SP2와 이후 출시된 윈도우들 에서는 전체가 제거 되었음)
와 같은 새로운 값에 의해 세밀하게 설계되어 졌었다.

 
나는 IRQ8Priority 레지스트리 변경과 윈도우2000 SP과 이후 버전들에서의 IoPageLockLimit 를 생성한 이후 증가된 퍼포먼스의 모든 결과물들은 잘못된 추론이나 플라시보 효과 때문이라고 결론 지어야만 한다.
IoPageLockLimit 는 적어도 예전에는 작동됐다.(어쨌든, 비록 저런 것들은 실제로 그것의 512k 디폴트값을 이용해 시스템을 종료하도록 했다는 언급을 한 거의 모든 웹사이트에서 제안된 값들 이긴 하지만)

나는 IRQ8Priority 와 같은 것이 어디서 왔는지 모르겠다. 그것은 너무 애매모호해서 날조된으로 여겨진다.(아마 몇 가지 윈도우9X 버전에서는 유효 했을지도?)

참고.

https://home.comcast.net/~SupportCD/XPMyths.html

https://www.wxpnews.com/archives/wxpnews-039-20020820.htm

Jamie Hanrahan는 누구?

Windows Driver Consulting and Training 사의 사장이기도 하면서
윈도우 소스 코드에 접근이 허가된 사람이며 kernel 과 driver 개발 분야에서 유명한 개발자 가운데 한 명.
윈도우 kernel개발.
장치 드라이버 개발.
Windows internals에서 프로페셔널 개발자들을 교육.

https://www.azius.com/instructors.htm

https://www.wd-3.com/archive/registercontext.htm#AboutAuthorhttps://www.usenix.org/events/osdi99/brochure/M2.html

한 마디로 IRQ8Priority 관련 레지스트리 수정으로 성능향상의 효과가 있다는 것은 헛소리에 불과 하답니다.
더 이상 이런 문제로 논란이 생길 이유가 없다고 본답니다.
시간낭비.

제가 번역 하는데는 얼마 안 걸렸지만 이런 글을 올리는 것 조차

사실은 시간 낭비랍니다.