• Due to design limitations and lazy programming techniques, many applications often exhibit adverse behavioral trends; they monopolize the server’s processors and deny other running applications their rightful share of CPU cycles. Such applications are often referred to as “rogue” or “runaway” applications.
• By definition, a rogue or runaway application is one whose thread(s) use up excessive amounts of CPU resources. In other words, they consistently remain in the RUNNING state for the entire lifetime of their allotted time slices. A time slice is often referred as “quantum”, and its value is typically 10 to 15 milliseconds (hardware-dependent) under Windows 2000/2003.
• The Windows scheduler does not include a fair-sharing mechanism; hence, it does not prevent rogue applications from consuming all the CPU time.
• “Priority boosting” performed by Windows’ built-in balance set manager does not effectively address CPU starvation caused by runaway applications, especially in Terminal Server environments.
• From a CPU management perspective, the thread priorities of interest are WAITING, READY, and RUNNING. In the case of a word processor, the latter could be waiting for user input. As soon as it receives input, it is ready to run. And as soon as the processor becomes free, it will run
• Given two threads in the READY state, the scheduler will ALWAYS favor the process with the higher priority level over the other.

Consider the case of two running (single-threaded) applications, a well-behaved word processor (figure 3) and a runaway CPU spinner (figure 4). Assuming a quantum length of 10 milliseconds, each thread is eligible to use the CPU for up to 10 ms at a time (the time slice). A thread could potentially use up its entire time slice if it has enough work to do to fill up the time slice. Being a runaway application, the CPU spinner will steadily use the CPU for the duration of its time slice. Being a well-behaved application, the word processor will almost never use up its time slice. Instead, its CPU requirements are conservative as it will only consume a small to moderate portion of its time slice (if any). Occasionally, it may not even have anything to do (e.g., waiting on user input) and will remain in the WAITING state until something happens (e.g., user input is received).

Figure 3 – A well-behaved application

Figure 4 – An ill-behaved (aka. runaway or rogue) application

Max-IT (CPU) ensures that each running process will get its fair share of CPU resources, enabling it to run smoothly and co-exist alongside CPU-hungry and rogue applications. At the most basic level, Max-IT (CPU) achieves fair-sharing across all running processes as follows:

• A fixed share of CPU resources is reserved to NT Authority (the operating system). By default, this share is 20 percent.
• The “target percent CPU time” is then computed as (100 - Reserved) / (number of active processes), where Reserved is the percent CPU share reserved for NT Authority.
• The “average percent CPU time” is calculated for each active process.
• Processes whose “average percent CPU time” has fallen below the “target percent CPU time” will get their priority levels set to NORMAL.
• Processes whose “average percent CPU time” has risen above the “target percent CPU time” will get their priority levels set to BELOW NORMAL.
• Processes whose “average percent CPU time” has fallen to zero get their priority levels set to ABOVE NORMAL.
• The above process is then repeated every several hundred milliseconds. The default setting is 100 milliseconds.

Max-IT (CPU) also makes use of proprietary and sophisticated techniques above and beyond what is described above. These techniques further improve the application response times and enhance the end-user’s experience.