Debunking the "Speed Up your Windows XP Box with IRQ Prioritization" Myth
SOURCE:
http://www.wxpnews.com/archives/wxpnews-039-20020820.htmYikes! We've been caught with our pants down again. It appears that the IRQ Prioritization tweak I shared with your last week was bogus. Who would have guessed? I could have sworn that the system seemed faster, and I do know that the system locked up after making the change. Nevertheless, Jamie Hanrahan of Windows Driver Consulting and Training (
http://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
http://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?"
By telling everyone with an ATI card to run 4X AntiAliasing is asking for trouble. This is going to really drop performance for people running many of the midrange - lowerend Ati cards .
