BAM – In the Scripting Environment

STB Suite | The Industry Standard in Peripheral Testing.

Introduction

BAM (Bus Analyzer Module) is a software-based protocol or bus analyzer which is included in the STB Suite.

BAM can capture and display all I/O to or from any device(s) on your test system. It works with SAS/SCSI/FC, SATA, and USB interfaces.

A few key points which we will address here are:

·         ease of use

·         quick setup

·         how to confirm your Script is doing what you think it should

 

 

Setting up BAM

Getting started with BAM is very easy – just

1. Start BAM

using the desktop BAM Icon –

Figure 1 – BAM icon

Figure 2-BAM Main Screen

Select the drive(s) to monitor

Click on the Disk Drive icon on BAMs toolbar to select the drives you wish to monitor.

 

 

Select the Phases to capture

Click on the Gear icon on the toolbar to select the phase types you wish to capture. The defaults should be fine for capturing SAS/SCSI/FC traffic – here is the suggested setting:

Figure 3 – Add/Remove Phases

Set your capture size

Use the Data Size field to specify how much data per I/O you wish to capture. The default for this field is 512. If you are going to be capturing more than 512 bytes per I/O, for example if you are going to capture MODE SENSE data that is 2048 bytes long just enter 2048 in the Data Size.

Start your capture

Click on the Green Arrow on the toolbar to start the capture.

Stop the capture

Just click the red Stop sign icon to stop the capture

Look at your trace

All of your captured I/O is shown in the scrollable center section of BAM.

Save your trace

You can save your trace in either BAM format (so you can reload it and use BAMs analysis tools) or in a .csv format for display via a spreadsheet program. Use the BAM File-Save Raw Data or File-Save to Excel file

 

 

A Build/Run Script Example

For this example we defined a Script which does:

1. an INQUIRY CDB which saves the INQ data to a file

2. a Sequential Write test, starting at LBA 0 and running through LBA 100,000

3. a WRITE CDB which uses the INQUIRY data from step 1 as the DATA OUT payload. We are trying to set this CDB up to use the Increment LBA feature of the User Defined CDB – here is the CDB setup

Figure 4 – Definition of WRITE CDB

Note – the CDB initially specifies LBA 0, and we have set up to repeat sending the CDB four times, each time incrementing the LBA fields in the CDB by 1.

Now we will use BAM to confirm that all of that worked as we expected it to.

Capture the I/O with BAM

Use the simple steps above to start BAM, select your drive, and start the trace capture. Then run your script from the STB Suite. When the script finishes click on the BAM red Stop sign to stop the capture

 

 

Examine the sequence of WRITE CDBs

As you can see, we did get four WRITE CDBs issued, and in fact the LBA field was incremented by one for each CDB.

Figure 5 – BAM trace showing WRITEs

Examine the data

Click on any of the Data phases associated with any of the WRITE CDBs, then click on the Raw Data tab to see that CDBs data phase data

You can use the Buffer/Edit Functions to save this data off to a file, etc.

 

 

More BAM data

BAM can also show you all CDBs which were issued during the capture. Click on the  I/O Statistics tab to see a summary of CDBs, their frequency, and performance metrics

Who sent this I/O?

Sometimes it can be valuable to know where every I/O came from. For instance, you may notice that there are CDBs being issued which aren’t coming from your script. An example of this could be a background utility which occasionally checks the status of a drive.

To see where an I/O comes from just look back at the center trace data area. The column on the far right shows what driver issued the I/O.

Figure 6 – source of I/O

Note, in our example all I/O was issued by the STB Suite driver STBTrace. You may see other I/O from PlugAndPlay, or from other sources. Knowing who issued an I/O can save hours of head scratching troubleshooting.

Summary

BAM is an invaluable tool when doing any type of user defined or customized work with the STB Suite. It is easy to use, quick to set up, and super versatile. In addition to this simple introduction BAMhas many other features, such as being able to search through the trace data, being able to view queued command/data pairs either by nexus or in time-order. You can screen (ignore) user specified CDBs, or ignore all I/O from a given driver source.

BAM is a valuable time saver – perfect to 100% confirm that your script is doing exactly what you think it is doing.

BTW – BAM can capture any I/O on your system – it is not limited to capturing STB-created I/O. If you have a utility from a vendor or other source you can use BAM to capture and analyze exactly what any source of I/O is doing.

BAM Benefits & comparison

What is the cost of a SAS protocol analyzer? Or a Fibre Channel? Or SATA?

BAM is included in the STB Suite – no additional charge!

What happens when a new interface spec appears?

Can other expensive hardware tools work with 6G? 12G? 24G? BAM will.

What if your lab has 10 people working, needing to capture I/O? How much would 10 hardware analyzers cost? BAM is part of the STB Suite, so every engineer has access to it – all the time.