USB Attached SCSI (UAS) Best Practices for Windows 8 - 2

USB Attached SCSI (UAS) Best Practices for Windows 8 - 2

USB Attached SCSI (UAS) Best Practices for Windows 8

July 24, 2012

Abstract

This paper provides guidelines for the independent hardware vendor (IHV) for making USB Attached SCSI (UAS) devices operate and perform properly with Windows 8. Additionally, it covers the limitations of the Universal Serial Bus (USB) Bulk-Only Transport (BOT) in mass storage devices. Also, it offers guidance for IHVs and original equipment manufacturers (OEMs) to implement the UAS protocol in their next generation of mass storage devices.

This paper assumes that the reader is familiar with:

·  The official USB Attached SCSI Protocol specification (see Mass Storage)

·  The official T10 USB Attached SCSI (uas-r04) specification

·  The Windows SCSI compliance tests as described in the blog post, USB Mass Storage and Compliance

This information applies to the following operating systems:

Windows 8

References and resources discussed here are listed at the end of this paper.

The current version of this paper is maintained on the Web at:
USB Attached SCSI (UAS) Best Practices for Windows 8

Disclaimer: This document is provided “as-is”. Information and views expressed in this document, including URL and other Internet website references, may change without notice. Some information relates to pre-released product which may be substantially modified before it’s commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here. You bear the risk of using it.

Some examples depicted herein are provided for illustration only and are fictitious.No real association or connection is intended or should be inferred.

This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes.

© 2012 Microsoft. All rights reserved.

Document History

Contents

Introduction 3

Limitations of BOT 3

Overview of UAS 3

What is UAS? 3

Key benefits of UAS 3

Implementation Guidelines 3

Command Queuing 4

Cache Policy 4

SCSI Compliance 4

Common Hardware Problems with UAS Implementation 4

Device Timeouts 4

Device Retries 5

UAS support on USB2.0 6

Troubleshooting Tips 7

Enable trace logging 7

Configuring transfer size 7

Conclusion 8

Resources 8

Introduction

Windows 8 natively supports the UAS transport that was preceded by the Bulk-Only Transport (BOT) protocol. The UAS protocol was created to overcome some of the limitations of the BOT protocol.

Limitations of BOT

The BOT specification defines a simple mechanism for transferring input/output (IO) between a host and a device. The IO transfer is sequential in nature; the host sends a command and waits for the device to complete the command before sending another command. The transfer sequence is two or three phase: command, data (optional), and status. While the device is processing one of the phases, the host is not allowed to send any other commands. This increases the turnaround time between commands, thereby limiting the bus utilization and lowering the Input/Output Operations per Seconds (IOPS).

Overview of UAS

UAS is the new mass storage protocol that uses standard SCSI commands to move data over a USB bus.

Key benefits of UAS

Overlapped Commands

UAS allows the host to send more than one command at a time, allowing the device and host to overlap command processing with data transfers.

Out-of-Order Completion

Unlike the BOT transport, which has only two pipes (Bulk-In and Bulk-Out), UAS supports four pipes (Command, Bulk-In, Bulk-Out, and Status). This allows the host to send more than one command at a time while the device is still processing the previous command. The host and device keep track of commands sent and received through a tagging mechanism, enabling seamless out-of-order command completion and data transfer scheduling by the device.

Windows 8 supports UAS over both EHCI and XHCI. The XCHI interface supports a new USB3.0 feature called Streams. The Streams feature enables data flow management at the hardware layer by eliminating CPU cycles and conserving interrupts on host.

Compliance

The UAS specification is compliant with T10 SAM4. In addition, having USB-IF DWG compliance ensures more robust device-host interoperability as the ecosystem evolves.

Implementation Guidelines

The following guidelines help to ensure that the device is built to perform better with Windows 8.

Command Queuing

UAS support for overlapped commands requires the host and device to have adequate resources available for buffering and completing any request it receives. In order for the host and device to operate under optimally, the device must implement the following requirements:

1. Set CmdQue bit in a standard SCSI INQUIRY command (SPC4, section 6.4.2).
2. Support the command queuing mechanism as appropriate to backend storage. For example, support NCQ if the backend store is SATA.

3.  Report the number of streams in an interface companion descriptor; this is equal to the queue depth as supported by the backend storage.

Cache Policy

UAS is about performance, delivering both high throughput and better IOPS. Taking this into consideration, it is critical that both the device and host support appropriate caching policies. Traditionally, Windows configures any hot pluggable device for Surprise Removal over Performance. Therefore, it is critical for the device to report the correct caching policy to the system to ensure that Windows can configure the device for Performance versus Surprise Removal. Windows needs to ensure that it can flush the host cache periodically. To support this scenario, the device must implement the following requirements.

1. Report RMB=0, unless the media is truly removable.
2. Report its write cache policy through caching mode page (0x08).
3. Support configuration of the cache policy through mode select.

SCSI Compliance

SCSI compliance requires that the following conditions are met:

1. Have the unique serial number for the device regardless of how the device is connected to system.
2. Ensure inquiry data responses are quad aligned (multiple of 4).
3. Support SPC4 and SBC3 version descriptors.
4. Support Synchronize Cache and Start Stop unit commands for exercising selective suspend functionality.

Common Hardware Problems with UAS Implementation

Device Timeouts

Idle Device

When all LUNs on a device are idle, the device is selectively suspended. The disk idle system power setting governs the idle timeout period. To avoid issues with timeout periods that are too short, the minimum allowed idle timeout for UASP devices has a floor of 15 seconds.

Command Execution

Storport considers a UASP device to be operating nominally if it completes commands within the given maximum 15 second time period. However, if this timeout is exceeded for any command, a device error condition is assumed and the hierarchical reset process is set into motion. Starting with RESET LUN, Storport progresses through a series of increasingly forceful attempts to bring the device back to working condition until the device responds to one of these attempts with success. Subsequently, once the device is believed to be operational, if the command execution timeout is exceed again, the hierarchical reset process is re-applied.

The reset hierarchy and how these translate to UASP devices are as follows:

Device Retries

ACK NoStream

For bulk stream transfers, a device must be prepared to retry ERDY for an active UASP command whenever it receives an ACK NoStream response from the host. The best time to retry ERDY for the pending stream is when the host issues PRIME PIPE, informing the device that the endpoint buffer set has been modified.

Under certain transient conditions the device may receive an unexpected ACK NoStream from the host in response to ERDY. The known conditions where this can occur are:

1. On some XHCI controllers when PrimePipe is issued in close enough proximity to an ERDY from the device, the controller may issue an unnecessary NoStream ACK at the completion of the transfer.
2. Whenever a bulk stream transfer is canceled on the host, there is a small window of time during which the TRB ring is rebuilt. The device may be unaware of this condition and could possibly assert an ERDY for a streamID at a time when the TRB ring is not ready.

A bus trace captures an example of the second case that has occurred with a UAS device. Packet 54 is the SenseIU for a failed command on stream 3. As a result, the corresponding data transfer URB for stream 3 is canceled. Meanwhile, a TEST UNIT READY command on stream 2 is issued (packet 56) and completes successfully (packet 60). Because this command doesn’t require a data transfer, no ERDY is generated by the device. However, when another command is scheduled on stream 2 (packet 622), which does require data, the corresponding ERDY from the device arrives at a time when the TRB list for the DATA endpoint is not quite ready. This is a result of being rebuilt after cancellation of data transfer for stream 3.

Figure 1. Bulk Stream Cancel Trace

UAS support on USB2.0

To provide consistent user experience Windows 8 supports UAS over EHCI and loads UAS driver for a given UAS device connected across either EHCI or XHCI port. So it is recommended that the device be ready to support and service at the least 32 outstanding commands over EHCI.

Troubleshooting Tips

Enable trace logging

To help discover root cause issues in the UASPSTOR driver, the following instructions can be used to capture a trace log:

1. From an elevated command window, enter the following:

Logman start UASPSTOR -p {2430d0ce-fd18-4bc2-94d8-91a9596714a7} 0xFFFF 0xFF -o uaspstor.etl -ets -nb 128 640 -bs 128

1. Reproduce the issue.
2. Terminate the trace capture:

Logman stop UASPSTOR -ets

1. Finally run this command to capture the relevant system information:

msinfo32 /report sysinfo.txt

1. Upload or attach the resulting uaspstor.etl and sysinfo.txt files in any support or incident correspondence.

Configuring transfer size

The following registry key is used to set the maximum transfer length reported to the upper level drivers in the stack for a particular device. The default is 512KB if this value doesn't exist.

HKLM\System\CurrentControlSet\Enum\USB\<VID_PID>\<INSTANCE>\DeviceParameters

DWORD: "MaximumTransferLength"

Note that some device firmware will stop responding if values other than the default are used. Thorough testing may be required in order to ensure that a particular device can tolerate the increased transfer size.

Conclusion

IHVs can deliver the best UAS solution by making sure that their device stream implementation is matching NCQ and that their device complies with SCSI standards. Thereby, offering the customer the best possible experience with Windows and UAS devices.

Resources

USB Attached SCSI Protocol (UASP) v1.0

http://www.usb.org/developers/devclass_docs/uasp_1_0.zip

USB Attached SCSI Standard Specification (T10/2095-D Rev. 4)

http://www.t10.org/cgi-bin/ac.pl?t=f&f=uas-r04.pdf

July 24, 2012
© 2011 Microsoft. All rights reserved.