Command Deadlines: HP's Modest Proposal

Ballard, Curtis C (HP Storage) curtis.ballard at
Wed Sep 3 17:15:46 PDT 2014

Attachment #1: <a href="">nameless-3208-2-1.html</a>

The total number of timeout values shouldn’t need to be any more than the
current proposal which defines 30 timeout values per I_T nexus.  The device
server could define a set of commands where timers are supported and could
have a maximum number of timers.  Instead of timers being associated with a
priority they would be associated with specific commands.  Most applications
will have a small set of commands where they want to use deadlines.

As we discussed in the last conference call, these timeout values don’t
have to map to timers.	The model is taking the command arrival time and
adding the timeout to generate a command deadline and the device server
checks the current time against the deadline rather than running a timer.

This model doesn’t provide as much flexibility for the application as being
able to pick from a table of timers for every command but can work with the
existing CDB’s without needing to use the transport specific command
priority.  If more flexibility is needed 2 bits in the control byte could
allow selecting from one of 4 timeout values.

Curtis Ballard


From: owner-t10 at<mailto:owner-t10 at> [mailto:owner-t10 at]
On Behalf Of George Penokie

Sent: Wednesday, September 3, 2014 4:19 PM

To: Paul Suhler

Cc: T10 E-mail Reflector (t10 at<mailto:t10 at>)

Subject: Re: Command Deadlines: HP's Modest Proposal


One timeout per opcode per I_T_L nexus sounds like one heck of a lot of
timers to me.

Bye for now,

George Penokie

Avago Technologies

Attn: George Penokie

4109 Manor View Dr NW

Rochester , MN 55901


george.penokie at

On Wed, Sep 3, 2014 at 4:30 PM, Paul Suhler
<Paul.Suhler at> wrote:

Hi, all.

Curtis Ballard has made an interesting suggestion for a major change to last
week’s T10/14-107r2:

Instead of providing two sets of fifteen timeouts, one timeout would be
provided per-opcode-per-I_T_L nexus.  That timeout would be used if a
newly-allocated bit in the CDB’s Control byte were set.


No need to wait for the Command Priority attribute to be added to transport
implementations and to driver stacks, which could take years.


In cases where an initiator wants to change the timeout for  a particular
command (e.g., READ(16)) on a particular LU, it would have to send a MODE


1)	Does anyone feel that one timeout per opcode per I_T_L nexus is too
much of a constraint?  HP doesn’t.

2)	Does anyone object to using mode pages, with the requirement that the
data length on MODE SELECT must match the data length on MODE SENSE?  (The
alternative is yet another command.)

Thanks for your feedback,


Paul A. Suhler, PhD

Research Staff Member

HGST Research

paul.suhler at

o: 949-476-1180 x275448<tel:949-476-1180%20x275448>

m: 949-241-6443<tel:949-241-6443>

3001 Daimler St.

Santa Ana, CA 92705-5812<<a href="">;

More information about the T10 mailing list