STB Suite

9.0 Release Notes with Screenshots

9.0 Release Notes with Screenshots

NOTE:

Extensive testing in-house and with Sentinel engineering has proven that “long-completion” commands (FORMAT, WRITE SAME, SECURITY ERASE) can cause stability problems when running under Server 2003 OS.

Due to these issues STB will no longer officially support running the STB Suite under Server 2003.

That said, we have “improved” the situation from version older versions such as 8.8.0 which would crash or hang the system when issuing the above mentioned commands. Now there may be a pop-up warning box displaying a “HASP H0033” error, but testing should continue with no hangs or crashes.

Items Addressed in STB Suite version 9.0.0

Overall

Updated Sentinel HASP methods to prevent long-command lock-up or crash. Including using latest Sentinel HASP drivers to work with Server 2008, 2012, & Windows 8

Version 9.0 Release Notes 140603

Installation:

  1. Use new Sentinel HASP drivers for Server 2008, Server 2012, Windows 8 support

AME – New Product

  • Has the ability to be fully automated from either a command window or a batch file
  • Has the ability to execute different test sequences to different drives
  • Has the ability to accept a configuration file that indicates to the automation engine where the logfiles are to be stored, and which test sequences are to be run against which disk drives
  • Has the ability to accept a list of disk drives to run the automation engine against
  • Has the ability to accept user-defined test sequences created within DMM

DMM:

Fixes/Changes:

  1. If an error occurs on the last I/O, we sometimes “double-report” the error
  2. If you modify a test from Sequential access to CPAM access, the “View Test Sequential Details” does not show the correct information

DMM/TMM Additions/New Features

  1. Updated TMM Read LTO MAM test to be compatible with LTO drives through LTO 6
  2. Update DMM Add-In EVPD to decode EVPD page data
  3. Update SATA SMART attribute definitions
  4. Update DMMSATAWriteSame DMM Add-in test to use various data patterns to allow for DoD5220 purges using WriteSame.
  5. DMMSataSecureErase Add-in test added
  6. Update internal writesame tests to log the data pattern used
  7. Add ability to define multiple workers to do a test
  8. Add ability to record up to 10 CDBs that preceded an error

VCPSSL:

Additions/New Features

  1. In FillSRB, propagate the cScsiRequestCode to the SRB’s SRB_TargStat field so that VCSCSIGetErrorDetails will report the Target Status properly
  2. Updated documentation for VCSCSIAddDiskDeviceToBeTested

STB:

Fixes/Changes:

  1. Inquiry Display shows invalid data (when you right-click on a device and click Inquiry, it shows more data than is really in the inquiry data, which was confusing)
  2. Updated LTO Read Cartridge Memory command to be compatible with LTO drives through LTO6
  3. Updated SATA TRIM command to only try to work on SSD drives
  4. Update SATA SMART attribute definitions

Additions/New Features

  1. SATA Secure Erase added to Disk->Commands->Data Functions

DMM Add-ins

DMMSetFeatures
-corrected wrong command code
DMMSataSecureErase – added

Specifics

STB Original Mode SATA Security Erase

Select your SATA drive in the device list, then go to top menu
Disk->Commands->Data Functions->SATA Security Erase

You will see what time estimates the drive reports for Normal and Enhanced SE.

If you click on the Enhanced choice and the drive does not support Enhanced SE you will see this error message

…and the choice will revert back to Normal.

Note: some older drives will report “0” as the time to complete.

Once you click Start Erase you will have one more chance to abort the SE operation

If you continue the drive will begin its SE process and you will see this Status:

Once the SE process completes you will see this

NOTE: The SE command operates as follows:

  1. The drives user password is defined as “STB”, enabling the SECURITY Feature Set.
  2. The drive is told to begin the SE
  3. This issues one command to the drive. This command does not complete until the operation is completed. As this can take a LONG time to complete (10 hours + for a 4TB drive) the test system may become very non-responsive. So much so that if you are running SE on multiple drives only one of the console windows may actually update and display information.
  4. It is VITALLY IMPORTANT that the SE process not be interrupted! Any interruption (system reboot, power cycle of drives or system, etc) will generally leave the drive in a SECURITY LOCKED state in which the drive will have errors with any read or write command.
  5. If you get a drive in the SECURITY LOCKED state contact support@scsitoolbox.com for instructions.

DMM SATA Write Same Test

To use the SATA Write Same test do the following:

  1. Select the External Program test step
  2. In the command line parameters pop up enter the data pattern you want to write.
    pattern=random” (without the quotes). Pattern choices are:
    allzeros,allones,altzeroandone,altoneandzero,incrementing,decrementing,random,walkingones,walkingzeros,alt1and0thenalt0and1,alt0and1thenalt1and0
  3. In the “Download File/External Program Executable” field enter “writesamesata” (without quotes)
  4. Click “Add this test to test sequence”

Test Progress:

This test will show progress by updating the Test Status tab data –

Note: you will see Number of Bytes incrementing and you will see an accurate This Drives Transfer Rate. However you will not see an Estimated Time Remaining.

DMM SATA Write Same Log File

The SATA Write Same test will begin by querying the drive to determine if the supports the SATA SCT WRITE SAME command.

If the drive does not the test will fail and the following information will be entered into its .log file:
05/16/2014  10:32:32  TEST 3 of 5:
                          External Program Test, executable = writesamesata
                          Stop-on-Error Type: Stop Current Test
                        String Data from the External Program follows: 
                        FAILED – Drive does NOT support SCT WRITE SAME –  – FAILED (Dll vs 8.5.0-111103)

  05/16/2014  10:32:32  Worker ID: 1
  05/16/2014  10:32:32  Test Failed

If the drive does support SATA Write Same and completes the process the .log file will contain information like this, showing the data pattern used and the aggregate data transfer rate:

05/16/2014  10:32:25  TEST 3 of 5:
                          External Program Test, executable = writesamesata
                          Stop-on-Error Type: Stop Current Test
                        String Data from the External Program follows: 
                        Pattern: random, Transfer Rate: 108.51

  05/16/2014  10:32:34  Worker ID: 1
  05/16/2014  10:32:34  Test Completed Successfully

DMM SCSI/SAS/FC Write Same Test

To use the SCSI/SAS/FC Write Same test do the following:

  1. Select the External Program test step
  2. In the command line parameters pop up enter the data pattern you want to write.
    pattern=random” (without the quotes). Pattern choices are:
    allzeros,allones,altzeroandone,altoneandzero,incrementing,decrementing,random,walkingones,walkingzeros,alt1and0thenalt0and1,alt0and1thenalt1and0
  3. In the “Download File/External Program Executable” field enter “writesamescsi” (without quotes)
  4. Click “Add this test to test sequence”

Test Progress:

This test will show progress by updating the Test Status tab data –

DMM SATA Security Erase

To use the SATA Security Erase test do the following:

  1. Place the file “dmmsatasecureerase.exe” in the C:\ folder of your test system
  2. Select the External Program test step
  3. In the command line parameter pop-up do not enter anything – just click “OK”
  4. In the “Download File/External Program Executable” field use the browse button to choose C:\dmmsatasecureerase.exe
  5. Click “Add this test to test sequence”

Test Progress:

When the test begins it will open a console-type window which will show the estimated time that the drive reports the SE should finish in. Some drives report 0 for this value, others report a more accurate number.
These console windows may not update due to the nature of the SE command.

DMM SATA Security Erase Log File

If the drive supports the SATA SE functionality and the test passes you will see information like this-
Test Date:  05/16/2014  12:20:13
Test Pass:  1
   Device:  4:270:0   Vendor: ATA, Product: ST3160815SV   Serial:             9RA15GFA, Version: F
   Capacity: 160.04 GB, BlockSize: 512 (0x200)
Results:
— OPERATOR NAME: mdj
— SPECIAL TEXT: SATA SE
  05/16/2014  12:20:13  TEST 1 of 1:
                          External Program Test, executable = C:\dmmsatasecureerase.exe
                          Stop-on-Error Type: Stop Current Test
                        Return code from External Program: 00000000
                        String Data from the External Program follows: 
PASSED – SATA SECURITY ERASE Test vs 2.2 – average data rate = 52.71 MB/sec – PASSED
  05/16/2014  13:09:54                                                 PASSED  

NOTE: The SE command operates as follows:

  1. The drives user password is defined as “STB”, enabling the SECURITY Feature Set.
  2. The drive is told to begin the SE
  3. This issues one command to the drive. This command does not complete until the operation is completed. As this can take a LONG time to complete (10 hours + for a 4TB drive) the test system may become very non-responsive. So much so that if you are running SE on multiple drives only one of the console windows may actually update and display information.
  4. It is VITALLY IMPORTANT that the SE process not be interrupted! Any interruption (system reboot, power cycle of drives or system, etc) will generally leave the drive in a SECURITY LOCKED state in which the drive will have errors with any read or write command.
  5. If you get a drive in the SECURITY LOCKED state contact support@scsitoolbox.com for instructions.

DMM Multiple Worker Threads

SCSI Toolbox is excited to announce the new Multi-Stream capability in the Disk Manufacturing Module (DMM).  This new feature allows the user to define multiple “workers” to execute a particular test.  Many of our customers have asked “Can you execute ten Write Test all simultaneously from separate threads, all running against one drive?”.

We can now do exactly that!

In what follows, we will show you just how easy it is for you, the user, to define as many workers as you want.

Let’s say we want to have four workers executing a Random access Write Test.

In the pic below, we click the Random button and the Write button, leave the default to stop the test after one minute, and choose any data pattern:

To set how many workers you want, you must now go to the Advanced Options dialog, so go ahead and click the Advanced Options button.

On the Advanced Options dialog, at the very bottom, you will see two new fields Workers and Number of Workers.

Go ahead an check the “Workers” checkbox, and then enter the number of workers you want in the Number of Workers edit box.

In our example, we have entered “4” for the number of workers.  See the pic below:

Now go ahead and click the OK button on the Advanced Options dialog.  To add this test to your test sequence, click the Add This Test to Test Sequence button.

Some new pieces of information will show up in the summary of your test.  Go ahead and click the View Test Sequence Details button to see this new information (see pic below):

As you can see from the pic above, the test now contains a new line:
Number of Workers = 4

This is your confirmation that you have set the number of workers to 4 (which you did on the Advanced Options dialog.

Now start your test by clicking the Start Test button.  You will now see that DMM has started your 4 workers in the Test Progress listbox (see pic below):


Because we set up the test to have 4 workers, we see in the pic above that DMM has started four threads on the device, one thread per worker.

You can click the Test Status tab to get real-time information as the test is progressing.   All of the performance information for the selected drive totals up all the performance metrics from the four workers.

You will also note that the DMM  .log file has information for every worker that executed, and the .log file has summary information for all the workers!

================================================================================
>> SCSI Toolbox32, Version 9. 0. 0 (build) 140401, running on \\HEY-KD7ID8KVDT<<
>> Default Driver: 10, Operating System: Server 2003<<
>> Number of Drives Under Test: 3 <<
>> Available Memory (in GB): 0.86 <<
================================================================================

Test Date: 04/04/2014 07:52:04
Test Pass: 1
Device: 5:0:0 Vendor: aaaa, Product: bbbbbbbb Serial: ccc000142496, Version: C018
Capacity: 7.00 GB, BlockSize: 512 (0x200)

Results:
04/04/2014 07:52:04 TEST 1 of 1:
Write Test; Random Access; for 1 Minutes
Fixed-Length Transfers of 128 (0x0080) Blocks
Start Block: 0
Data Pattern: Decrementing
Queue Depth = 1
FUA = OFF
Number of Workers = 4
Stop-on-Error Type: Stop Current Test

04/04/2014 07:53:04 Worker ID: 1
04/04/2014 07:53:04 Test Completed Successfully

Transfer Rate: 24.52 MB/sec
I/O Per Second: 392.33 IO/sec
Number of Blocks Transferred: 3,013,120
Fastest Command Completion Time: 0.348 ms
Slowest Command Completion Time: 70.043 ms
Average Command Completion Time: 2.447 ms
Standard Deviation of Command Completion Times: 1.662 ms

04/04/2014 07:53:05 Worker ID: 4
04/04/2014 07:53:05 Test Completed Successfully

Transfer Rate: 29.01 MB/sec
I/O Per Second: 464.12 IO/sec
Number of Blocks Transferred: 3,564,416
Fastest Command Completion Time: 0.512 ms
Slowest Command Completion Time: 125.879 ms
Average Command Completion Time: 2.053 ms
Standard Deviation of Command Completion Times: 1.211 ms

04/04/2014 07:53:05 Worker ID: 2
04/04/2014 07:53:05 Test Completed Successfully

Transfer Rate: 23.85 MB/sec
I/O Per Second: 381.67 IO/sec
Number of Blocks Transferred: 2,931,200
Fastest Command Completion Time: 1.019 ms
Slowest Command Completion Time: 126.355 ms
Average Command Completion Time: 2.527 ms
Standard Deviation of Command Completion Times: 1.697 ms

04/04/2014 07:53:05 Worker ID: 3
04/04/2014 07:53:05 Test Completed Successfully

Transfer Rate: 23.85 MB/sec
I/O Per Second: 381.65 IO/sec
Number of Blocks Transferred: 2,931,072
Fastest Command Completion Time: 1.030 ms
Slowest Command Completion Time: 125.916 ms
Average Command Completion Time: 2.527 ms
Standard Deviation of Command Completion Times: 1.542 ms

04/04/2014 07:53:06 Transfer Rate (All Workers): 101.24 MB/sec
I/O Per Second (All Workers): 1619.77 IO/sec
Number of Blocks Transferred (All Workers): 12,439,808

04/04/2014 07:53:06 PASSED
———————————————————————-

In summary, there is not a more powerful tool to allow the user to execute multiple simultaneous worker I/O streams to a device, each worker “working” independently of each other.

Automated Manufacturing Engine

The Automated Manufacturing Engine (AME) is STB’s new automation tool that allows you to run scripts created in our Disk Manufacturing Module (DMM).  AME can be run from a Command Prompt Window or even a batch file.  Like other automation tools, once run it requires no user-intervention or “baby sitting”.   After AME completes, the user can then analyze the extensive logfiles for success or failures.

In order to run AME, there are five steps that must be done.  These steps are

  1. Create, within DMM, one or more testing scripts
  2. Decide which devices on your system will be tested
  3. Create a configuration file that will test the devices in step 2
  4. Launch AME
  5. Analyze the logfiles

STEP 1: Create, within DMM, one or more testing scripts

Our first script that we will create in DMM will consists of 4 tests.  The first test is a “Write Test, Butterfly Access, for 1048576 blocks”.  See the pic below:

Our second test will be a “Read Test with Data Compare, Butterfly Access, for 1048576 blocks” – this step is to verify that the pattern “Walking Ones” was indeed written to the start and end of the drive.  Our third step is an “External Program Test”.  The “External Program” name is the DMM’s “WriteSameScsi” Test (you do not need, in this case, to create this executable, DMM already “knows” about it).  See the pic below:

Notice in the pic above, as soon as we clicked the radio button “External Program” DMM brought up a dialog box asking for the command line parameters.  In the above pic, we have entered “pattern=random” (this tells the WriteSameScsi application to write a random pattern to the drive).

Our final test is a “Read Test, Sequential Access, for the Entire Drive” – this step is to verify the entire drive has in fact been written with a random pattern.

In DMM, the 4 tests in our script looks like what is shown in the below pic:

Now let’s save off this script – this script will be “fed into” our AME product.  Go ahead and click the “Save to File” button, and save it off to the file “OverwriteDrive_SCSI.seq” (see the pic below):

Now let’s create a second script – this script is identical to the above script except that it is designed for SATA drives.  Test steps 1,2, and 4 are identical, but step 3, the “External Program Test” is different in that the program name now is “WriteSameSATA” (see the pic below):

Go ahead and save this script off to file “OverWriteDrive_SATA.seq”

STEP 2: Decide which devices on your system will be tested

AME has two ways to tell it which devices you wish to test.  These are the
“device=”

“hba=”

The two parameters that you will pass to AME tell it which devices to test (more on this in STEP 4).  But here are a few examples of using these two parameters:

Example 1: AME.exe AMEConfig.txt device=3-5-0,6-0-0
In this example, AME will test devices 3-5-0 (HBA=3, Target=5, Lun=0), and device 6-0-0.
You can have as many devices as you want listed.  Notice they must be separated by a comma, and that there are no spaces in between.

Example 2: AME.exe AMEConfig.txt hba=3,6
In this example, AME will test all devices attached to HBA #3 and HBA #6.
You can have as many HBAs listed.  Notice the list of HBA numbers are separated by a comma, and that there are no spaces in between

Example 3: AME.exe AMEConfig.txt hba=3,6,device=4-1-0
In this example, AME will test all devices on HBA #3 and #6, and also device 4-1-0

STEP 3: Create a configuration file that will test the devices in step 2

AME requires a configuration file to be passed as the first parameter (see the above examples).  This configuration file has two very important functions:

  1. Informs AME where the logfiles are to be stored
  2. Informs AME which scripts are to be run against which devices

To inform AME where the logfiles are to be stored, you use the keyword “PATHTOLOGFILES”.  Here’s an example:
PATHTOLOGFILE=d:\workdirv900\amelogfiles
IMPORTANT: We recommend that there be NO spaces in the path to the logfiles!

To inform AME which scripts are to be run against which devices, we use the keyword “DEVSEQ”.  Here’s an example:
DEVSEQ:VENDOR=Seagate,SEQ=OverWriteDrive_SCSI.seq

Notice in the above example, the format is basically

DEVSEQ:VENDOR=abc,SEQ=xyz.seq

What this DEVSEQ line in your configuration file tells AME is that out of all the devices you list in STEP 2, any one of them which is made by Seagate, AME will run test sequence file “OverWriteDrive_SCSI.seq against these drives.

Here’s another example:
DEVSEQ:VENDOR=Maxtor,SEQ=OverWriteDrive_SATA.seq
This tells AME that out of all the devices listed in STEP 2, any one of them which is made by “Maxtor”, that AME is to run test sequence file “OverWriteDrive_SATA.seq” against them.

One of the advanced features of AME is that it can run two completely different test sequences simultaneously, one test sequence to one set of drives, and another test sequence to another set of drives, but done SIMULTANEOUSLY!!

Other DEVSEQ usages are as follows:
DEVSEQ:PRODUCT=MX00486,SEQ=OverWriteDrive.seq (change MX00486 to whatever your product is)
DEVSEQ:HBA=17,SEQ=OverWriteDrive.seq (change 17 to whatever your HBA number is)
IMPORTANT: Use of the “DEFAULT” keyword.  You can tell AME a default test sequence to run against a drive.  Here’s an example:
DEVSEQ:VENDOR=DEFAULT,SEQ=OverWriteDrive.seq
What the above tells AME is that no matter what the VENDOR is of a drive, to use sequence “OverWriteDrive.seq”

Here’s an example of an AMEConfig.txt file:
PATHTOLOGFILE:d:\workdirv900\AMELogfiles
DEVSEQ:VENDOR=Seagate,SEQ=OverWriteDrive_SCSI.seq
DEVSEQ:VENDOR=Maxtor,SEQ=OverWriteDrive_SATA.seq

STEP 4: Launch AME

The parameters to launch AME from a command prompt window or a batch file are as follows:
AME.exe Configuration_File_Name List_of_Devices_To_Test

Notice there are just two command-line parameters to pass AME.exe

Here’s an example from STEP 2:

Example 1: AME.exe AMEConfig.txt device=3-5-0,6-0-0

STEP 5: Analyze the logfiles

If you have defined the PATHTOLOGFILE keyword in your configuration file, for example you have a line such as

PATHTOLOGFILE=d:\workdirv900\amelogfiles

Then to locate your logfiles, go to the folder you have specified in the PATHTOLOGFILE line.  The logfiles have exactly the same information as the logfiles created by DMM.

AME SATA Write Same Test

To use the SATA Write Same test in AME do the following:
Setup an external program test step as outlined in the section “DMM SATA Write Same Test” and add this test to your test sequence that will be inputted into AME via your configuration file.

AME SCSI/SAS/FC Write Same Test

To use the SCSI/SAS/FC Write Same test in AME do the following:
Setup an external program test step as outlined in the section “DMM SCSI/SAS/FC Write Same Test” and add this test to your test sequence that will be inputted into AME via your configuration file.