In last month’s newsletter we described some new DTB api calls which implement a Command Probability Sequencer test. These new DTB api calls will be in the STB Suite version 8.2.
This month we will introduce a stand-alone application which uses these same api calls to implement an interactive test application – we will call this application CPS. CPS will be available at the same time STB Suite version 8.2 is released.
CPS is useful any time you need to send a number of different commands to one or more drives, in either a sequential or a random order. Some of CPS’s features are:
- Ability to define a list of SCSI (FC, iSCSI, or SAS) commands
- Commands may be 6, 10, 12 or 16 bytes long
- Timeout value can be set per command
- WRITE (10) and READ (10) commands can increment the LBA field by any number
- READ data compare may be specified
- Each command can have its own data associated with it, of any size
- Each command can be assigned a % probability – the number of times out of the total test I/O size that each command will be issued. For instance, a command with a probability of 10% would be issued 10 times during a test which is generating 100 I/Os.
- CPS implements Command Tag Queuing and Native Tag Queuing – desired queue depth user defined
- Any number of drives on up to 16 HBA’s can be tested
- Commands in the list may be issued sequentially or randomly
- Sequential mode is exactly that – random mode looks at the entire command list, determines how many I/O’s are to be issued, determines how many of each command have been issued, and balances the probability percentage of all the commands so that at the end of each test the proper number of each command have been issued. Phew! Complex? Yes!
- Command lists may be saved and reloaded
- All busses may be rescanned to accommodate hot-swapping
- A BAM capture trace of all test I/O may be specified. This trace is saved as a .csv file.
Here is a screenshot showing CPS:
CPS is very useful for performing tasks like command compliance testing, performance measuring – particularly measuring performance in a real-world situation where disk read or write cycles may be intermixed with random other commands, such as occasional LOG SENSE commands, or occasional READ or WRITE commands to other areas of a drive. It is also very useful for stress-testing storage system components such as HBAs, bridges, and backplanes by issuing extremely high I/O rate command sequences to many drives at once.
The CDB Parameters area is used to define the CDB’s which will make up your test. You specify the CDB size, the individual bytes which make up the CDB (you can define a “legal” or an “illegal” CDB), the data direction, the data transfer length, the data pattern, whether you want an LBA overlay applied to READ or WRITE commands, the command timeout in seconds, the queue depth you hope to attain, whether you want the LBA field in READ or WRITE commands to be automatically incremented, and by what amount they should increment, and finally what probability percentage should this command have.
Plan ahead because the total probability numbers of all commands MUST equal 100.
Here is an example of adding a READ and a WRITE command to the command list:
Once your READ command is defined click on Add Command to List. Now, the WRITE command:
Be careful – make sure that your data direction is correct and that you specify the exact correct data transfer length – be is zero, or 1 block worth of bytes, etc. And again – plan ahead so that your commands total 100% probability. If you make a mistake and add an incorrect CDB to the command list just mouse to the far left column (CDB Len) on that command and right-click to remove it from the list.
Here is an example of seven commands take a close look at the way the Data Direction and Data Lengths look – having either of this incorrect can cause Windows to abort the command and possibly issue a bus reset – :