Renaming Command Deadlines (14-107)
Ballard, Curtis C (HP Storage)
curtis.ballard at hp.com
Fri Oct 17 08:43:05 PDT 2014
Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1410172_f.htm">HTML-formatted message</a>
I really donât link deadline. A deadline is a fixed point in time when
something has to be done. It isnât a limit on how long something can take.
Websterâs defines deadline as: âa date or time before which something
must be doneâ
Several people have interpreted this to be creating a method where the system
can provide a timestamp for when the command must be complete and while there
is a definition that says otherwise, a frequent misinterpretation makes
implementation and acceptance more difficult.
I like âCommand processing time limitâ because that describes exactly
what this is in plain language without having to refer to a definition. This
is setting a limit on the amount of time the device server can spend
processing the command. If that is too long âCommand time limitâ is
further away from âcommand processing timeoutâ and shorter.
Paulâs proposal of âCommand duration limitâ isnât too bad.
A possible alternative with a nod to the SAM state machine might be
âCommand enabled time limitâ or âCommand enabled limitâ.
+1 970 898 3013 / Tel
Curtis.Ballard at hp.com / Email
Fort Collins, CO
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Gerry Houlder
Sent: Friday, October 17, 2014 8:21 AM
To: T10 Reflector
Subject: Re: Renaming Command Deadlines (14-107)
My first choice is to keep the "command deadline" label. We have a
definitions section to describe exactly what we mean.
If that option fails, my second choice is "command time limit". Time limit is
an acknowledged synonym for deadline. Again, if folks need more clarification
than that, read the definition of the term.
On Thu, Oct 16, 2014 at 6:54 PM, Paul Suhler
<Paul.Suhler at hgst.com> wrote:
At Tuesdayâs SAM-5 call, I received a recommendation not to use the term
âcommand deadline timeâ because that implied an absolute wall clock time,
rather than a duration that begins when the command is received by the device
One suggestion was âcommand processing time limit.â This could be
confusing because itâs too close to âcommand processing timeout,â which
is in SPC-4 and is a totally different concept; see the command timeouts
descriptor in REPORT SUPPORTED OPCODES. Moreover, âtime limitâ could
also imply a wall clock time.
Another objection I have is that Iâd be replacing three words with four and
this proposal is wordy enough already.
a) Command duration limit (Do we *have* to say âprocessingâ â can
it be implicit?)
b) Command lifetime limit
Paul A. Suhler, PhD
Research Staff Member
paul.suhler at hgst.com
o: 949-476-1180 x275448<tel:949-476-1180%20x275448>
3001 Daimler St.
Santa Ana, CA 92705-5812
More information about the T10