Chapter 11 - Performance Monitoring Tools

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

A collection of general purpose monitoring tools is available to augment and complement Performance Monitor. This chapter describes them.

Tool	Location
Task Manager	Integrated into Windows NT 4.0 Workstation and Server.
Performance Data Log Service (PerfLog)	Resource Kit \PerfTool\MeasTool
Pentium Counters	Resource Kit \PerfTool\P5Ctrs
Process Monitor (PMON)	Resource Kit \PerfTool\MeasTool and \Computer Diagnostics
Process Explode (PView)	Resource Kit \PerfTool\MeasTool and \Computer Diagnostics
Process Viewer (PViewer)	Resource Kit \PerfTool\MeasTool and Computer Diagnostics
The SC Utility	Resource Kit \Computer Configuration
Data Logging Service	Resource Kit \PerfTool\MeasTool\ Datalog.exe and Monitor.exe
Microsoft Test	Microsoft product purchased separately
Response Probe	Resource Kit \PerfTool\Probe

This is not intended to be a complete list of performance monitoring tools. For more information about the tools on the Windows NT Resource Kit 4.0 CD, see the Alphabetical List of Tools in Rktools.hlp.

In addition to the general purpose tools described in this section, more specific tools are discussed throughout the book. They are listed here for reference only.

Tool	Description	Location	Chapter reference
Start	Starts a process and lets you set its properties, including priority, and whether it runs in a separate or shared memory space.	Included in Windows NT	Ch. 9, "The Art of Performance Monitoring" Running 16-bit Windows Applications in a Separate Process. Ch. 13, "Detecting Processor Bottlenecks" Measuring and Tuning Priority
Extensible Counter List	Lists installed Performance Monitor counters that did not come with Windows NT.	Resource Kit \PerfTool\CntrTool \Exctrlst.exe	Ch. 10, "About Performance Monitor" Performance Monitor Troubleshooting Features
CreateFile	Creates a zero-filled file of a size you specify	Resource Kit \PerfTool\Probe \Creatfil.exe	Ch. 11, "Performance Monitoring Tools" Creating Simulated Files
Clearmem	Allocates all available memory, then releases it.	Resource Kit \PerfTool\MeasTool \Clearmem.exe	Ch. 12, "Detecting Memory Bottlenecks" Determining the Minimum Working Set
Page Fault Monitor (PFMON)	Produces a detailed report on all hard and soft page faults for a process	Resource Kit \PerfTool\MeasTool \Pfmon.exe	Ch. 12, "Detecting Memory Bottlenecks" Examining Your Applications
Working Set Tuner	Analyzes the patterns of function calls in your application code and recommends an organization that consumes the least possible physical memory.	Win32 Software Development Kit	Ch. 12, "Detecting Memory Bottlenecks" Examining Your Applications
LeakyApp	Allocates all available memory to its process and retains it until it is stopped.	Resource Kit \PerfTool\MeasTool \leakyapp.exe	Ch. 12, "Detecting Memory Bottlenecks" Examining Your Applications
CPU Stress	Creates a single-threaded or multithreaded process using processor time. Users choose the number of threads and set the priorities of the process and its threads, the threads' activity level.	Resource Kit \Perftool\Meastool \CpuStres.exe	Ch. 13, "Detecting Processor Bottlenecks"

TotlProc

Installs a counter for measuring processor time on applications launched by the system interrupt.

Resource Kit \PerfTool\TotlProc \TotlProc.exe

Ch. 13, "Detecting Processor Bottlenecks" Processor Sampling

Performance Meter

Lists current statistics on the file system cache.

Resource Kit \PerfTool\MeasTool \Perfmtr.exe

Ch. 15, Detecting Cache Bottlenecks"

Note The tools on the Windows NT Resource Kit 4.0 CD are not supported. Whenever possible, use Performance Monitor and Task Manager, supported tools integrated into Windows NT.

Some tools are included in more than one category, so some duplication might occur. You can delete the duplicates.

Several of these tools are included on the Windows NT Resource Kit 4.0 CD. To install them, use the Setup program on the CD. To install all tools, use the Typical Installation mode in Setup. Use Custom Installation to install just one category of tools. Some Custom Installation categories, including Performance Tools, let you install the tools selectively. In Setup, click Performance Tools, then click Change Option to select a tool from the group.

The following figure shows the Custom/Complete dialog box of the Setup program configured so that only the performance tools are installed.

Task Manager

Task Manager is a new tool introduced with Windows NT 4.0 Server and Workstation. It lets you monitor active applications and processes on your computer, and start and stop them. Best of all, it has basic performance-monitoring capabilities and a friendly interface:

• It displays running applications and processes, including 16-bit processes.

• It displays the most commonly used performance measures for processes, including processor time, main memory size, virtual memory size, page faults, base priority and number of threads.

• It displays line graphs and instantaneous values of processor and memory use for the computer.

• It lets you set processor affinity for a process, change the base priority class of a process and activate a debugger, if you have one.

Task Manager gets its data from the same functions used by Performance Monitor. However, it calls these functions directly, bypassing the Performance Library and the registry. Thus, it cannot log data to a file and it cannot monitor remote computers. However, it is a useful tool for quick checks of basic counters and for training users to monitor their own computer.

Starting and Setting Up Task Manager

Task Manager is integrated into Windows NT 4.0 Workstation and Server and does not need to be installed separately. This section explains how to use Task Manager as a performance monitoring tool. For more general information, see Task Manager Help.

To start Task Manager, use any of these methods:

• Press ctrl+shift+esc.

• Use the right mouse button to click the Task Bar, then click Task Manager.

• Press ctrl+alt+delete, then click Task Manager.

You can also start Task Manager from the command prompt or the Run command, and you can create a shortcut to Taskmgr.exe.

Task Manager has three tabs, but the status bar always displays the total number of processes, CPU use, and virtual memory use for the system. Note the following display possibilities:

• All Task Manager columns can be resized.

• Clicking a column sorts its entries in ascending or descending order.

• Double-clicking the window frame toggles the menu bar, tabs, and status bar on and off for a compact footprint. You can then resize the window as desired.

• Select Always on Top from the Options menu to keep the window in view as you switch between applications.

• Press ctrl+tab to toggle between tabs.

 

 

When Task Manager is running, an accurate miniature CPU usage gauge appears on the taskbar on the end opposite the Start button. When you touch it with the cursor, it displays the percentage of processor use in text format. The miniature gauge always matches the CPU Usage History chart on the Performance tab.

To make Task Manager the top window, double-click the gauge, or click the gauge with the right mouse button and select Task Manager from the menu that appears.

If you run Task Manager frequently and don't want to see its icon on your taskbar, click Hide When Minimized from the Options menu. To open a hidden Task Manager, click the Task Manager CPU gauge on the taskbar.

Monitoring Processes

Click the Task Manager Processes tab to see a list of running processes and measures of their performance. The Task Manager process table includes all processes that run in their own address space, including all applications and system services. From the Options menu, click Show 16-bit Tasks to include those in the display.

For a description of the most common system services that appear in the list, see "System Processes," in Chapter 9, "The Art of Performance Monitoring."

Note Task Manager displays its values in kilobytes, which are units of 1024 bytes. When comparing Performance Monitor and Task Manager values, multiply Task Manager values by 1024. For example, 108K bytes of memory usage for Explorer.exe, shown below, equals 110,592 bytes in Performance Monitor.

From the View menu, click Select Columns to add to or remove performance measures from the display. The following table briefly describes the measures and their Performance Monitor counterparts, if any.

Process Measure	Description	Performance Monitor Process counter
Image Name	Name of the process.	The process name in the Instances box.
PID (Process Identifier)	Numerical ID assigned to the process while it runs.	ID Process.
CPU Usage	The percentage of time the threads of the process used the processor since the last update.	%Processor Time.
CPU Time	The total processor time used by the process since it was started, in seconds.	None.
Memory Usage	The amount of main memory used by the process, in kilobytes.	Working Set.
Memory Usage Delta	The change in memory use since the last update, in kilobytes. Unlike Performance Monitor, Task Manager displays negative values.	None.

Page Faults

The number of times data had to be retrieved from disk for this process because it was not found in memory. This value is accumulated from the time the process is started.

None. Page faults/sec is the rate of page faults over time.

Page Faults Delta	The change in the number of page faults since the last update.	None.
Virtual Memory Size	Size of the process's share of the paging file, in kilobytes.	Page File Bytes.
Paged Pool	Amount of the paged pool (user memory) used by the process, in kilobytes. The paged pool is virtual memory available to be paged to disk. It includes all of user memory and a portion of system memory.	Pool Paged Bytes. (See note below.)
Nonpaged Pool	Amount of the nonpaged pool (system memory) used by the process, in kilobytes. The nonpaged pool is operating system memory which is never paged to disk.	Pool Nonpaged Bytes. (See note below.)
Base Priority	The base priority of the process, which determines the order in which its threads are scheduled for the processor. The base priority is set by the process code, not the operating system. The operating system sets and changes the dynamic priorities of threads in the process within the range of the base. Use Task Manager to change the base priority of processes. See the next section for details.	Priority Base.
Handle Count	The number of object handles in the process's object table.	Handle Count.
Thread Count	The number of threads running in the process.	Thread Count.

Important The size of the paged and nonpaged memory pools, as shown on the Process tab, are not precise. These values are taken from internal counters which count duplicated object handles as well as space for the object. Also, they are rounded to page size, so if a process is using part of a page, its pool space is overestimated. However, they can be used to monitor changes in the size of the pool for a process.

The paged and nonpaged pool size for the whole system, shown on the Performance tab, are precise. Thus, the sum of values for each process might not match the count for the whole system.

Task Manager, Performance Monitor, Process Explode (Pview.exe), Process Monitor (Pmon.exe) and Process Viewer (Pviewer.exe) all use the same internal counters for monitoring the paged and nonpaged memory pools.

Changing the Base Priority Class

The base priority class of a process determines the range of dynamic or current priorities that the operating system can assign to the threads of that process. The base priority is usually set in the application code. You can use Task Manager to change the base priority class of a process. However, this change lasts only as long as the process runs. When the process is started again, it reverts to the original base priority class.

In a preemptible, multitasking operating system like Windows NT, the microkernel schedules threads for the processor in order of their priority and interrupts running threads if a higher priority thread appears.

You might want to increase the priority of a process, or decrease the priority of competing processes to improve their response.

Warning Changing the base priority class of a process to Real-Time can destabilize your system. A busy, Real-Time process can prevent other processes and system services from running.

To change the base priority class of a process, select the process name from the Task Manager Processes tab, click the highlighted name with the right mouse button, click Set Priority, and then select a new priority class from the Set Priority submenu.

Selecting a Processor

You can use Task Manager to limit the execution of a process to one or more processors.

Note The Set Affinity option used for selecting a processor appears only on computers with more than one processor.

On multiprocessor computers, the Windows NT microkernel distributes thread-processing requests over all processors based on thread priority. Often, the threads of a single process are running on more than one processor. Windows NT uses soft affinity to distribute processor load. This means that when all other factors are equal, Windows NT reassigns threads to the same processor they ran on before. This takes best advantage of the processor cache. However, you can override this configuration and determine on which processors your processes run.

You might want to expedite a process by reserving a processor for it and rerouting all other processes to other processors.

To select processors for a process, click the process name in the Task Manager Processes tab, click the highlighted name with the right mouse button, click Set Affinity, and the select one or more processors from the list.

 

Starting your Debugger

If you have installed a debugger, you can activate the debugger on a process by using Task Manager. Click the process name in the Task Manager Processes tab. Then click the highlighted name with the right mouse button and click Debug.

Update Speed

You can control the rate at which Task Manager updates its counts. This will reduce Task Manager overhead, but might miss some data. You can force an update at any time by clicking Refresh Now on the View menu or by pressing F5.

Task Manager Update Speed options are:

High	Updates every half-second.
Normal	Updates once per second.
Low	Updates every four seconds.
Paused	Does not update automatically. Press F5 to update.

Monitoring the System

Click the Task Manager Performance Tab to see an dynamic overview of system performance, including a graph and numeric display of processor and memory usage.

To graph the percentage of processor time in privileged or kernel mode, click Show Kernel Times on the View menu. This is a measure of the time applications are using operating system services. The remaining time, known as user mode, is spent running threads within the application code.

Users of multiple processor computers can click CPU History from the View menu and choose to graph the non-idle time of each processor in a single graph or in separate graphs.

The following table briefly describes the counts on the Performance tab and their Performance Monitor counterparts, if any.

Task Manager Counts	Description	Performance Monitor counters
CPU Usage	The percentage of time the processor is running a thread other than the Idle thread.	Processor: % Processor Time and System: % Total Processor Time
MEM Usage	The amount of virtual memory used, in kilobytes.	Memory: Committed bytes
Total Handles	The number of object handles in the tables of all processes.	Process: Handle Count: _Total
Total Threads	The number of running threads, including one Idle thread per processor.	Process: Thread Count: _Total
Total Processes	The number of active processes, including the Idle process.	Object: Processes is the same, but excludes the Idle process
Physical Memory: Total	Amount of physical, random access memory installed in the computer, in kilobytes.	None
Physical Memory: Available	Amount of physical memory available to processes, in kilobytes. It includes zeroed, free, and standby memory.	Memory: Available Bytes
Physical Memory: File Cache	Amount of physical memory released to the file cache on demand, in kilobytes.	Memory: Cache Bytes
Commit Charge: Total	Size of virtual memory in use by all processes, in kilobytes.	Memory: Committed Bytes
Commit Charge: Limit	Amount of virtual memory, in kilobytes, that can be committed to all processes without enlarging the paging file.	Memory: Commit Limit
Commit Charge: Peak	The maximum amount of virtual memory used in the session, in kilobytes. The commit peak can exceed the commit limit if virtual memory is expanded.	None

Kernel Memory: Total	Sum of paged and non-paged kernel memory, in kilobytes. Kernel refers to memory available to operating system components running in highly privileged kernel mode.	None (Sum of Pool Paged Bytes and Pool Nonpaged Bytes)
Kernel Memory: Paged	Size of the paged pool allocated to the operating system, in kilobytes. The paged pool is an area of operating system memory that can be paged to disk as applications demand more memory.	Memory: Pool Paged Bytes
Kernel Memory: Nonpaged	Size of the nonpaged pool allocated to the operating system, in kilobytes. The nonpaged pool is the part of operating system memory that remains in physical memory as long as it is allocated.	Memory: Pool Nonpaged Bytes

Performance Data Log Service

Performance Data Log Service (PerfLog) is an new tool that logs data from performance counters to a tab-separated or comma-separated variable file. It lets you choose which performance counters you want to log, and it will start new log files automatically at intervals you select.

PerfLog is included on the Windows NT Resource Kit 4.0 CD in the Performance Tools group (\PerfTool\MeasTool\Perflog.exe).

PerfLog logs performance data to a comma-separated or tab-separated text file for later use as input to spreadsheets, databases, and other applications, as well as to Performance Monitor. Unlike Performance Monitor logs, which store data in a compact, multi-dimensional C-language data format, PerfLog logs can be used as direct input without reformatting.

PerfLog uses the same objects and counters as Performance Monitor, but it lets you select which counters you want to log for each instance of an object. You can also select the level of detail you need on an instance and let PerfLog select a set of counters for you.

For more information on PerfLog, see Rktools.hlp.

Pentium Counters

Intel Pentium and Pentium Pro processors have special counters that monitor the inner workings of the chip. You can see a graph of these counters by using Pperf, a tool on the Windows NT Resource Kit 4.0 CD. Better yet, you can set up the counters by using Pperf, and then use Performance Monitor to chart, log, report, or set alerts on them.

Tip The Pentium counters are extensible counters for Windows NT. You can confirm that the installation of these counters was successful and find useful information about them by using Extensible Counter List, a tool on the Windows NT 4.0 Workstation Resource Kit CD. Extensible Counter List is in the Performance Tools group in \PerfTool\Cntrtool\Exctrlst.exe. For more information, see Rktools.hlp.

To use the counters

1. Install the P5Ctrs directory from the Windows NT Resource Kit 4.0 CD. It is in the Performance Tools group in \PerfTool\P5Ctrs. 

2. Complete the installation of Pperf by loading new registry values, copying some files to different directories, and installing counter names and explain text for the Pentium counters in Performance Monitor. For instructions, see P5perf.txt, in the P5Ctrs subdirectory. 

3. Use Pperf to activate the Pentium counters by selecting them and assigning them to registers You activate two at a time. For instructions, see P5perf.txt, in the P5Ctrs subdirectory. 

    

4. In Performance Monitor, select the Pentium object, then select one or both of the counters you activated with Pperf.

   Note The Pentium object and the names of all Pentium counters appear in Performance Monitor when you complete the installation of Pperf. However, only the counters you activate by using Pperf will display valid values in Performance Monitor.

And, as you can with any Windows NT 4.0 application, you can create a shortcut to Pperf on your desktop.

Simple and Composite Counters

There are two types of Pentium counters: simple and composite. Simple counters require that one Pperf counter be activated for each Performance Monitor. Composite counters require that two Pperf counters be activated for each Performance Monitor counter.

For example, to use the simple counter, FLOPs/sec, in Performance Monitor, FLOPs must be activated in Pperf. However, to use the composite counter % Data Cache Misses in Performance Monitor, both Data R/W and Data R/W Miss must be activated in Pperf.

Counter Table

The following table associates the Pentium counters with the Pperf counters that activate them:. Descriptions of the counters appear in the Explain text in Performance Monitor.

Pentium Counter (as seen in Performance Monitor)	Required Pperf Counters
% Branch Target Buffer Hit	Branches and BTB hits
% Branches	Instructions executed and Branches
% Code Cache Misses	Code Read and Code cache miss
% Code TLB Misses	Code Read and Code TLB miss
% Data Cache Misses	Data R/W and Data R/W miss
% Data Cache Read Misses	Data Read and Data Read miss
% Data Cache Write Misses	Data Write and Data Write miss
% Data Snoop Hits	Data cache snoops and Data cache snoop hits
% Data TLB Misses	Data R/W and Data TLB miss
% Segment Cache Hits	Segment cache accesses and Segment cache hits
% V-Pipe Instructions	Instructions executed and Instructions executed in vpipe
Bank Conflicts/sec	Bank conflicts
Branches Taken or BTB Hits/sec	Taken branch or BTB hits
Branches/sec	Branches
BTB Hits/sec	BTB hits
Bus Utilization (clks)/sec	Bus utilization (clks)
Code Cache Miss/sec	Code cache miss
Code Read/sec	Code Read
Code TLB Miss/sec	Code TLB miss
Data Cache Line WB/sec	Data Cache line WB
Data Cache Snoop Hits/sec	Data Cache snoop hits
Data Cache Snoops/sec	Data Cache snoops
Data R/W Miss/sec	Data R/W miss
Data Read Miss/sec	Data Read miss
Data Read/sec	Data Read
Data Reads & Writes/sec	Data R/W
Data TLB Miss/sec	Data TLB miss
Data Write Miss/sec	Data Write miss
Data Write/sec	Data Write
Debug Register 0	Debug Register 0
Debug Register 1	Debug Register 1
Debug Register 2	Debug Register 2
Debug Register 3	Debug Register 3
FLOPs/sec	FLOPs
I/O R/W Cycle/sec	IO r/w cycle
Instructions Executed In vPipe/sec	Instructions executed in vpipe
Instructions Executed/sec	Instructions executed
Interrupts/sec	Interrupts
Locked Bus Cycle/sec	Locked bus cycle
Memory Accesses In Pipes/sec	Memory Accesses in pipes
Misaligned Data Refs/sec	Misaligned data refs
Non_Cached Memory Ref/sec	Non_cached memory ref
Pipe Stalled On Addr Gen (clks)/sec	Pipe stalled on addr gen (clks)
Pipe Stalled On Read (clks)/sec	Pipe stalled on read (clks)
Pipe Stalled On Writes (clks)/sec	Pipe stalled on writes (clks)
Pipeline Flushes/sec	Pipeline flushes
Segment Cache Accesses/sec	Segment cache accesses
Segment Cache Hits/sec	Segment cache hits
Segment Loads/sec	Segment loads
Stalled While EWBE#/sec	Stalled while EWBE#
Write Hit To M/E Line/sec	Write hit to M/E line

Process Monitor

Process Monitor (Pmon.exe) is a utility on the Windows NT Resource Kit 4.0 CD in \PerfTool\MeasTool and \Computer Diagnostics. It displays process statistics in text format in a command prompt window. The data is updated automatically every five seconds. Process Monitor requires no setup.

To start Process Monitor, at the command prompt, type pmon. To stop it, press Esc.

 

Process Explode

Process Explode (Pview.exe) is a utility on the Windows NT Resource Kit 4.0 CD in \PerfTool\MeasTool and \Computer Diagnostics. It provides a wealth of accurate and detailed information on many aspects of the system, processes, threads, and memory.

Much, but not all, of the information in Process Explode is also available in Performance Monitor, but Process Explode requires no setup. All of the information is provided in a single dialog box—a convenience once you are familiar with it and a mind-boggler until you are.

With Process Explode you can:

• See current counts of system objects.

• Change the base priority class of a process and see, but not change, the dynamic priority of its threads.

• Examine details of the process address space, with counters at the level of operating system kernel-mode DLLs.

• Examine detailed physical and virtual memory counts.

• Examine and change process, thread, and token permissions and some attributes of the security context in which a process runs.

• Stop running processes.

The Times box, at the top of the second column, shows the total elapsed time of the selected process since its start (E), as well as time elapsed in kernel mode (K) and user mode (U) processing. Thread times appear in a separate box halfway down the first column.

Process Explode is not updated automatically. Use the Refresh button in the lower right corner to update the data. The time of the last refresh is displayed in the upper right corner.

Note The Hide button, next to Refresh, makes the dialog box disappear, though the Pview.exe process continues to run. However, it places no icon on the Taskbar and it is unclear how to show it again once it is hidden.

Process and Thread Priority

Process Explode displays the base priority class of active processes and the dynamic priorities of active threads. You can use Process Explode to change the base priority class of processes.

Note You can see, but not change, the dynamic priorities of threads. The Process Explode Thread Priority box has clickable option buttons, but they are for display only; clicking them has no effect.

To display or change the base priority class of a process, select the process from the drop-down list in the first column. All process data in the dialog box changes to show the values for the process you selected. The base priority class of the process is displayed and can be changed in the Base Priority box at the top of the second column.

Process Explode displays three base priority classes: Idle, Normal, and High. Processes running at Real-Time priority appear in Process Explode as High. Process Explode does not let you set a process to Real-Time priority class.

To display the dynamic priority of a thread, select its process from the drop-down list in the first column. Then select the thread by its number from the list box half-way down the first column. All thread data in Process Explode changes to show values for that thread. The thread's dynamic priority is shown in the Thread Priority box at the bottom of the first column.

Process Viewer

Process Viewer (Pviewer.exe) is a utility on the Windows NT Resource Kit 4.0 CD in the Performance Tools group (\PerfTool\MeasTool). It displays information about processes on local and remote computers and is especially useful for investigating process memory use. It also lets you stop a running process and change the base priority class of the process.

Process Viewer is a subset of Process Explode, and its features work in the same way.

Note The select buttons in the Thread Priority box display the current dynamic priority of the thread. You cannot use them to change the thread priority.

It also lets you see the proportions of privileged and user processor time for each thread of the process.

When you click a process in the process box, the whole dialog changes to show the values for that process.

To see memory detail, select a computer and a process, then click the Memory Detail button. The drop-down menu lets you display statistics for each item in the process address space. Note that Process Viewer is not automatically updated; use the Refresh button for manual updates.

 

The SC Utility

The SC Utility is a command line interface for the service controller. It displays the configuration of the computer on which is it run. The SC Utility is on the Windows NT Resource Kit 4.0 CD in the Computer Configuration group. Run it from a command prompt window; it should not be started from the Run command on the Start menu.

At the command prompt, type sc to see a brief description of the commands. Among other things, SC lists all services and drivers on the system.

To see a listing of services, drivers, or both, type:

c:\> sc query

Or, for just services, type:

c:\> sc query type= service

Or, for just drivers, type:

c:\> sc query type= driver

 

For more detail on a driver or service, including the process in which it runs, type:

c:\> sc qc servicename

 

To find the display name, type:

c:\> sc getkeyname displayname

Data Logging Service

Data Logging Service is a Windows NT service that lets you log performance monitor data and alerts automatically as an unattended service. This is especially useful for logging data on a network of remote computers. The logs remain on the remote computer until you review them in Performance Monitor.

Two utilities are needed to set up Data Logging Service: Datalog.exe, the service executable, and Monitor.exe, which configures the settings file. These are included on the Windows NT Resource Kit 4.0 CD in \PerfTool\MeasTool. Instructions for using the utilities are in Rktools.hlp.

Microsoft Test

Microsoft Test is an application that lets you record a series of keystrokes and mouse movements into script files for later execution. These extended macros can then be used to manipulate any graphic user interface, including Performance Monitor.

Note Some older copies of Microsoft Test are intended for 16-bit applications. Be sure to use the 32-bit version for Performance Monitor.

Among other tasks, you can use Microsoft Test to

• Start and stop Performance Monitor at preset times, or run it on certain days of the week and change the update interval as the day progresses.

• Start multiple copies of Performance Monitor, with different settings files for each.

• Merge, relog, and batch Performance Monitor logs for long-term planning.

Response Probe

Response Probe is a utility that lets you design a simulated workload. It then uses that workload to test the performance of your hardware and software configuration. Repeated testing with a fixed, application-independent workload eliminates much of the uncertainty and doubt in performance testing. The response of your configuration is now the only independent variable in the test. When you change your configuration, you can be more confident that any changes in performance result from the new configuration.

Response Probe 2.3 is on the Windows NT Resource Kit 4.0 CD in the Performance Tools group in \PerfTool\Probe\Probe.exe. The Probe subdirectory also includes some useful sample script files and text files explaining how to use them. Response Probe 2.3 must be run from the Command Prompt window of the computer being tested. It cannot be run from the Start button.

This section describes Response Probe, tells you how to run it, how to interpret its output, and then explains how it really works.

What's New in Response Probe

Response Probe no longer requires that you create a simulated codepage file and enter its name in the Process Script File (*.scr). It now reads from a 1000-function internal codepage file in memory. You control the reading of the codepage function file by setting a mean and standard deviation for FUNCTION parameter in the Thread Description File (*.sct).

The CodePageFileName parameter has been eliminated from the Process Script file format. The CODEPAGE parameter in the Thread Description script file (*.sct) has been replaced by the FUNCTION parameter.

Note This feature was added to Response Probe 2.1 and later versions. Earlier versions of Response Probe still require the CodePageFileName and CODEPAGE parameters. To find the Response Probe version number, at the command prompt, type: probe ?

Using Response Probe

Response Probe is commonly used to

• Collect baseline performance statistics.

• Determine maximum throughput values.

• Model the behavior of an application or set of procedures.

• Systematically test the response of each component in your configuration to incremental changes in the workload.

The power of Response Probe is in the wide range of parameters you control and the range of values you can set for each parameter.

Response Probe tests are short and repeatable; that is, the same input will produce the same results every time. The tests can help you determine a range of expected responses for your system. Then, when you use Performance Monitor, you will be able to tell when counters are too high or too low because you know what is normal. Response Probe can help you predict how your equipment will handle workloads of various types, and determine how changes to your equipment have affected its capacity.

Workload Design

All Response Probe workloads have the same basic design. You customize a workload by setting parameters to describe its processes and threads, but you cannot alter the basic design. For more detailed information, see the section titled "How Response Probe Works," later in this chapter.

Response Probe workloads simulate a real user using a real computer. There are cycles of idle or think time, followed by some processing. The processing consists of file access followed by simulated computation that consumes processor cycles. This includes reading code page files and writing to data page files in memory. The following diagram shows a complete workload cycle:

 

Response Probe simulates code pages and data pages. Code pages are pages of memory that contain the program's code. Response Probe's 1000-function internal code page file simulates a file of application program code from which instructions are read during a process. Data pages are memory pages that contain the data used by the program, including global program data, the stack, and heap allocations.

Understanding the Normal Distribution

You describe workloads to Response Probe, in part, by choosing a mean and standard deviation for several parameters that characterize threads in the workload. You choose a mean and standard deviation for

• Length of think times

• Number of processing cycles (file access and computing) between think times

• Length of computing times

• Position of records accessed from the workload file

• Position of pages accessed from the data page file

• Position of functions read from the code page file

The theory behind Response Probe is that real workloads are normally distributed; that is, the time spent thinking, accessing memory, reading and writing to files, finding a record in a file, computing, and other such tasks, are distributed on a standard bell-shaped curve. Alternatively, if the workloads were invariant or random, they wouldn't simulate real use of real computers.

Note The actions of threads and processes are normally distributed, so they are not, technically, fixed. However, in repeated trials the same inputs will produce the same results.

In a bell-shaped curve, most activity is concentrated around the mean, decreasing with distance from the mean, and with the least frequency at both extremes. The standard deviation determines how much activity is concentrated near the mean and how often more distant values occur. By definition, 2/3 of all activity occurs within one standard deviation on either side of the mean, 95% is within two standard deviations, and 99% is within three standard deviations of the mean.

Usually, the midpoint is chosen as the mean, and one-third of the total (1/6 on either side of the mean) is chosen as the standard deviation.

 

For example, in a 1024-page file, if page 512 is the mean and 170 pages is the standard deviation, then:

• 2/3 of reads will be from pages 342–682, (512-170 to 512+170).

• 95% will be from pages 172–852 (512 - (170 *2) to 512 + (170 * 2).

• 99% will be from pages 2–1022 (512 - (170 *3) to 512 + (170 * 3).

If, instead, the mean was 512 and the standard deviation was 256 (1/2 of 512), then 2/3 of reads will be from pages 256–768, and the remaining third would be equally distributed throughout the rest of the file. At the extremes, if the standard deviation is 0, page 512 is the only one read, and if the mean is equal to the standard deviation, reading is random, so all pages are equally likely to be read.

Customizing the Workload

You describe a workload to Response Probe by submitting script files and a simulated workload file. The name of the workload file is included in the script files.

Script Files

Script files are small, formatted text files you create with a text editor such as Notepad. The script files describe a simulated workload to Response Probe in terms of processes and their threads. There are three types of script files, and at least one of each type is required for each Response Probe run. Response Probe identifies the file type by its three-character file extension. You can assign any name to the files; simply add the correct file extension:

Tip You needn't create the files from scratch. Use the sample files on the Windows NT Resource Kit 4.0 CD in the Probe subdirectory as a starting point.

• The Process script file (*.scr) is where you create each process in the workload. There is one Process script file for each Response Probe run.

• The Thread Definition file (*.scp) is where you create the threads that run in the processes.

• The Thread Description file (*.sct) describes the threads in each process. This is where you enter the means and standard deviations Response Probe uses to generate a normal distribution of work for each thread.

The files are closely related. Each process definition in the Process file includes the name of the file where threads for that process are defined. The definition of each thread includes the name of the file where the threads are described.

Process Script File

In the Process script file (*.scr), you create the processes that Response Probe runs. The file consists of one or more process lines, each of which creates, names, and specifies the attributes of one process.

Note Response Probe 2.0 and earlier required that you create a simulated code page file and enter its name in the Process Script file. Response Probe versions 2.1 and later include an internal 1000-function codepage file. They do not require, and will not accept, a CodePageFileName parameter.

By default, Response Probe tests run in a process called Probeprc.exe. You can change the process name to make it easier to distinguish among Response Probe tests in Performance Monitor. Although Performance Monitor 3.51 and later let you monitor multiple processes with the same name, changing the name makes later analysis easier.

To change the process name, copy Probeprc.exe to a file with a different name. Then, enter that name in the optional ProcessName field.

The REPEAT parameter creates separate processes with the same process name. In Performance Monitor, the Process object Instances box will show several instances of the same named process.

The format of each process line is

[REPEAT n] PROCESS ThreadDfFilename.scp DataSize [ProcessName
[PriorityClass]] [# Comments]

Item	Description
REPEAT n	Creates n instances of the process. Each repetition runs the same test with the same process name. This field is optional. The default is 1.
PROCESS	Required word that identifies the process statement.
ThreadDfFilename. scp	Name of the file that defines the threads for the process. When processes are repeated, all repetitions share the same Thread Definition file.
DataSize	Number of pages of virtual memory allocated to simulate data pages. For repeated processes, this number of pages will be allocated for each repetition. The minimum is 0. 10 is a commonly used value.
ProcessName	The name the process in which the test runs. You can change the process name to distinguish among Response Probe tests when analyzing them. To change the process name, copy Probeprc.exe to a file with the new process name. This field is optional, but is required if you choose a priority class.
PriorityClass	The base priority class of the process. Valid entries are I (idle = 4), N (normal = 8), H (high = 13), and R (realtime = 24). Enter only the first letter of the priority type. N is the default. This field is optional, but if you choose a priority class, you must also have a process name other than Probeprc.exe
Comments	Comments can be included anywhere in the Process script file. Begin each line of comments with a # character.

For example, the following line runs one Response Probe test with a 500-page paging file in the PROBE06.EXE process at high priority:

PROCESS TestDisks.scp 500 Probe06.exe H

The following line runs three identical processes, each having the threads defined in A971012.scp. The processes share a 300-page paging file. All of the processes are called Probeprc.exe.

REPEAT 3 PROCESS A971012.scp 300

Thread Definition File

In the Thread Definition file (*.scp), you create the threads that run in the Response Probe processes. This file consists of one or more thread definitions. Each definition creates one thread and associates it with a thread description file.

The format of a thread definition is:

[REPEAT n] THREAD ThreadDescFile.SCT [ThreadPriorityAdjustment]

Item	Description
Repeat n	Creates n instances of the thread. Each instance is treated as a separate, though identical, thread. This field is optional. The default is 1.
THREAD	Required word that identifies the thread statement.
ThreadDescFile. SCT	Name of the file where the characteristics of the thread are described. If the thread is repeated, all repetitions will share the same Thread Description file.
ThreadPriority Adjustment	The amount by which the priority of the thread differs from the priority of the process. This field is optional. N is the default. Options are: (T)TimeCritical = +15, (H)Highest = +2, (A)AboveNormal = +1, (N)Normal = 0, (B)BelowNormal = -1, (L)Lowest = -2, and (I)Idle = -15. Enter only the first letter of the priority adjustment. You don't have to name threads to adjust their priority.

For example:

THREAD ThreadDesc.sct

– Or –

REPEAT 4 THREAD FastThread.sct I

You can also set a priority adjustment for the thread based upon the priority of the process. The actual priority of the thread will be the base priority of the process plus or minus the adjustment.

For example, if you set the priority of the process to Normal (8), and the thread adjustment to L (-2), the thread would run at priority 6.

Thread Description File

In the Thread Description file (*.sct), you set values for the parameters that describe each thread. The parameters may be listed in any order. The sample thread description files on the Windows NT Resource Kit 4.0 CD are a good starting point for creating your own thread description files.

Note In Response Probe versions 3.51 and later, the CODEPAGE parameter has been replaced by the FUNCTION parameter.

Thread Description files are arranged in a table. Each line is in the following format:

PARAMETER_NAME Mean StandardDeviation Comments 

The following table describes the parameters. Optional parameters are shown in brackets [].

Parameter Name	Description	Valid Values for Mean	Values Often Used
THINKTIME	The mean and standard deviation of the idle time between processing, in milliseconds.	0 to trial time.	Mean = 0; Sdev = 0 or Mean = 100 Sdev = 30
CYCLEREADS	The number of times FILEACTION and CPUTIME are executed between think times. Enter the mean and standard deviation.	Minimum is 1.	Mean = 0 Sdev = 30
CPUTIME	The time spent in compute state. Enter the mean and standard deviation in milliseconds.	0 to trial time.	Mean = 0; Sdev = 0 or Mean = 100 Sdev = 30
DATAPAGE	The position of the page to be written to in Response Probe's simulated data page file. Enter the mean and standard deviation of the page number.	0 to the data size specified in the Process script file (*.scr).	Use the midpoint as a mean and 1/6 as the standard deviation. In a 10-page file, use Mean=5, Sdev = 2.
FUNCTION	The position of the function to be read from Response Probe's 1000-function internal code page file. Enter the mean and standard deviation of the function to be read.	1- 1000	Mean = 500 Sdev = 167
FILEACCESS	The name of the workload file to be used in the test. This file can be created manually or by using the CREATFIL utility.
FILESEEK	The position of the record to be accessed in a file. Enter the mean and standard deviation of the record number. This parameter is required for random file access and is ignored for sequential file access.	1 - #records in file. To find #records, filesize (bytes) / recordsize (bytes)	Use the midpoint as a mean and 1/6 as the standard deviation. In a 10-page file, use Mean=5, Sdev = 2.
[RECORDSIZE]	Size of each read from or write to the FILEACCESS workload file, in bytes. This parameter is optional. The default is 4096 bytes. If you change RECORDSIZE, the midpoint of the file will change, so remember to change FILESEEK to match it.	On buffered reads, 1 - filesize. On unbuffered reads, the minimum is one sector of the disk. Use the Windows NT Diagnostics Drive page to find the sector size for your disk.	Filesize/ Recordsize = #records. In a 20 MB file with 4096K reads, #records = 5000. Use: Mean = 2500; Sdev = 834.

[FILEATTRIBUTE]	Enter RANDOM or SEQUENTIAL. This parameter is optional. RANDOM is the default. In random access, record numbers are chosen based on a normal distribution. For sequential mode, the record number from the last FILE ACCESS phase is used as a starting point. When the file system opens the file, it is told that the file is accessed sequentially. This maximizes read-ahead by the cache manager.
[FILEACCESSMODE]	Specifies how files are accessed. This parameter is optional. BUFFER is the default. Valid values are BUFFER (use file system cache), UNBUFFER (no cache) or MAPPED (array in memory). If UNBUFFER is selected, RECORDSIZE must be a multiple of the disk sector size.		See Chapter 6, "Detecting Disk Bottlenecks," for more information.
[FILEACTION]	Specifies the pattern of reads and writes by using the letters R and W. For example, RWRRWWRRRWWW. This parameter is optional. The default is R (one read).

Tip Type comments about each parameter after its specification. Any text on the parameter line after the standard deviation field is ignored. You might include a note on your rationale for that choice, list the units of measurement of the parameter, the date of the last change, your initials, or additional descriptions.

Another Tip Code pages are read and data pages are written once in each processor loop. To determine how many loops your processor generates per second, check the Relative Processor Speed field in the Response Probe output file, described later in this chapter.

Yet Another Tip In buffer mode, Response Probe simulates fast reads (reads that bypass the I/O Manager file system and go directly to the Cache Manager). When charting Response Probe tests with Performance Monitor, add the Sync Fast Reads/sec or Async Fast Reads/sec counters to see this activity.

Sample Thread Description Files

Here are some sample thread description files. There are more on the Windows NT Resource Kit 4.0 CD, and many have text files explaining how to use them.

This sample file tells Response Probe to do nothing and produces almost no response, because Response Probe calculates its own overhead and subtracts it from each cycle.

THINKTIME	0	0
CYCLEREADS	0	0
FILESEEK	0	0
CPUTIME	0	0
DATAPAGE	0	0
CODEPAGE	0	0
FILEACCESS	access.dat

The following example might be used to test disk performance. Response Probe is configured to read the same 4096-byte record in the ACCESS.DAT file 100 times without using the file system cache. Because the standard deviation for CYCLEREADS and FILESEEK is 0, the same record is read exactly 100 times in each cycle. The FILEACCESSMODE is set to UNBUFFER so the system bypasses the cache and goes directly to disk. (Remember, when using UNBUFFER, the RECORDSIZE must be a multiple of the disk sector size.)

The order of the parameters are changed and optional fields are included to make the test record more complete and easy to understand.

CYCLEREADS

100

0

FILEACCESS	access.dat
RECORDSIZE	4096
FILEACTION	R
FILEACCESSMODE	UNBUFFER
FILEATTRIBUTE	RANDOM

THINKTIME	0	0
FILESEEK	100	0
CPUTIME	0	0
DATAPAGE	0	0
FUNCTION	1	0

The following example simulates an application reading very small files directly from a 20 MB file on disk without using the file system cache. This sample test is on the Windows NT Resource Kit 4.0 CD in the Probe subdirectory. There are three variations, each reading slightly larger records. The files are called 512.sc*.

During this test, for each cycle, Response Probe is idle for an average of 1000 milliseconds, then does an average of 100 reads and writes randomly throughout the 40000-record (512-byte records in a 20 MB file) file. Then it computes for an average of 10 seconds, during which it write randomly throughout the 10-page datapage file and reads randomly throughout the 1000-function codepage file.

THINKTIME	1000	300
CPUTIME	10	3
CYCLEREADS	100	30
FILESEEK	20000	6667
DATAPAGE	5	2
FUNCTION	500	167

FILEACCESS	workfile.dat
FILEATTRIBUTE	RAN
FILEACCESSMODE	UNBUFFER
RECORDSIZE	512
FILEACTION	RW

The Workload File

The Process Script file includes the name of the workload file, a file that simulates data records that are read from and/or written to during the process. The content of this file is irrelevant, but its size is crucial. Performance often varies directly with the size of the file.

You enter the name of the workload file in the FILEACCESS parameter of the Thread Description file (.sct).

You can use real workload files, simulate them manually or use the Createfile utility, Creatfil.exe, to create them for you.

Creating Simulated Files

The Windows NT Resource Kit 4.0 CD includes CreateFile, a utility to create zero-filled files of a size you specify.

The CreateFile utility is installed when you do a typical installation or do a custom installation of Performance Tools. It is in \\ RESKIT\PerfTool\Probe\creatfil.exe. It must be run from the Command Prompt Window; it cannot be run from the Run command on the Start button.

At the command prompt, type:

creatfil filename [filesize]

where filename is the name of the file it will create and filesize is the size of the file it will create, in units of 1024K bytes. The filesize is optional. The default is 1024K bytes.

For example, to create a 100K file called workfile.dat, type:

c:\ RESKIT\PERFTOOL\PROBE> creatfil workfile.dat 100

Creatfil produces a 1,048,576-byte file of zeros called workfile.dat.

Running Response Probe

After you have created the script files and working files, you are ready to execute the utility. Run it from a Command Prompt window.

1. At the command prompt, type: 

   probe ProcessFileName.SCR TrialTime [OutputFileName] 

   Item	Description
   ProcessFileName.scr	Name of the process script file.
   TrialTime	Total trial time, in seconds.
   OutputFileName.out	Name of the Response Probe output file. This field is optional. The default is ProcessFileName.out.

The value in the TrialTime parameter is important:

• It establishes the total time for the test. All threads stop when the time expires.

• It determines when Response Probe actually starts measuring performance.

  Response Probe doesn't begin measuring when the test begins; it waits for one-half of the trial time to pass before measuring any values. This is intended to allow time for all processes and threads to launch and to begin operating consistently. Then Response Probe can measure normal operation, not performance at startup time.

• Increasing the trial time produces more repeatable results.

  If the trial time is too short, Response Probe might begin measuring before all threads are launched and operating normally.

Interpreting the Output

Response Probe writes its results to a text output file. The default filename is the same as the Process script file name, but with the .out suffix. However, you can enter a different name as part of the command to run Response Probe.

The file begins with a header that includes copyright and version information, the date and time the test was run. The data lines appear below the header. One line of data is printed for each thread in the Response Probe test.

Response Probe times cycles, each of which consists of one think state, file access state, and compute state for the workload. The output values represent the time of workload cycles only. Response Probe computes and subtracts its own overhead from the values before displaying them.

The values in the output files are actual values, not necessarily those specified in the Thread Description file. Response Probe calculates values based on the means and standard deviations in the Thread Description file. When it calculates an uninterpretable value, such as a negative page number, it folds (recalculates) the number into one that makes sense. For more information, see "How Response Probe Works," later in this chapter.

The following figure is a sample output file. In an real file, the data line columns appear in a single row.

Multi-Processor Response Probe.
Copyright 1990-1993 Microsoft Corporation.
Version 2.1 (93.12.21)
Wed Mar 15 05:45:14 1997
Script File : 512.scr
Trial Time : 300 seconds
Stable interval : [50%..100%] of Trial Time == [150..300] (150 seconds)
Relative Processor Speed: 4.31
(All times are in milliseconds)

PID	TID	File Mode	Rec Size	Total Time	Resp Time	Resp Cnt
----	----	-----	-----	-----	-----	-----
138	131	R U	512	303195	117847	5

Mean	Sdev	Min	Max	Think Mean	Think Sdev	Reads Mean
-----	-----	----	----	-----	-----	------
23569	8055	18860	37679	1000	300	00

Reads Sdev	CPU Mean	CPU Sdev	DataPg Mean	DataPg Sdev	Func Mean	Func Sdev
-----	----	----	-----	------	-----	------
30	10	3	5	2	500	167

Item	Definition
Script File	The filename of the process script file (*.scr). The process file includes the name of thread definition file, and the thread definition file includes the name of the thread description file, so all Response Probe script files used in this test can be traced from this single entry.
Trial Time	This is the time limit you set for the test on the command line. The actual test time is shown in Total Time in the output table, below.
Stable Interval	The time that elapsed before Response Probe started measuring. This is half of the value of the TrialTime parameter in the run command. Response Probe assumes that, by that time, all threads have launched and are processing, and increasing the time limit on the trial does not significantly change thread response times.
Relative Processor Speed	The number of times the compute loop must be executed to consume one millisecond of time on the processor. This is calibrated when Response Probe starts and is used to run the compute state for the time you chose.
PID	Process ID. Windows NT assigns an identifier to all processes. The IDs are assigned in the order that the processes start and don't imply any priority. This field is for identification only.
TID	Thread ID. Windows NT assigns an identifier to all threads in a process. The IDs are assigned in the order that the threads execute and don't imply any priority. This field is for identification only.
File mode	A combination of FILEATTRIBUTE and FILEACCESSMODE. Reports whether file access was random or sequential, and whether access was buffered, unbuffered, or mapped. This field should match the input in the Thread Definition file parameters.
Rec size	Size of the each read/write as specified in the RECORDSIZE parameter, in bytes. This field should match the input in the Thread Definition file RECORDSIZE parameter.
Total time	The actual elapsed time for the test. Compare this value to Trial Time in the output header.
Resp time	Total elapsed time for all test cycles during the measured part of the test, that is, half of the trial time. Response Probe calculates its own time and subtracts it from the data.
Resp cnt	Number of cycles completed during the measured part of the test.
Mean	Average elapsed time of a cycle. This value should be the same in repeated trials with the same input. If it is not, lengthen the trial time of the test.
Sdev	The standard deviation of elapsed time of a cycle.
Min	The elapsed time of the quickest cycle.
Max	The elapsed time of the slowest cycle.
Think mean	Average elapsed time of the think states in the measured cycles.
Think Sdev	Standard deviation of the elapsed time of the think states in the measured cycles.
Reads mean	Average elapsed time of the file access states (reading and/or writing) in the measured cycles.
Reads Sdev	Standard deviation of the elapsed time of the file access states (reading and/or writing) in the measured cycles.
CPU mean	Average elapsed time of the compute states of the measured cycles.
CPU Sdev	Standard deviation of the elapsed time of the compute states of measured cycles.
DataPg mean	Average elapsed time of writes to Response Probe's internal data pages.
DataPg Sdev	Standard deviation of the elapsed time of writes to Response Probe's internal data pages.
Func mean	Average elapsed time of reads from Response Probe's 1000-function simulated codepage file.
Func Sdev	Standard deviation of the elapsed time of reads from Response Probe's 1000-function simulated codepage file.

How Response Probe Works

This section gives some basic details about the Response Probe methods, including the formula its uses to generate normally distributed values, and more details on the stages of the simulated workload.

Calculated Values

Note No two Response Probe tests are ever identical because Response Probe actions are random within the chosen mean and standard deviation. Nonetheless, tests using the same script files should produce similar values in repeated trials.

For each simulated action, such as using the processor or writing to a file, Response Probe calculates a value using this formula:

Value = Mean + (((Sum of 14 random numbers from 0 to 1) -7) * standard deviation)

Fourteen random numbers are used to simulate a bell-shaped curve. Seven is subtracted to return the midpoint to the mean.

Folding

Sometimes, the actual standard deviation varies slightly from what you enter. This happens when Response Probe folds outlying values back toward the mean. While the difference is usually not significant, this folding might reduce the standard deviation slightly.

Response Probe folds values when a computed value has no meaning, such as negative time or record numbers greater than the file size.

If a computed value is negative, it is folded to use the absolute value. For example, if the computed value were -16, the folded value would be +16.

If a computed value is too high, Response Probe subtracts the difference between the computed value and the maximum value from the maximum value to fold the value.

Folded value = Maximum value - (Computed value - Maximum value)

For example, suppose a page number of 102 is computed for a 100-page file. The value is folded back toward the mean and the value used is 98:

100 - (102 - 100) = 98

Sometimes these strategies are combined. If a computed value for a 100-page file is 205, the folded value is 5:

100 - (205 - 100) = -5
|-5| = 5.

Relative Processor Speed

When Response Probe starts, it calibrates the number of cycles the processor can complete in one second. Then, when it needs to consume processor time, it knows how many cycles to consume. It calibrates at High priority.

Think State

The think state simulates a user thinking but not interacting with the computer. The Response Probe thread becomes idle during this state. The length of the think state is a normally distributed value based on the mean and standard deviation set in the THINKTIME parameter of the Thread Description file.

After the think state, Response Probe generates normally distributed value for the number of file access and compute states to execute before the next think state.

File Access State

During this state, Response Probe reads from and/or writes to the workload file specified in the FILEACCESS parameter of the Thread Description file. You choose whether records are accessed randomly or sequentially. If you choose random, Response Probe generates a normally distributed value to determine which records it accesses based on the values in the Thread Description file.

After the file is accessed, Response Probe generates a normally distributed value for the amount of processor time to consume.

Compute State

During this state, Response Probe consumes processor cycles for the time interval you specify. To occupy the processor, it simulates the reading of code pages by reading from a 1000-function internal file. It also simulates writing to data pages by writing to a section of virtual memory backed by the paging file written during computation. Functions and data pages are selected as normally distributed values based on the mean and standard deviation set in the CPUTIME parameter of the Thread Description File.

Troubleshooting Response Probe

Here are some solutions to the most common Response Probe problems. The format of this section is:

Error message or description
Probable cause	Proposed solution

Response Probe error messages look like this:

************************************
* FAILure-->Line=770File=g:\ntrk\source\probe\src\probe.c (pid=0x2A)
* RC=0x7FFFFF0D (Process exe is not found)
* StartProcesses() - FindExecutable failed for codepg.dat
* specified in testfunc.scr
************************************

The error message is on the second and/or third lines, as shown above in bold.

Please keep in mind that Response Probe is not an officially supported Microsoft product. As such, support is limited. Please read the documentation carefully.

Process.exe is not found

Probable cause	Proposed solution
You are using the codepage parameter in the Process script file (*.scr).	Response Probe version 2.1 and later uses a 1000-function internal file as its codepage file. Delete the codepage parameter from your Process script file (*.scr).

FindFirstFile failed for (filename)

Response Probe cannot find the file specified in the FILEACCESS parameter of the thread description (*.sct) file.	Enter the name of a file for Response Probe to read from or write to. You can use a real file, use the 20 MB sample file of zeros on the CD, Workfile.dat, or use the CreateFile utility on the CD to create a zero-filled file of a different size.
Invalid probe data file argument	Invalid probe data file argument
You are using the CODEPAGE parameter in the thread description (*.sct) file.	Replace the CODEPAGE parameter from your Thread Description file (*.sct) with a FUNCTION parameter. Enter a mean and standard deviation for the 1000 function file.

InitializePrc() Virtual Alloc

Probable cause	Proposed solution
Response Probe can not run the test because it cannot allocate enough virtual memory.	Increase the size of your pagefile and try again. Use the System Control Panel Performance page to change the pagefile size.

Invalid Mean and/or Standard Deviation

Probable cause	Proposed solution
You have entered an invalid value for the mean or standard deviation of the FUNCTION parameter in the Thread Description (*.sct) file.	Valid values for the FUNCTION parameter range from 1 to 1000. 0 is not valid.

The output file has column headings but no data.

Probable cause	Proposed solution
There is an error in a script file.	Check that all of the parameters match the format statement. The run statement must include a Process script file (*.scr) name. The Process script file must include a thread definition (*.scp) file name, and the thread definition file must include a thread description (*.sct) file name.