STB Suite

May 2013

In this Issue:

  • Introduction to Command Queuing
  • Advanced Stop-On-Error options in DMM
  • Ask Dr. SCSI – Can I modify an existing test sequence so I don’t have to start over?
  • Coming soon, the AME – Automated Manufacturing Engine!
  • Ready to receive your 8.7.1 Performa upgrade email?

What is Queue Depth, Command Queuing, and how do I set or achieve Command Tag Queuing?

Queuing

Queuing is a method of sending multiple commands to a drive while not waiting for the drive to process each command before sending the next.

You could  issue one command to the drive, and while the drive is still processing that command you can  issue another command, etc. until your queue is full. Each command you issue is put into a Queue, and as the drive completes one command out of the queue it fetches the next command from the queue and executes it. While commands are being executed by the drive more commands can be “stacked up” or added into the queue, to be processed when the drive gets to them.

Since it takes longer for the disk to execute a command than it takes to issue commands to the drives queue you can end up having a fairly deep queue of commands waiting to be processed by the drive.

This type of queuing is called a Simple Queue – the drive executes the commands in the queue in the same order that the commands were placed into the Queue. This is sometimes referred to as a FIFO (First In First Out) type of queuing method.

There are more complex types of queuing, such as Ordered Queuing, where instead of the disk just executing the queued commands in the order they were issued (FIFO), the drive actually analyzes each command in the queue and sorts them, executing the commands in an order which may give higher performance.

For example, a drive may take commands out of its queue based on the starting LBA of each command, to try to issue commands to the drive in a way that would minimize moving the heads back and forth.

As you can see command queuing is a complex process. Commands which are placed in the queue are tagged with an identifier called a “tag”. The operating system, drivers, and host bus adapter all use these tags to keep track of which commands are still waiting in the queue and which command is currently being processed. The use of these tags becomes very important when there is a problem and the drive can’t execute a command properly.  For another example of the importance and complexity of dealing with queued commands and keeping track of them via their tags, imagine what must happen if you have 100 write commands queued and you lose power to the disk drive? Keeping track of which tags were completed successfully and which tags weren’t is a very complex task!

You may see the terms Command Tagged Queuing or Tagged Command Queuing. These terms all refer to the process of queuing commands, that is, putting commands into a queue at the same time the drive is taking commands out of the queue and executing them.

Queue Depth

The term Queue Depth refers to how many commands  the drive, host bus adapter, driver, and operating system can have in a queue. Some drives have a queue depth limit of 32, while some newer storage technologies such as NVMe supports queue depths of 64K!

Queuing in the STB Suite

Queuing and allowing the operator to specify the desired queue depth is supported in the STB Suite Disk Manufacturing Module (DMM). You specify the desired queue depth via the Advanced Options  page using the Queue Depth setting –

For each test step you can specify the maximum queue depth desired. Note – it is possible to enter a desired queue depth which for one reason or another cannot be attained. DMM will try its best to issue commands fast enough to sustain the  desired queue depth. SATA drives will report what their maximum queue depth is via their IDENTIFY data – such as these –



There’s no point specifying a queue depth greater than the supports.

What does Queuing look like?

Click here to see the screenshots of queuing and read the rest of the article.

 

Advanced Stop-On-Error options in DMM

Disk Manufacturing Module (DMM

DMM has several options that control what happens if a drive fails during a test run.

The “Stop On Error” options, which can be set on the “Advanced Options” dialog inside of DMM, were designed to allow you to accomplish the following six options:

  1. If an error occurs to stop the current test in the test sequence
  2. If an error occurs to stop all tests in the test sequence
  3. If an error occurs to simply ignore the error
  4. If an error occurs to run an “External Program”
  5. If an error occurs to run an “External Program” and if the “External Program” fails to stop the current test
  6. If an error occurs to run an “External Program” and if the “External Program” fails to stop all tests
  7. If an error occurs to run an “External Program” and continue executing the current test

Let’s take a closer look at each of the above options.

Option A) If an error occurs to stop the current test in the test sequence

On the Advanced Options dialog in DMM, you set this option as seen in the following picture:

EP_1

Notice that the checkbox “Stop On Error” is checked, “Group 1” is checked, and “Group 2” is unchecked

As an example, let’s say you have a 7-step test sequence, and step 3 is a sequential write test for 10 minutes, and that step 3 is currently executing when an error occurs at say the 5 minute mark of the test.  What this option will do is stop the current test (i.e. step 3 of 7 steps, will NOT continue the remaining 5 minutes of the sequential write test, and proceed to step 4 of your 7 step test sequence).

Option B) If an error occurs to stop all tests in the test sequence

 

On the “Advanced Options” dialog in DMM, you set this option as seen in the following picture:
EP_2

Notice that the checkbox “Stop On Error” is checked, “Group 1” is checked, and “Group 2” is unchecked

As an example, let’s say you have a 7-step test sequence, and step 3 is a sequential write test for 10 minutes, and that step 3 is currently executing when an error occurs at say the 5 minute mark of the test.
What this option will do is stop all tests (i.e. it will stop step 3 and will NOT continue the remaining 5 minutes of the sequential write test, and will NOT execute steps 4-thru-7).

 

Option C) If an error occurs to simply ignore the error

On the “Advanced Options” dialog in DMM, you set this option as seen in the following picture:

EP_3

Notice that the checkbox “Stop On Error” is checked, “Group 1” is checked, and “Group 2” is unchecked

As an example, let’s say you have a 7-step test sequence, and step 3 is a sequential write test for 10 minutes, and that step 3 is currently executing when an error occurs at say the 5 minute mark of the test.  What this option will do is simply ignore the error (i.e. it will continue step 3 and will continue with the remaining 5 minutes of the sequential write test, and after this step 3 has completed proceed to step 4 of your 7 step test sequence).

Option D) If an error occurs to run an “External Program”

 

On the “Advanced Options” dialog in DMM, you set this option as seen in the following picture:

EP_4

Notice that the checkbox “Stop On Error” is checked, “Group 1” is unchecked, and “Group 2” is checked

As an example, let’s say you have a 7-step test sequence, and step 3 is a sequential write test for 10 minutes, and that step 3 is currently executing when an error occurs at say the 5 minute mark of the test.  What this option will do is run the “External Program” that you inputted on the “Advanced Options” dialog, and pass, as a command line argument, the following information:

HBA=n,TID=m,LUN=x,SLOT=255,RecordTemperature.

IMPORTANT: Notice that preceding the command line parameters you inputted on the “Advanced Options” dialog are the device address of the device that had the error.  After the device address information, we append the string “RecordTemperature” at the end of the command line argument to the “External Program”.

After the “External Program” completes, the return code from the External Program logged to the devices logfile and step 3 is stopped (so the remaining 5 minutes of the sequential write test is not performed).  Then we proceed to step 4 of your 7 step test sequence.

View options E-G as well as “Asynchronous Notifications” in DMM in the full article here.

 

 

 

Ask Dr. SCSI – Can I modify an existing test sequence so I don’t have to start over?

DMM - Disk Manufacturing Module

Q. I have a DMM test sequence that is used every day for testing disk drives. I want to change where the log files are created & stored. Is there a way to modify an existing test sequence so I don’t have to start over from scratch?

A. Yes, there sure is! Just follow these steps:

  1. Load your existing test sequence
  2. Make sure that the Test Setup tab is selected
  3. In the upper right corner (in the Test Sequence window) highlight the first test step
  4. Make whatever changes you want made. In this case you want to change the path to the log file folder, so click on the Advanced Options button, use the Browse button […] next to the Path to Log Files box and choose the new location where you want the log files to be created.
  5. Now click OK to exit the Advanced Options
  6. Now click the Modify Current Test Step button – this will save the change(s) you just made.
  7. When you have made all the changes you want re-save your test sequence using the Save Setup button.

Note: you can repeat steps 3-6 to make as many changes as you need to make.
Just remember –

  1. Highlight the test step you want to modify
  2. Make your changes on the Test Setup and/or Advanced Options tabs
  3. Click Modify Current Test Step to save your changes to each test step
  4. Re-save your test sequence when you’re done

 

AME (Automated Manufacturing Engine) coming soon!

Automated Manufacturing Engine (AME)We’ll be releasing more information in the coming months about our new Automated Manufacturing Engine (AME). The new AME Module will be a go/no-go type testing tool geared toward burn-in and Contract Manufacturers (CMs) with multi-drive testing capability with a fail-proof testing approach.

Be sure to visit our website often and if you’re interested in beta testing, please contact sales and let them know you’re willing to offer feedback on this great new module!

 

 

Receiving your Performa upgrade emails?

Performa EmailsTo make sure you are running the latest version of the STB Suite and are notified ASAP on the new releases be sure to follow the outline below.

  1. Purchase the STB Suite, it comes with one year of Performa
  2. Maintain the license with the Performa program
    1. Be sure to keep your Technical Contact information updated with STB so you receive the latest emails regarding new releases.
      1. Email – This is very important and we would recommend using a technical support distribution email address so it is visible by more than one person to avoid accidental deletions, junk mail filtering, or just missing the “Official Performa” emails.
      2. Name
      3. Company
      4. Phone
  3. Have your testing teams or technical co-workers sign-up for the STB Suite Monthly newsletter so they can see what’s coming, what’s new and not miss out on any special promotions or announcements for the STB Suite. Please note if you sign-up for the newsletter you will receive a follow-up email that requires a confirmation. If you don’t receive that email then your company mail server is blocking @scsitoolbox.com and/or @stbsuite.com.

If you’re not sure who your technical contact is for your license(s) or have any questions contact STB today!