Mulit-Initiator Task Set (Queue) Full vs Busy responses.

[dallas at zk3.dec.com]

* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* dallas at zk3.dec.com
*


Folks,

I have to agree with Ralph and Gerry on this issue.  QUEUE FULL 
does not set fixed-for-all-time upper limit for the device. 

An OS may develop any type queue depth implementation that they 
want, but don't change the rules for other OSs that have developed
floating queue depth mechanisms.  The Compaq/Digital UNIX OS
implemented a fully dynamic adjusting queue depth per device 
algorithm.  OSs/drivers should implement dynamic mechanisms to 
handle the dynamic nature of I/O devices in todays market, but
it also depends upon the OS's target market. 

Wasn't this topic brought up about 3 years ago and shot down.

Thanks
Bill

------- Replied-To Message

Date: Sat, 27 Jun 1998 00:11:02 EDT
From: roweber%acm.org at 2.1001.enet.dec.com (MAIL-11 Daemon)
  To: -T10 Reflector <T10 at symbios.com>
  cc: "Houlder, Gerry" <Gerry_Houlder at notes.seagate.com>,
      "Ericson, George" <gericson at clariion.com>
Subj: RE: Mulit-Initiator Task Set (Queue) Full vs Busy responses.

* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* "Ralph O. Weber" <ralphoweber at csi.com>
*
I am adamantly opposed to the proposed changes in the definition of
QUEUE FULL status.

The current SCSI definition of QUEUE FULL is correct.  It is correct
because it is open-ended, allowing a variety of implementations and
any enhancements to current implementations a future of invention
might hold.

The proposal to restrict the definition of QUEUE FULL to "you've hit
the fixed-for-all-time upper limit" is wrong.  It would constrain
current implementations in all the ways that Gerry Houlder has
described.  Worse still, it would prohibit an innovative company from
building a better SCSI device.

The fact that some system implementations are already constrained in
the same way that the proposed change is constrained cannot justify
the proposed change to the SCSI standards.

Firstly, the existence of even one system that is implemented
correctly (in a manner that fully utilizes the current SCSI
definition) is sufficient cause to maintain the current definition. 
Since I am aware of at least one such system and suspect the existence
of a couple more, T10 is obligated to the SCSI community to make no
changes that break properly designed high-performance systems.

Secondly, the current implementations that assume QUEUE FULL sets a
fixed boundary are relying on other information to know that this
design decision is correct (or at least adequate), or the
implementations are flat-out wrong.  If the design is wrong and if
that mistake produces a noticeable adverse effect on the system
performance experienced by the system's user community, then the
developers of that system will find themselves encouraged to implement
proper support.

BTW As I understand it, the NT sharing model is share-nothing.  This
means that at any given instant, only one processing unit will be
performing I/O operations on any given disk.  This fundamental
clustering model assumption can justify a design decision to assume
that QUEUE FULL sets an upper bound on queued requests, if in fact
that is the NT assumption.

Because of the share-nothing model, the processor that gets QUEUE FULL
knows that no other processors are consuming device resources.  To a
first approximation, receipt of a QUEUE FULL does indicate that device
resources have been exhausted by the number of outstanding requests. 
There are, of course, secondary effects that might cause the QUEUE
FULL boundary to move, even for a single processor.  However, a
reasonable person might find it justifiable for the NT developers to
choose to ignore such secondary effects in their initial cluster
software versions.

Symbios opposes the proposed restrictions on the definition of QUEUE
FULL.

Thanks.

Ralph...




*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at symbios.com

% ====== Internet headers and postmarks ======
% Received: from mail13.digital.com by us2rmc.zko.dec.com (5.65/rmc-22feb94) id
   AA24447; Sat, 27 Jun 98 00:08:07 -0400
% Received: from mpdgw2.symbios.com (mpdgw2.symbios.com [204.131.200.2]) by mai
  l13.digital.com (8.8.8/8.8.8/WV1.0f) with SMTP id AAA10611 for <Dallas at wasted
  .enet.dec.com>; Sat, 27 Jun 1998 00:08:06 -0400 (EDT)
% Received: (from root at localhost) by mpdgw2.symbios.com (8.6.8.1/8.6.6) id WAA0
  9110; Fri, 26 Jun 1998 22:05:07 -0600
% Received: from aztec.co.symbios.com(153.72.199.214) by mpdgw2.symbios.com via
   smap (V1.3) id sma009082; Fri Jun 26 22:04:49 1998
% Received: (from majordom at localhost) by Symbios.COM (8.6.8.1/8.6.6) id WAA1392
  8 for t10-outgoing; Fri, 26 Jun 1998 22:04:38 -0600
% Received: from mpdgw2.symbios.com (bastion.symbios.com [204.131.201.2]) by Sy
  mbios.COM (8.6.8.1/8.6.6) with ESMTP id WAA13923 for <t10 at symbios.com>; Fri, 
  26 Jun 1998 22:04:36 -0600
% Received: (from root at localhost) by mpdgw2.symbios.com (8.6.8.1/8.6.6) id WAA0
  9062 for <t10 at symbios.com>; Fri, 26 Jun 1998 22:04:36 -0600
% Received: from smtp4.site1.csi.com(149.174.183.73) by mpdgw2.symbios.com via 
  smap (V1.3) id sma009054; Fri Jun 26 22:04:30 1998
% Received: from mail pickup service by csi.com with Microsoft SMTPSVC; Sat, 27
   Jun 1998 00:04:28 -0400
% Received: from localhost (hdn87-145.hil.compuserve.com [206.175.97.145]) by h
  il-img-ims-4.compuserve.com (8.8.6/8.8.6/IMS-1.3) with SMTP id AAA13346; Sat,
   27 Jun 1998 00:04:11 -0400 (EDT)
% Date: Sat, 27 Jun 1998 00:04:11 -0400 (EDT)
% Message-Id: <199806270404.AAA13346 at hil-img-ims-4.compuserve.com>
% To: -T10 Reflector <T10 at Symbios.COM>
% Subject: RE: Mulit-Initiator Task Set (Queue) Full vs Busy responses.
% Cc: "Houlder, Gerry" <Gerry_Houlder at notes.seagate.com>, "Ericson, George" <ge
  ricson at clariion.com>
% From: "Ralph O. Weber" <ralphoweber at csi.com>
% Reply-To: roweber at acm.org
% X-Mailer: PROCOMM PLUS 3.0 for Windows
% Mime-Version: 1.0
% Content-Type: Text/Plain; charset=US-ASCII
% Sender: owner-t10 at Symbios.COM
% Precedence: bulk

------- End of Replied-To Message
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at symbios.com