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@us.ibm.com
http://www-03.ibm.com/servers/storage/
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@t10.org on behalf of Kevin D Butt
Sent: Sat 8/5/2006 10:05 PM
To: t10@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.