Fw: 96-277r1 - Proposed Change in QErr for SPC-2

Gerry Houlder Gerry_Houlder at notes.seagate.com
Thu Feb 27 11:19:56 PST 1997

* From the SCSI Reflector (scsi at symbios.com), posted by:
* Gerry Houlder <Gerry_Houlder at notes.seagate.com>
I agree that Ed's recap of the written record is useful. However, I have 
recollections of things that weren't written that have influenced this 
proposal. These things have been forgotten
until recently.

(1) Jim McGrath (the one from Quantum) originally proposed basic queuing. His 
original proposal was outlined on an overhead in front of the working group and 
there was about a half hour of discussion in which Jim didn't get much support 
for the idea. After the Working Group was adjourned, Jim conducted an in depth 
discussion (another hour or more) of what he wanted and why. This was a small 
group (5-8 people) and anyone that attended had no doubt that the proposal was 
intended for single initiator systems and "legacy" applications.
There was considerable discussion about clearing queued commands. The QERR=1 
response of "clearing all commands" was deemed critical to the "simplified" 
(meaning substantially less drive firmware) proposal. He also wanted to have 
ABORT required instead of CLEAR QUEUE because it is used in legacy driver 
software. The ABORT message has a heritage going all the way back to systems 
without arbitration or with only single bit selection (clearly single initiator 
systems). CLEAR QUEUE is a more recent addition to SCSI and is less used by 
driver software. The fact that the drive was actually going to do a CLEAR QUEUE 
in response to this message was deemed unimportant because "the result is the 
same for single initiator systems anyway".

(2) Pete Dougherty became champion and author of the official proposal. I 
presume this was because Jim knew he would not be attending the next few X3T10 
meetings and was happy to find a champion that was going to attend.

Pete started with 3 levels of queuing support, which was trimmed to two levels 
by popular acclamation. Pete removed the single initiator restriction/ 
recommendation because he felt (as do others) that the flush all commands in 
multi-initiator system is a manageable problem. He felt strongly about it and 
the rest of us went along with his opinion. After all, it was his proposal.

What all of us forgot about was the nuance of CLEAR TASK SET operation versus 
ABORT TASK SET operation. This nuance becomes a significant difference when 
basic queuing is applied to multi-initiator systems. I think it was ignored 
because a lot of people (including me) remembered Jim's emphatic arguments 
about basic queuing applying to single initiator systems even though that 
wording was no longer in Pete's proposal.

(3) That brings us to today. Ralph's proposal is a great fix for using the 
"clear other commands on CHECK CONDITION" feature in a multi-initiator system. 
If a multi-initiator system really wants to do this, OK. I support Ralph's 
proposal on that basis.

I want to see a clearer statement from Ralph (i.e., Symbios)  on what he 
expects to gain from this. Will a drive that supports this desired 
configuration be cheaper than a drive that does full queuing and QERR=0? It 
will not be. The new basic queuing definition is not available on any drive 
today. A drive implementing this definition will be a "full queuing" capable 
drive that has a few more lines of code to do the new QERR=11 function. This 
will not be cheaper or more reliable than using an existing "full queuing" 
drive with QERR=0.

If Ralph really wants the "clear other commands on CHECK CONDITION" feature in 
a multi-initiator system and he doesn't care if the drive cost the same as 
current full featured drives and won't be available for several more months, 
then accepting the proposal will give him what he wants.

Also note that, if we accept this proposal, Jim's cheaper "simple queuing" 
drive (with the functionality outlined in item (1) above) will not be usable by 
Ralph. This is problem 1. Can Symbios live with this?

Jim will not have a description of his "simple queuing" drive in SAM like he 
wanted. This is problem 2. The "basic queuing" description will have evolved 
into something with much more firmware complexity than what he wanted. Jim 
might be willing to live with this. I recall early statements from him that he 
wanted a description of "simple queuing" in the standard, but he would produce 
it as a de facto standard product if he had to. I think we will hear more about 
this from Jim.

Speaking for Seagate, I don't know of any implementation planned that matches 
Jim's simple queuing. All of our SCSI products support the full queuing 
functionality, even the cheaper "XL" drives that do have reduced features. My 
company doesn't have much of a stake in the outcome of this debate, but the 
whole basic queuing concept seems to be causing MORE fragmentation and 
complexity instead of less.

Our industry would be better off if we all decided that full queuing is 
mandatory, only the ACA tag stuff and supporting more than one value for the 
QERR field is optional, instead of trying to draw a line and say that a lower 
functionality is also valid. There seem to be too many different places to draw 
lines. Too many options in this area can lead to reduced reliability!

I hope Symbios is being very careful about what they are asking for, because 
they probably will get it.
* For SCSI Reflector information, send a message with
* 'info scsi' (no quotes) in the message body to majordomo at symbios.com

More information about the T10 mailing list