Chapter 11 - Performance Monitoring Tools

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

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.

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 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.

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.

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.

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.

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.

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.

 

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.

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:

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.

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.

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.

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.

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.

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.

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 (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 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 (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 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 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 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 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.

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 ?

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.

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.

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.

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 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.

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]

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

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]

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.

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 [].

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.

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.

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.

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.

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.

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] 

   Expand table

   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.

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)

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.

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.

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.

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.

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.

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.

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.

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

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

FindFirstFile failed for (filename)

InitializePrc() Virtual Alloc

Invalid Mean and/or Standard Deviation

The output file has column headings but no data.