Unleash The Beast!
Turn this script loose and see how easy it is to maximize processor performance across multiple workstations!
- By Chris Brooke
- April 01, 2002
I just got a new laptop at work. My "old" onea Pentium II 300 MHzwas
considered a "Desktop Replacement" notebook when I got it three years
ago. If that's true, then this one must be considered a "Crazy Supercomputer
Replacement"a Pentium III 1.13 GHz, with 512MB RAM, built-in wireless,
LAN and modem. As Tim "The Tool Man" Taylor would say, "Arr, Arr, ARR!!"
I was in heaven!
Until the newness wore off, which took about 15 minutes.
Then I was back to tapping my fingers on my desk waiting for applications
to start. Yes, it's true: Computers will simply never be fast enough
to satisfy us. All isn't lost, though. There are things we can do to maximize
their performance. The featured script this month is one I wrote back
in my NT 4.0 days to configure processor performance on servers. Over
the years, it's evolved to be the first script I run on a new workstation
(or one that I've just rebuilt). Let's take a look at it first, then I'll
explain what it does and why it's so useful.
<?xml version="1.0" ?>
This script updates the Win32PrioritySeparation
key in the registry to boost the performance
of applications running in the foreground
allows you to change the performance role of your computer
role (server or workstation) for the computer"
strRole, strKey, strDataType
strKey, 38, strDataType
"Priority Control has been set to optimize foreground applications."
strKey, 24, strDataType
"Priority Control has been set to optimize background services."
What this script does is simple enough: It changes the registry setting
"Win32PrioritySeparation." This setting controls the priority of foreground
processessort of. What it actually does is determine how much processor
time the threads of a process receive and the relative priority of foreground
and background processes. Of course, there's a GUI tool for this that
I'm sure you've used many times: the System Applet. Priority control is
set by selecting the Advanced tab and clicking the Settings button under
Performance. This opens the Performance Options window. Select the Advanced
tab and make your selection under Processor Scheduling (see Figure 1).
|Figure 1. This machine is set to boost foreground
applicationsor is it?
You have two choices: Adjust for Programs or Adjust for Background Services.
Pretty straightforward, yes? So why bother with a script? Well, the script
allows you to automate these Workstation or Server "role" settings. You
specify the role using the command-line argument /Role:
. A "W" ("W"orkstations) changes the value to "boost" foreground processes.
"S" ("S"erver) changes the setting for background processes.
Depending upon a computer's usage in your organization, you may want to
modify how it handles processes rather than simply rely on the default
settings. For instance, if you work for a small company and use IIS on
Windows 2000/XP Professional to run your intranet, you'd certainly want
to maximize background processes on this machine. This script should be
on your checklist to be applied every time you change the primary function
of a computer.
But Wait, There's More
Using a script to directly edit these values provides even more benefit
than simply specifying one of two possible computer roles. A lot
more! Let's explore this by looking at what these settings meant back
in the "old days" of NT 4.0. If you use the System Applet to look at these
same settings on a Windows NT 4.0 computer, you'll notice a slider instead
of the two radio buttons. There are three choices on the "Select Performance
Boost for Foreground Applications" slider: None, "Balanced", and Maximum.
The corresponding registry setting would be either 0 (None), 1 (Balanced),
or 2 (Maximum). In Windows 2000, the usage of this key has changed. In
NT 4.0, this key merely affected thread priority. In Windows 2000 (and
XP/2002 Server, as well), it allows you to control not only relative priority
for processes, but also the length of the intervals (i.e. how long each
process runs once it is scheduled), and whether or not these intervals
are fixed-length or variable-length. This is possible because with Win2K,
this registry setting, rather than being a "real" value of 0, 1, or 2,
is now a 6-bit bitmask valuecomprised as three 2-bit pairswith
each pair specifying a particular element of thread priority control.
Now, here's the good part: Microsoft managed to preserve the NT 4.0
settings, so that they would have the same effect if applied to the bitmask
of a Win2000/XP machine. In fact, the "old" values are still the default
settings for this key! See for yourself and open the System Applet.
If you have Win2000/XP Professional installed, it should already be set
to Adjust for Programs. Now open the registry and browse to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\PriorityControl.
(This is where we include the "standard" disclaimer that directly editing
the registryor even looking at it with Regedit.exemay permanently
damage your computer. Other side-effects include male pattern baldness,
dry mouth, itchy scalp, recurring migraine headaches, and/or death.) Unless
you've changed this previously, the value for Win32PrioritySeparation
will be 2 (the old NT 4.0 setting). Now, switch back to the "Performance
Options" window, tick the "Adjust for Background Services" option and
click Apply. Switch back to the registry editor and hit F5 to refresh
it. Now it's 24. This value of 24 has the same effect on processor scheduling
as the NT 4.0 value of 0. Now use the GUI to switch it back to "Adjust
for Programs" and click Apply. Back to regedit, F5 to refresh, and...tada! It's 38, which has the same effect as the NT 4.0 value of 2.
The Win32PrioritySeparation value for Windows 2000/XP
takes on a whole new dynamic from its previous incarnation
in Windows NT 4.0 and earlier. As mentioned in the column,
the new setting gives you control over not only process
priority, but also the amount of processor time allocated
to the threads of a process and whether or not the length
of time is fixed or variable.
A Review of Binary Math
We've dealt with bitmasks before (see "A Bit About Binary
Math" in my December 2000 column); please feel free
to refer back to it if you need a little refresher.
Go ahead… I'll wait. OK, you're back! Now that you've
been reminded that it's not the number, but the bits
that are important, let's move on to how we use this
bitmask for priority control.
So… How's This Work?
The bitmask is divided into three, two-bit pairs (AABBCC).
Each bit-pair corresponds to certain behavior. I've
broken it down below:
The highest bits (AABBCC)
specify whether the processor interval (the amount of
time allocated to the threads of a process) is relatively
short or long. The "middle" bits (AABBCC)
specify whether the interval is fixed or variable. The
lowest bits (AABBCC) determine
the ratio of foreground threads to background threads.
Certain values cause different behavior, depending on
whether you are using Professional or Server. Here's
a table that breaks down each bit-pair.
|00 or 11
(Windows 2000/XP Professional); Longer Intervals
(Windows 2000/2002 Server)
||Fixed or variable
|00 or 11
(Pro); Fixed length (Server)
||Ratio of foreground
to background threads
||Equal and fixed.
This value also overrides the Fixed/Variable
value to Fixed.
processes receive twice the processor time
of background processes.
|10 or 11
processes receive three times the processor
time of background processes.
Now let's apply the "standard" and "default" values
of the System Applet and see what this translates to.
- Adjust for ProgramsThe default value
is 2 (000010 binary). The "standard" value (set when
changed using the System Applet) is 38 (100110 binary).
Notice that with Win2000 Pro, these values have the
same effect - shorter intervals, variable length,
- Adjust for Background ServicesThe
default value is 0. The "standard" value is 24 (011000
binary) Notice that regardless of whether you are
running Server or Professional, the values have the
same effect - longer intervals, fixed length, equal
Putting it into Action
Remember that default thread settings are designed to
be generic and may not be optimal for your system depending
upon the services and applications you are running.
By combining different bit-pair values, you can tweak
thread processing significantly, rather than simply
"living with" the default behavior. I encourage you
to experiment with different settings to find what works
best on your system.
Changing Workstation Roles, and Then Some
While this script is valuable as a means of changing how a particular
machine handles foreground and background processes, its real value lies
in its ability to perform low-level tweaking of thread performance, which
I explain in "Advanced Priority Control" above.