Figuring out whether or not HT is beneficial or detrimental on a specific workload is difficult today unless you can do an apples-to-apples comparison between an HT machine and a non-HT machine running the exact same workload. On an HT machine, all the processor level resource usage measurements such as % Processor Time represent utilization of a logical processor. Some authorities recommend averaging the processor utilization of the two logical processors that share a physical processor core to calculate utilization of the physical processor. To do this, you must understand which logical processors are associated with the same physical processor core.

Two new Processor configuration records, introduced in Performance Sentry version 2.4.7, allow you to identify HT machines definitively and determine which logical processors share a physical processor core. An instance of a DTS.CPU configuration record that identifies a physical processor is written for each physical processor that is present. These records contain a counter called # Logical Processors Supported that will tell you if it is an HT machine, along with a counter called  # Logical Processors Active that shows you if HT is enabled. If the # Logical Processors Supported counter contains a null value, then the machine is not HT-capable. If the # Logical Processors Supported counter contains valid numeric data, then it is an HT-capable machine. (You should see a numeric value of 2 for current HT-ready processors. Note that Intel’s processor roadmap shows them contemplating building HT machines with more than 2 logical processors sometime in the future.) You can also tell if HT is enabled on the machine. On an HT machine, if the # Logical Processors Active is less than # Logical Processors Supported, then the HT support has been disabled.

The DTS.CPU records contain some additional CPU hardware configuration data that you might find interesting, like the amount of L1, L2 and L3 cache memory is installed, where that information is available.

DTS.LogicalProcessor records are also written that associate a logical processor instance name (the same instance name used in the Processor records) with a DTS.CPU physical processor core parent instance. Both sets of Processor configuration records are automatically written once to the beginning of each NTSMF data file, just before the first interval data records.

The core technology that Intel uses in its HT machines is known as Simultaneous Multithreading (SMT), which you can learn about at this University of Washington, Computer Science department web site. Much of the research published here shows SMT to be quite promising. Multiple threads executing simultaneously on the same processor core works well when an instruction from one thread blocks inside the instruction pipeline, but the processor can continue to make forward progress executing instructions from another thread. On the other hand, in practice HT is sometimes detrimental to overall performance when it comes to real-world workloads, forcing customers to disable HT in some instances. Threads executing concurrently on the same processor core must contend for shared resources inside the processor, particularly the same processor cache. Multiple threads can also interfere with each other’s instruction execution progress, which leads to degraded performance levels. One suggestion is that this interference is more likely to occur when you are attempting to run an homogenous workload and less likely to occur when the processor is executing threads from unrelated processes. In other words, on a machine dedicated to a specific application or one instance of SQL Server, HT could do more harm than good.

According to this white paper posted on Microsoft ’s web site, logical processor instance names on an HT machine are generated in sequence, one to a physical processor until all the physical processors have one logical processor, and then in sequence again until all the HT logical processors have been accounted for. For example, on an HT-enabled machine with 4 processor cores, processor instances 0 and 4 are associated with the first physical processor present, instances 1 and 5 are associated with the next, etc. Since the assignment of logical processor numbers to physical processor cores is a BIOS function, the authors of the Microsoft white paper were not entirely certain that every HT machine you ever come across will look this way, but at least every one that they have seen so far conforms to this numbering scheme.

(1) The primary indicator of processor utilization is the % Processor Time Counter in the Processor Object. Note that the _Total instance of the Processor Object is actually the average value over all processors. The System Object in NT 4.0 contains a Counter named % Total Processor Time, which is also the average value over all processors.

The thread is the unit of execution in Windows. Each process address space that is launched has at least one thread, and many applications, of course, are multithreaded. There is an operating system function in Windows that keeps track of how CPU time each thread consumes using a sampling technique. Samples are normally taken approximately one or two hundred times per second, which suggests that this technique is probably accurate for measurement intervals of 30 seconds or more. These samples are used to maintain the Thread % Processor Time Counter, once execution time recorded in 100 nanosecond timer tick units, is normalized to a percentage of the measurement interval duration. Thread % Processor Time is also summarized at the Process level. The table below summarizes this overall measurement scheme:

Processor busy is measured using an Idle thread mechanism. The operating system dispatches an Idle thread whenever there are no ready threads to run. Whenever the processor accounting routine finds the Idle thread dispatched, processor time is accumulated for the Idle thread. By the way, the Idle thread is not an actual execution thread, it is a HAL function which fulfills this essentially bookkeeping function.

At the end of a measurement interval, % Processor Time is calculated by subtracting the amount of accumulated Idle thread time from 100%. On a multiprocessor, there is a dedicated Idle thread per processor so that reliable measurements are kept. % Processor Time at the processor level can be broken down into Privileged mode execution time, User mode execution time, execution time in Interrupt mode, and execution time in Deferred Procedure Calls (DPC), as illustrated in Figure 1 below. % Interrupt Time and % DPC Time are both subsets of % Privileged Time. Figure 1. Processor utilization breakdown.

% Processor Time approaches 100% as an absolute upper limit on CPU capacity. A system that is running consistently at greater than 90% busy is clearly out of capacity. However, this is a not a hard and fast rule. Some workloads show signs of significant CPU contention at lower levels of processor utilization. For example, Figure 1 shows an IIS web server at a large e-commerce site where processor utilization remains consistently below 85%, except for two peak processing intervals. However, we will see that this system suffers from a serious CPU capacity constraint. So start with % Processor Time, but do not stop there.

(2) The System Object contains an instantaneous Counter called Processor Queue Length. This Counter shows the number of threads that are currently in the Ready state, but are delayed waiting for a processor to be available. Maintaining a value of no more than five Ready threads per processor is the usual recommendation. More than ten Ready threads per processor normally indicates a CPU resource shortage.

The Processor Queue Length Counter is often well-correlated with % Processor Time, even though the former is an instantaneous value obtained at the time the last processor sample was collected, while the latter is based on continuous samples during the measurement interval. Figure 2 shows the overall processor utilization from the 4-way multiprocessor system in Figure 1 with an overlay of the Processor Queue Length for the same interval (charted against the right hand y-axis). The expected correlation between processor utilization and the number of Ready and Waiting threads is apparent.

Figure 2. % Processor time vs. the Processor Queue Length.

In this instance, we also saw a correlation between periods of poor Active Server Pages (ASP) response time and corresponding spikes in the size of the Processor Ready Queue. In this specific instance, % Processor Time values consistently greater than 70% appeared to cause spikes in web site response time.

(3) At the Thread level, there is a Counter called Thread State. Threads waiting in the Ready Queue have a Thread State code of 1 (see the Explain text for the Counter). This Counter tells you precisely which threads are waiting for service at the processor. Since Windows uses priority queuing to order the Ready Queue, knowing which threads are delayed in the queue can be quite useful to help pinpoint the impact of CPU contention on specific applications that might be experiencing performance problems.

Because of the quantity of threads on a typical NT machine, collecting thread execution state data using tools like System Monitor is normally prohibitive. Consequently, we designed Performance Sentry to allow efficient collection of this potentially useful information. The Ready Threads Counter that Performance Sentry provides at the process level shows the number of Ready and Waiting threads for that process at the end of each measurement interval.