Multi-tasking Operating Systems just give the illusion that they\u2019re doing things in parallel. In reality, the CPUs rapidly skip from task to task using various algorithms and heuristics, making one think the processes truly are running simultaneously. The choice of scheduling algorithm can be immensely important.<\/p>\n
In a nutshell the processors are allowed to spend finite chunks of time per process. This “time” is referred to as quanta. The quantum is simply the amount of time the CPU will spend on the task. Every time the CPU switches to a new process, there is what\u2019s called a context switch<\/em>. Context Switches\u00a0are computationally expensive,\u00a0\u00a0and we all know how bad excessive context swtiching is in any environment, more so in a Terminal Services environment. So obviously we need to avoid excessive context switching but still maintain the illusion of concurrency.<\/p>\n Thomas Koetzing wrote a great article on Understanding and Troubleshooting context switches<\/a>.<\/p>\n There is some excellent information on how Windows manages Processes and Threads in the updated Windows Internals, Fifth Edition<\/em> book by Mark E. Russinovich and David A. Solomon with Alex Ionescu. You can still download chapter 6\u00a0from the Fourth Edition titled “Processes, Threads, and Jobs<\/a>“. It’s a great read!<\/p>\n Changing the processor scheduling option modifies the Win32PrioritySeparation value under the HKEY_LOCAL_MACHINE\\System\\CurrentControlSet\\Control\\PriorityControl key, which consists of 6 bits (AABBCC)…<\/p>\n When you set the performance option for processor scheduling\u00a0in the GUI, you only see two possible choices for the duration of the timeslice quantum: Neither of these settings are optimal for a Terminal Server, although the Programs<\/em> option is the better of the two simply because shorter timeslices are mandatory for a Terminal Server environment.<\/p>\n If using CPU Utilization Management Feature that was introduced with Citrix Presentation Server 4.0 Enterprise Edition and above, the 3 x\u00a0boost for the default Programs<\/em> value makes this feature somewhat less effective. In these circumstances the variable timeslice length is often better fixed. Under these conditions it is suggested that the optimum value\u00a0may indeed be\u00a040 decimal, 101000 binary. That gives us small, fixed length timeslices, allowing the CPU Utilization Management Feature to efficiently do its job by\u00a0giving each user a fair share of the CPU by modifying the normal job priority scheduling in the operating system.<\/p>\n\n
\n01 – longer timeslice interval
\n10 – shorter intervals<\/li>\n
\n01 – timeslice can have variable length
\n10 – timeslice has fixed length<\/li>\n
\n00 – foreground\/background processes have same priority
\n01 – foreground process gets 2 x boost compared to background process\u00a0
\n10 – foreground process gets 3 x boost compared to background process<\/li>\n<\/ul>\n
\n1) Programs<\/em>: value is 38 decimal, binary is 100110 = shorter intervals, variable timeslice length, 3 x boost
\n2) Background Services<\/em>: value is 24 decimal, binary is 011000 = longer timeslice interval, timeslice fixed length, no boost<\/p>\n