Skip to main content

Errors

The Errors section provides a high level indication of presence of errors, and once you expand on the Errors section, you will see the Alerts Summary which gives a total count of each error type, along with an Error Inspector for each error type that provides detailed reporting of the reported error in this Workload run instance.

Alerts Summary

The Alerts Summary provides a breakdown of the different errors observed, and the total count of each error. The Alerts Summary table is organized in an OSI-like stack, where the upper layer protocol (e.g. SMB) is at the top of the table, followed by TCP, and so on. At a quick glance, you can quickly get a sense of where the errors are.

For example, if you see no SMB errors and no MAC/VLAN errors, but see a lot of TCP Connection errors, then that is a good indication that there is a TCP transport layer issue or IP networking layer issue, preventing the SMB clients from starting from an SMB protocol perspective. Or vice versa, if you see a high number of SMB errors but few TCP errors, then that is a good indication that the TCP/IP layers are generally ok, but the SUT is not performing so well at the SMB layer.

2019-11-15_12-17-48.png

Error Inspector

The Error Inspector is a deep error reporting feature that tells you when an error occurred, who was involved, where in the System Under Test the error occurred, what error codes are reported, and more. Here is an example for FC-SCSI.

FC-SCSI example:

2019-11-15_12-28-08.png

We see that the workload run found the following: Essentially, this is a hierarchy of error types and counts observed, and you can think of it in the following structure. Future releases of WorkloadWisdom will improve the layout of this view.

  • 208 FC-SCSI Workload Actions (for the most part, Actions are Commands) encountered errors

  • 100 were Read Action errors

  • 108 were Write Action errors

  • The CHECK CONDITION error was observed 208 times

Essentially, this is a hierarchy of error types and counts observed, and you can think of it in the following structure. Future releases of WorkloadWisdom will improve the layout of this view.

In the right column, a detailed reporting of the error code is shown.

  • Timestamp: The relative test timestamp when this occurrence of the error was observed (test start time has a timestamp of 0).

  • Error type: The types of Errors listed in the middle column that this occurrence of the error contributed to.

  • Scenario name: This is mainly for Support use and is not generally visible / meaningful to WorkloadWisdom users. However, if you use TDE as well, then you can see this Scenario name when you export the Workload Test Run and opens it from TDE.

  • Time: This is the Unix Epoch time that corresponds to the Timestamp above.

  • FC Initiator / Target: This is the Initiator WWPN and Target WWPN found in the SCSI message that contains the reported CHECK CONDITION.

  • FC Alert: This is the command that triggered the error from a SCSI protocol perspective.

  • Sense information: These are the SCSI error codes that are found in the SCSI message that contains the reported error.

  • Action Completion Status: This is mainly for Support use, and is not generally visible / meaningful to WorkloadWisdom users.

  • Scenario Impact: By default this is always TERMINATE. However, if the workload supports the Ignore errors gracefully option and you have selected the checkbox, then this will report CONTINUE, which means that even though an error was encountered, you wanted the workload to continue to run.

  • Scenario Action Index: This is mainly for Support use, and is not generally visible / meaningful to WorkloadWisdom users. However, if you use TDE as well, then you can use this information to find out the exact Action (Command) in the workload Scenario by this index number, as every Action in a Scenario in TDE has a unique index number.

  • SCSI Write Total Size / Bytes information: This tells you the attempted total size of the Write command, and exactly how far into the Write (i.e. offset) when the error was reported.

Different protocols offer different levels of details based on what is available from a protocol’s error reporting that is observable in a packet on the wire. For example, Error Inspector for iSCSI includes information about sequence numbers found in the iSCSI conversation where the error was reported, and for File protocols like SMB, Error Inspector provides information about the Share and Filename where the error was reported.

For performance reasons, the number of unique error occurrence records stored is the first 100 occurrences of each error type (i.e. error category in the middle column).

Legacy Errors Summary (Workload Test Runs before 6.4)

The Errors Summary section provides a high level indication of errors, as well as accounting of per-command type errors encountered in this Workload run instance.

Two types of errors are reported: fails and aborts. Once expanded, the number of fails and aborts are provided for each statistic.

2019-11-15_12-34-20.png

There are cases where 1 error encounter can be effectively registered multiple times.

For example, during the workload run instance, 1 CDB Test Unit Ready request encountered an error, therefore the CDB Test Unit Ready command registered 1 error. At the same time, the CDB Test Unit Ready command is considered a SCSI IO command. Therefore, the SCSI IO error is also registered.

To access the detail errors encountered, navigate the charts in the All Charts section.