SPC-4: Self Describing Command Timeouts (05-284r2)

Kevin D Butt kdbutt at us.ibm.com
Sun Aug 6 14:24:28 PDT 2006


Formatted message: <A HREF="r0608061_f.htm">HTML-formatted message</A>

Pat,
Thanks for the response.  It sounds like, for your interests, the main 
delays are at the host side and not in the device queue(s).  In SCSI 
terms, the host queue is still considered part of the application client 
(as I understand it) and therefore not something that I can address.  So I 
agree that from the host perspective the time from Command Out to Status 
In is what it has to work with.  On the other hand, target devices only 
have the time from receipt of the command to the time the status is sent. 
The difference in these times is whatever bus delays there are.  However, 
since the Command Timeout values are in units of seconds, I believe that 
the bus/fabric delay time is negligible.
With this in mind, I am trying to concentrate my efforts on providing a 
Command Timeout value from receipt of the command to the sending of the 
status.  My proposal currently does not take into consideration any time 
that a command might sit in the target device queue prior to entering the 
enabled task state.
My proposal covers the issues from when the command enters the enabled 
task state to when it enters the task ended state.  The sense that I had 
when the previous version was discussed in CAP is that I will have a 
difficult time getting this passed without somehow addressing the time 
spent in the queue waiting to enter the enabled task state (i.e. when the 
command is in the dormant task state).
The only ways I have thought of that might work are to use a Task 
Management function like query task and attach a timout to the return 
status (if that is even possible in the SCSI architecture).  However, this 
does not meet the goal of the proposal.  The goal of the proposal is to 
have a method that allows an application to call an API from the device 
driver and provide a timeout value for the completion of that command. 
This requires an a priori knowledge of how long that command will take.
Thanks,
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com
http://www-03.ibm.com/servers/storage/ 
Pat LaVarre <p.lavarre at ieee.org> 
08/06/2006 07:25 AM
To
Kevin D Butt/Tucson/IBM at IBMUS
cc
Subject
RE: SPC-4: Self Describing Command Timeouts (05-284r2)
Kevin,
Clear explanation of how Reservations help Tape devices, thank you.
 > The delay injected by ... the command(s) in the queue
 > prior to this one) do not often have an effect on the host doing 
data I/O.
Yes.  For Disk and all the more for Dvd/cd devices, in my low-end 
commodity peripheral world, the cache & queues are mostly in the 
host, not in the device.  The write cache in the host can be huge, 
even as large as the device, and not aggressively flushed.  If an 
early write request stumbles across a difficult to write area, then 
that time delays all the remaining requests.  The only measurabe time 
that reliably fits within limits is the time from Command Out to 
Status In measured at the bus, not as measured at a level above the 
queue.
-----Original Message-----
From: owner-t10 at t10.org on behalf of Kevin D Butt
Sent: Sat 8/5/2006 10:05 PM
To: t10 at t10.org
Subject: SPC-4: Self Describing Command Timeouts (05-284r2)
A new version of my "self-describing" command time-outs has been posted.
This is a major revision from the one posted last November.  I have a 
few
issues to solve that I would appreciate help with.  The main one 
being how
to sufficiently address or skirt the delay injected by the time in the
queue.
My thoughts and experience are in the tape realm, and I don't have a 
good
feel for disk or enclosure or MMC.  In the tape realm, reservations are
often used to ensure that only one host is doing data I/O (or time
intensive activities) at a time.  While multiple host may be talking to
the drive, most are just polling to see if it is there or if it is
available (i.e. doesn't have an active reservation).  In this scenario,
the command time-outs as I have described them will solve a high
percentage of the issues related to unknown command time-outs.	The 
delay
injected by the queue (or the command(s) in the queue prior to this one)
do not often have an effect on the host doing data I/O.
Anyway, I need to understand better the issues seen by the other device
types.	I would also appreciate any suggestions.
2006/08/05 22:47:18
Your request to upload a file or files to the T10 site has been 
accepted.
Your PDF file will be posted at:
    http://www.t10.org/ftp/t10/document.05/05-284r2.pdf
Normally, the posting/archiving process takes about 30 minutes.
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com
http://www-03.ibm.com/servers/storage/



More information about the T10 mailing list