When usex is invoked without specifying an input file specifying a test suite, the user will be presented with a set of prompts, whose answers will specify exactly what set of test(s) are run.
The number of tests that can be run in a usex session is dictated by the size of the terminal window, which must be at least 80x24. Because of the manner in which the output display screen is formatted, an 80x24 window will allow at most 12 tests to be run. The maximum number of tests allowed by a single usex session is 48, which requires an 80x60 terminal window. Any attempt to run usex in a terminal window with less 80 columns or less than 24 lines will fail immediately. If run from a window with more than 60 lines, the 48 test limit will apply.
For example, if invoked from an 80x24 window, the user is first informed of the maximum number of tests that can be run, and then prompted for a number:
# usex UNIX System EXerciser (USEX) Version 1.7 Mission Critical Linux The maximum number of built-in or user-supplied tests is 12. A <RETURN> implies that NO built-in or user-supplied tests will be run. How many tests would you like to run? ==>
After entering the number of tests to run, instructions are issued that explain how to specify a test type. The instructions are followed by a prompt that asks what type of test should be executed as "test 1" of the 12 tests requested in this example:
How many tests would you like to run? ==> 12 Enter one of the following: 1) a directory in which to create an I/O test file. 2) a block or character device file name to use as an I/O test file. 3) "rate" followed by either a device file name, or a mount point on which to run a transfer rate test. 4) "whet" for the built-in whetstone benchmark. 5) "dhry" for the built-in dhrystone benchmark. 6) "vmem" for the built-in virtual memory test. 7) "bin" for the built-in UNIX command suite. 8) a UNIX command or shell script preceded by a "!". 9) a <RETURN> implies a repeat of the LAST directory or test type that was entered, or if no prior selection has been made, the current directory will be used for an I/O test. Enter directory, device or command for test 1 ==>
There are seven possible test types that can be run, based upon the response to the prompt above:
For complete details on any of the test types, click on any of the test type links.
- A disk I/O testwill be invoked if a directory name, a block device name, or a character device name is entered. The test performs a set of write-read-compare operations on the file, building to, or seeking to, a user-specified file size limit, performing writes of a user-specified buffer size. If a directory name is entered, a temporary file will be created in that directory. When the limit has been reached, a set of read-compare operations are performed from the end of the file back to the beginning. The file fill/truncate cycle is repeated indefinitely, until and unless a disk corruption is detected.
- A transfer rate test will be run if the word "rate" followed by a directory name, block device name, or character device name is entered. The test reads the designated file in user-specified block size until it reaches a user-specified file limit, and simply times the transfer in kilobytes/second. If a directory name is entered, and that directory happens to be local mount point, the associated block device will be read; if not, a temporary file will be created in that directory. The test cycle is repeated indefinitely.
- The Whetstone benchmark will be run repeatedly if the word "whet" is entered.
- The Dhrystone benchmark will be run repeatedly if the word "dhry" is entered.
- A virtual memory test will be run if the word "vmem" is entered. The test allocates a user-specified number of megabytes of memory, and then randomly touches the pages in the allocated address space. The test continues forever, i.e., does not end and restart like the other test types.
- The bin test suite consisting of the execution of a test suite consisting of over 300 commands from the /bin, /usr/bin and /usr/sbin directories, if the word "bin" is entered. Once the test suite has been completed, it will be re-run the suite indefinitely until and unless a command failure is detected.
- A user-supplied command or shell script will be executed repeatedly if the command string is preceded by an exclamation point. Instead of being restricted to the built-in tests above, this test type allows the user to run any external test command or shell script.
For example, the following set of answers dictates that at least one of each test type should be run. Note that if <RETURN> is entered alone, it means to repeat the last test type that was entered. If no previous tests have been entered, the current directory will be used for a disk I/O test:
Enter directory, device or command for test 1 ==> /usr/tmp Enter directory, device or command for test 2 ==> Enter directory, device or command for test 3 ==> rate /dev/sda1 Enter directory, device or command for test 4 ==> whet Enter directory, device or command for test 5 ==> dhry Enter directory, device or command for test 6 ==> vmem Enter directory, device or command for test 7 ==> Enter directory, device or command for test 8 ==> bin Enter directory, device or command for test 9 ==> Enter directory, device or command for test 10 ==> Enter directory, device or command for test 11 ==> Enter directory, device or command for test 12 ==> !cat /etc/passwd
Based upon the example input above:
Test 1 will be a disk I/O test that will be run on a temporary file created in /usr/tmp. Test 2 -- because <RETURN> was entered -- will be another disk I/O test run on a different temporary file in /usr/tmp. Test 3 will be a transfer rate test on the /dev/sda1 block device file. It should be noted that if a directory name that is a mount point for /dev/sda1 were entered, the test would also be run on the /dev/sda1 block device. However, if an entered directory name is not a mount point, or is an remote NFS mount point, a temporary file will be created in that directory, and then that file would be read. Test 4 will consist of the whetstone benchmark. Test 5 will consist of the dhrystone benchmark. Test 6 -- and test 7 because <RETURN> was entered -- will both be virtual memory tests. Test 8 -- and tests 9, 10 and 11 because <RETURN>s were entered -- will all be bin test suites. Test 12 is a trivial example of a user-supplied test.
At this point, test types have been specified for each of the 12 possible test "slots". Several of the tests, however, require additional parameters. For each test requiring additional data, additional prompts will be issued. Given the test selections above, the 2 disk I/O tests, the transfer rate test, and the 2 virtual memory tests all require a data buffer:
Tests 1, 2, 3, 6 and 7 require buffer sizes. The buffer size must be entered in one of the following ways: 1) a literal integer value. 2) a number followed by a "k" or "K", for multiples of one kilobyte. 3) the vmem test requires the number of megabytes to allocate. 4) a <RETURN> implies a repeat of the LAST buffer size that was entered. At least ONE buffer size MUST be entered. Enter a buffer size for I/O test 1 (/usr/tmp) ==>
The disk I/O tests will do write-read-compare cycles using a buffer size expressed in a number of bytes, or a number of kilobytes followed by a "k". The transfer rate test will read its file using a buffer size specified in the same manner. The vmem test will allocate a buffer that is sized by the number of megabytes specified:
Enter a buffer size for I/O test 1 (/usr/tmp) ==> 4k Enter a buffer size for I/O test 2 (/usr/tmp) ==> 8k Enter a buffer size for transfer rate test 3 (/home) ==> Enter number of megabytes for virtual memory test 6 ==> 30 Enter number of megabytes for virtual memory test 7 ==>
Test 1 will use a buffer size of 4096, test 2 will a buffer size of 8192, test 3 will also use 8192 since <RETURN> was entered, test 5 will allocate 30 megabytes of memory, as will test 6 since <RETURN> was entered.
The 2 disk I/O tests and the transfer rate test require one additional parameter, a file size limit. These limits may only be expressed in kilobytes or megabytes, or if acceptable, and "f" may be entered:
Tests 1, 2 and 3 require file size limits. The file size limits must be entered in one of the following ways: 1) a number followed by a "k" or "K", for multiples of one kilobyte. 2) a number followed by a "m" or "M", for multiples of one megabyte. 3) an "f" implies: for I/O tests: "until the file system is full" for transfer rate tests: "read the whole file" 4) a <RETURN> implies a repeat of the LAST file size that was entered. At least ONE file size limit MUST be entered. Enter the file size limit for I/O test 1 (/usr/tmp) ==> 1m Enter the file size limit for I/O test 2 (/usr/tmp) ==> f Enter the file size limit for transfer rate test 3 (/home) ==> 150m
Test 1 will run an I/O test on a temporary file in /usr/tmp that will be 1 megabyte in size. Test 2 will also run an I/O test on a temporary file in /usr/tmp, but the file will increase in size until the file system is full and can no longer provide any more free disk space. Test 3 will run a transfer rate test on /dev/sda1, timing how long it takes to read 150 megabytes.
At this point, all test parameters have been collected. Two more prompts are left to be answered, the first of which allows a user to specify a time in minutes for the usex session to run:
If desired, enter automatic USEX kill time in minutes. A <RETURN> implies that USEX should run indefinitely ==>
In most cases, a <RETURN> will suffice. A usex session will run indefinitely unless a time in minutes is specified. Typically the session is killed interactively by entering the "k" command after the tests have been up and running for some period of time.
The final question is concerned with the verbosity of the data output by each individual test:
Enter a "b" if initial display mode is to be in background. A <RETURN> implies foreground display mode ==>
Depending upon the type of built-in test, they can be run in either a verbose, "foreground" mode, or in a less verbose "background" mode. All built-in tests except for the bin test run by default in the verbose, foreground mode. To force them all to run in the less verbose background mode, enter a "b" to the final prompt above.
Upon answering the final prompt, the usex display screen appears, and all of the designated tests start. For example, given the prompt answers shown above, here's a capture of the display screen after the tests had been running for several minutes:
******************************************************************************** * ID BSIZE MODE POINTER OPERATION FILE NAME PASS STAT * * -- ----- ---- --------- --------- ----------------------- ---- ---- * * 1 4096 Trun 315392 read..... /usr/tmp/ux000936_01 2 OK * * 2 8192 Fill 2686976 write.... /usr/tmp/ux000936_02 1 OK * * 3 8192 Rate 839 kb/sec read[17%] /dev/sda1 2 OK * * 4 170.850 MWIPS Loop N6.. whetstone benchmark 2 OK * * 5 450450 dhrystones/second dhrystone benchmark 74 OK * * 6 30 mb random 57.2 mb virtual memory test *** OK * * 7 30 mb random 57.0 mb virtual memory test ** OK * * 8 /usr/bin/ar [ ] 1 BKGD * * 9 /bin/csh [ ] 1 BKGD * * 10 /usr/bin/groups [ ] 1 BKGD * * 11 /usr/bin/cut [ ] 1 BKGD * * 12 cat /etc/passwd [xfs:!!:100:102:X Font Server:/etc/X11/f] 365 OK * ******************************************************************************** * Unix System EXerciser * USER SYSTEM IDLE LOADAVG TASKS/RUN TEST TIME * * USEX Version 1.7 * 95% 5% 0% 12.46 92/9 000:06:22 * * * * * anderson - i686 * PAGE-IN PAGE-OUT FREEMEM FREESWAP CSW INTR * * Linux 2.2.5-15smp2 * 2209 48 1.0 mb 126 mb 825 446 * * * SWAP-IN SWAP-OUT BUFFERS CACHED FORKS * * 2May01 14:36:17 * 0 0 3.0 mb 13.7 mb 5 * ********************************************************************************
The tests will run until a failure is detected. The usex session can be killed by entering "k", and then a confirming "y", interactively.
To run the exact same test suite at a later time without having to re-enter the parameters, enter "F" interactively while the session is still active. A status box will indicate the name of a file that can be fed to subsequent usex sessions using the "-i inputfile" command line option.
That is the end of the usex invocation tutorial. For details on the specifics of the six built-in tests, or how to invoke a user-supplied test, click on the appropriate link below:
For details on usex command line options, the usex display screen, and run-time interactive commands, click on the appropriate link at the bottom of this page.