Script Files

All scripts that drive Response Probe are tiny text files. There are three types of script files:

• .SCR files for creating processes in Response Probe runs. For each Response Probe run, there is exactly one .SCR file.
• .SCP files for creating threads for processes.
• .SCT files for setting parameters for the threads.

You can create any number of processes and threads in this way, and these processes and threads can be similar or different in any way you want.

*.SCR File Format

This script file is used as the first input argument to the probe program. It contains all process script file names. For each PROCESS line specified in the file, a process is created with the following parameters:

• Script file name
• Data memory pages size (in number of pages)
• "Code" memory pages

The format of each PROCESS line in the .SCR file is:

|

[REPEAT N] PROCESS ParameterFileName.SCP DataSize CodePagesFileName [ProcessName [PriorityClass]]

ParameterFileName is the name of the .SCP file for this process. DataSize is the amount of virtual memory (in pages) allocated as the paging file that simulates data pages. CodePagesFileName is the name of the file (that you must have created) to be used to simulate code pages. You can use the createfil utility to create CodePagesFileName. The size of this file determines how large the code space is. The process maps virtual memory to the size of the code pages file. "REPEAT N" creates the PROCESS within the same line N times, creating N processes.

ProcessName and PriorityClass are optional, but if you specify a PriorityClass you must also specify a ProcessName. The default for ProcessName is PROBEPRC.EXE. Changing this makes it possible to have child processes with different names so they can be identified by the Performance Monitor. You'll copy PROBEPRC.EXE to files with these names before running. PriorityClass is one of the following: Idle, Normal (the default), High, and Realtime. You need supply only the first letter of the priority class (I, N, H, or R).

To include a comment in the .SCR file (or in a .SCP or .SCT file), begin that line with a # character.

Here is an example .SCR file that creates one process and then three more:

|

PROCESS  LikeMine.scp 500 SomeCode.dat MyProg.exe H
REPEAT 3 PROCESS  LikeHis.scp 300 OtherCod.dat HisProg.exe N

The first line creates a process with the process parameter file LIKEMINE.SCP. The data space in the paging file is 500 pages. The file for simulating the code space is SOMECODE.DAT. You have copied PROBEPRC.EXE to MYPROG.EXE for this process. It executes at High Priority class.

The next line creates three identical processes. Their parameters are in the LIKEHIS.SCP file. They each allocate 300 private pages of paging file. They will share the "code" pages in the OTHERCOD.DAT file. The three processes each have the name HISPROG.EXE (you must have copied PROBEPRC.EXE to this filename), and you will see data from only one of them in the Performance Monitor. They will run at Normal Priority class.

*.SCP File Format

This script file contains the names of the thread script files. For each THREAD line, a thread is created using the parameters in another specified script file..

The format of each THREAD line is as follows:

|

[REPEAT N] THREAD ThreadFileName.SCT [ThreadPriority]

ThreadFileName is the name of the .SCT file containing the parameters for this thread. ThreadPriority is optional. If it is specified, it must be one of the following: TimeCritical, Highest, AboveNormal, Normal (the default), BelowNormal, Lowest, and Idle. Only the first letter of the thread priority is significant and need be supplied.

"REPEAT N" creates N identical threads.

*.SCT File Format

This script file contains all the information required for the operation of Response Probe threads. Supplied mean and standard deviation values may not be negative numbers.

Here is the format of the .SCT file. The parameter lines can be in any order. The units for each parameter on the right are not part of the specification of the workload, but are indicated here for reference. We actually include them in each .SCT file for reference since they don't hurt anything by hanging around out there on the end of each line.

|

The commands FILEATTRIBUTE, FILEACCESSMODE, RECORDSIZE, and FILEACTION are optional. All others are required. Defaults for the optional commands are Random, Buffered, 4096, and 1 Read respectively.

If UNBUFFERED is selected as FILEACCESSMODE, then the RECORDSIZE must be a multiple of the disk sector size.

A few of these parameters deserve some additional explanation. CYCLEREADS indicates the number of times that FILEACTION followed by CPUTIME are executed before the next THINK cycle is carried out. The name CYCLEREADS is a holdover from early versions of Response Probe. Forgive us just this once.

FILESEEK is how you distribute random access on the FILEACCESS file. It specifies a mean and standard deviation of the record to be accessed. It is typical to place the mean at the central record of the file; for example, at record 500 in a 1000-record file.

DATAPAGE and CODEPAGE also specify a mean and standard deviation of the page to be accessed, except that they are in units of pages.

If the FILEACCESS method is SEQUENTIAL, FILESEEK is ignored. If SEQUENTIAL mode is specified, access starts at the beginning of the file again when the end of the file is reached. We defined FILEACCESSMODE already. If you can't remember how it works you have to read this appendix again as a punishment.

RECORDSIZE is the size of each file access to the FILEACCESS file. If you change this, you might want to adjust FILESEEK to get the same access pattern since it is in units of records, and the record that is the center record in a file will change as you modify the RECORDSIZE. Tricky, huh?

FILEACTION is the most fun parameter. Here you specify a string of reads and writes with R and W. Here is an example FILEACTION:

|

FILEACTION     RRWRR

In this case, FILESEEK is performed first if access is RANDOM, otherwise it accesses the next sequential record in the file. That record is read, and then so is the next record. The second record that was read is then written. In other words, writes that follow reads write the last record that was read, much as an application would. Then the third record in the sequence is read, and then the fourth. Now this FILEACTION is over, and a COMPUTE phase executes, and then another [FILESEEK /] FILEACTION occurs as long as the number of CYCLEREADS computed for this cycle has still not decremented to zero. This permits the simulation of a wide variety of file access patterns, although certainly not all possible patterns.

Sample .SCT Files

Here are some sample .SCT files. The first one does nothing, and you'll get a near zero response time from it because Response Probe has calibrated its overhead and subtracted it from each cycle.

|

Here's one that reads a single record, 1024 bytes long, from the start of the ACCESS.DAT file 100 times, without using the file system cache:

|

Finally, here is an example of a workload that, during its 1000 milliseconds of computation, repeatedly reads the first DWORD of a page in a 4-MB code page file. The page reads will occur in a normal distribution. Four megabytes is 1024 pages on a machine with 4096-byte pages, so the central page is number 512. One third of 512 is about 170, so to stretch the bell-shaped curve across the file we specify 170 as the standard deviation.

|

If we had specified 512 and 170 for DATAPAGE instead of CODEPAGE, during computation Response Probe would have written to the first DWORD of a page selected with the normal distribution from the paging file section of 1024 pages that we had specified in the .SCP file for the experiment.

These code and data page references occur once in each basic computation loop. The number of basic processor loops per millisecond on the processor in question is given by the Relative Processor Speed in the .OUT file described in the next section. The basic computation loop computes the result for these two normal distributions, checks to see if it is time to stop computing, and that's about it.