Yet Another SAM-5 Command Timeout Subproposal for 14-107

Paul Suhler Paul.Suhler at
Fri May 30 10:58:13 PDT 2014

Formatted message: <a href="">HTML-formatted message</a>

Thanks, Gerry.	I’d overlooked the possibility of re-entering Dormant.
As far as other states, the timeout proposal only applies to commands with
the SIMPLE attribute.
From: owner-t10 at [mailto:owner-t10 at] On Behalf Of Gerry Houlder
Sent: Friday, May 30, 2014 10:52 AM
To: T10 Reflector
Subject: Re: Yet Another SAM-5 Command Timeout Subproposal for 14-107
Another side effect that may have to be considered -- a command may be
received, to to dormant state, to to enabled state, go back to dormant, go
back to enabled several times before it gets processed. You would only want
the transition from Idle to either dormant or enabled to set the timeout --
entering enabled from dormant or dormant from enabled should not recalculate
the timeout.
On Fri, May 30, 2014 at 12:42 PM, Gerry Houlder
<gerry.houlder at> wrote:
It seems reasonable to me that the arrival at the CS of a Queue Command
message (item c) is a good event to choose as the event that starts the
command timer, if any. The other events on your list could either be thought
of as 'zero time" or just not accounted for (e.g., part of the service
delivery delays that are not accounted for).
Note that entry into dormant state only accounts for Queue Command messages
received with simple or ordered attribute. You also have to account for Queue
Command message that are received with Head of Queue attribute and ACA
attribute (these go directly to Enabled state, so you need modifications here
to also set the timeout interval, if any).
On Fri, May 30, 2014 at 12:07 PM, Paul Suhler
<Paul.Suhler at> wrote:
It’s been suggested to me that the lack of a roar is because the lion
sleeps Wednesday night through Sunday night.
I’d like to check my understanding of 14-054r3 and how that affects my
My intent is that a command may time out any time after arrival and before it
first requests a data transfer.  In terms of T10/14-054r3, this corresponds
to command states LU_CS2:Dormant and LU_CS3:Enabled.  The expiration time is
computed when the command first arrives, as indicated by entry into
LU_CS2:Dormant; this assumes that four events take place essentially at the
same time, given adequate resources:
a)	      Arrival of the command at the SCSI Target Port.
b)	      Arrival at the TM of the SCSI Command Received message.
c)	      Arrival at the CS of the Queue Command message.
d)	      Entry into LU_CS2:Dormant.
Is that assumption correct?
I’d like not to introduce a new message.  Having specified in the model
section the conditions upon which a timeout happens, can I just specify in
the descriptions for LU_CS2 and LU_CS3 what happens when the timeout occurs? 
This would be analogous to the description of the LU_DS state, which
specifies what happens when an error occurs during command processing
Or is a message to those states necessary?
From: owner-t10 at<mailto:owner-t10 at>
[mailto:owner-t10 at<mailto:owner-t10 at>] On Behalf Of Paul Suhler
Sent: Thursday, May 29, 2014 9:31 AM
To: T10 E-mail Reflector (t10 at<mailto:t10 at>)
Subject: More: SAM-5 Command Timeout Subproposal for 14-107
Okay, that attempt to provoke the lions’ den did not evoke any roars, so it
must have been acceptable, n’est pas?  So, here’s another try:
The previously-posted revision specified when a command timeout occurs.  I
now propose to implement the timeout into the state machines by stating that
when a timeout occurs, the device server sends a (newly-defined) Time Out
Command message to the appropriate set of LU_CS states.  And I’ll define
the resulting behaviors.
From: owner-t10 at<mailto:owner-t10 at> [mailto:owner-t10 at]
On Behalf Of Paul Suhler
Sent: Wednesday, May 28, 2014 4:01 PM
To: T10 E-mail Reflector (t10 at<mailto:t10 at>)
Subject: SAM-5 Command Timeout Subproposal for 14-107
Hi, George (and anyone else who wishes to comment).
As suggested in CAP in May, I’m trying to leverage the new state machines
in 14-054 for defining the command deadline operations.  For example, in
order to record the arrival time of a command and set its expiration time, I
want to abandon adding an argument to the Route Command operation and instead
hang it on a newly-defined transition.	Using 14-054r3 as a base, I propose
to add the paragraph in blue: LU_CS1:Idle state LU_CS1:Idle state description
This is the initial state of the LU_CS state machine. Transition LU_CS1:Idle to LU_CS2:Dormant
This transition shall occur after receiving:
a) a Queue Command message with a Task Attribute argument set to Simple; or
b) a Queue Command message with a Task Attribute argument set to Ordered.
This transition shall include the following arguments:
a) I_T_L_Q Nexus;
b) CDB;
c) Task Attribute;
d) CRN, if any;
e) Command Priority, if any; and
f) First Burst Enabled, if any.
If this transition occurred after receiving a Queue Command message with a
Task Attribute set to simple, then the Deadline Expiration time attribute of
this command shall be set as specified in
The new subclause relies upon the proposed command deadline clock,
which is in the logical unit, and upon a command deadline value in the
proposed Command Deadline mode page.
Any problems with specifying this behavior here?  Other questions?
Paul A. Suhler, PhD
Research Staff Member
HGST Research
paul.suhler at
o: 949-476-1180 x275448
m: 949-241-6443
3001 Daimler St.
Santa Ana, CA 92705-5812<<a href="">;

More information about the T10 mailing list