Command Queuing and SAM
Ralph Weber -- VMS -- ZKO3-4/U14
weber at star.enet.dec.com
Tue Feb 15 15:52:38 PST 1994
>"Jim McGrath" 9-FEB-1994 15:33:47.88
>To: SCSI at WichitaKS.NCR.COM
>Subj: Command Queuing and SAM
> Subject: Time: 2:55 PM
> OFFICE MEMO Command Queuing and SAM Date: 2/8/94
>Is it required by SAM that any SCSI protocol support all of the traditional
>queuing functions (e.g. head of queue, ordered, abort, clear queue, etc...).?
>It would be a goodness if only unordered queuing and some abort function
>(reset anyone) be required.
>The reason I am opening this is because of ATA command queuing, where I want
>to develop a very simple solution. Functions other than unordered are either
>useless or can be emulated by the host (i.e. just send down commands one at a
>time for ordered commands). This simplification should help in making
>queuing easier for ATA implementations.
>Feedback is appreciated.
I am of two minds about this.
For the specific needs of my operating system (OpenVMS), the need for queuing
functions other than unordered occur only in the multi-initiator cases. So,
if ATAPI is limited to single initator configurations, then ATAPI disks that
only do unordered tagged operations are ok. Conversely, if ATAPI drives are
complex enough to do multi-initiator support right, then why should a little
more queuing firmware matter?
However, I find the "just send down commands one at a time" concept has
appalling performance implications. Any system that frequently uses ordered
commands as a synchronization tool will find itself in single-step mode nearly
all the time. Then, the question becomes, "Why pay for queuing at all?"
I do not much care which set of cleanup functions you support (abort, clear
queue, etc.). My experience says that the QErr bit in the Control mode page
is the heart of all interesting cleanup models. Make sure that QErr works for
both 0 and 1 settings, give me a BUS DEVICE RESET equivalent, and I will be
More information about the T10