software_concerns

dallas at zk3.dec.com dallas at zk3.dec.com
Wed May 1 14:41:07 PDT 1996


* From the SCSI Reflector, posted by:
* dallas at zk3.dec.com
*

Thank You for your reply.  I may not agree with your points and rational,
but I still value your discussion of the issues.

You ask the question "Do I have to be careful to avoid opening boxes
wrapped in brown paper that are postmarked as being from New
England?".  My answer would have to be no, you should give us software
bitheads a little more credit.  There are a number of subtle other ways
to make your life miserable!

All joking aside, the issue here is that I and other software implementors
think there is a real problem with the serial channel mappings and the
effect on our host software.

The network protocols recognized a need for deterministic models decades
ago and solved the problem.  People can argue about UDP (datagrams-class 3) 
and its un-deterministic model. In a UDP client (host) server (device) 
application they forget to mention the tons of software needed in the 
server to overcome the limitations of UDP (e.g., xFS response XID caches). 

Hmmmmmm Didn't GPP solve these issues?

Thanks
Bill

------- Replied-To Message

Date: Wed, 01 May 96 02:35:07 EDT
From: dal_allan%mcimail.com at us2rmc.enet.dec.com (Dal Allan)
  To: scsi at symbios.com
Subj: re:software_concerns

* From the SCSI Reflector, posted by:
* "Dal Allan" <dal_allan at mcimail.com>
*
Hi Bill,

At the risk of making myself very unpopular with a segment of the software 
community, you are describing a problem which was self-induced, and has been 
telegraphed for years. 

If you recall, back when Ordered tags were introduced, there was a small 
number of vocal opponents who argued that such behavior was unique to the 
parallel bus and any implementation which relied on Ordering would have to 
change at some time in the future. 

The future is here. 

Deterministic delivery of commands is a logical function which should not be 
dependent upon the physical attributes of the transport. There are a number 
of companies which recognized this and required that their driver writers 
avoided certain capabilities of SCSI-2 which relied on the parallel bus. 

I can pull a couple of slides out of my old SCSI training material and find 
guidelines on Queueing which preach against Ordering, and if it is used, 
absolutely prohibit mixing it with Head of Queue. I seriously doubt that 
ENDL was the only company inveighing against certain practices (many of the 
recommendations originated with clients). 

Managing I/O logically consists of programming in atomic units and if there 
are subsequent dependencies, not proceeding until an acknowledgment of 
successful completion.

I grant you that software which is based on assumptions of the physical 
transport can be more efficient than logical management BUT the downside is 
it has to change on a physical transport with different characteristics.

Every software driver which relies on implicit or explicit physical 
transport capabilities of the parallel bus has a problem. 

 - I sympathize with you, but I cannot empathize. 
 - I will support your efforts to identify all the places where drivers can 
   be affected.
 - I will oppose any effort to modify the serial interfaces to behave in the 
   same manner as the parallel bus. 

BTW, we may need to establish guidelines for your proposed effort, because I 
disagree with some of your assumptions e.g. 

> Each SCSI-3 serial channel presents its own behavioral characteristics
> for channel errors. These affect all layers of the host I/O subsystem,
> including the peripheral driver.  If my memory serves me right, one of
> the original objectives of SCSI-3 was the transparency of the physical
> interconnect to the peripheral drivers.  In my opinion this objective
> has not be met.

If my memory serves me right, the goal was to preserve the application 
software so that the user did not have to re-program. 

I believe it was debated that the task of the SIM to map physical interface 
characteristics to a peripheral driver. The SIMs could be wildly different 
and the Peripheral Drivers could be wildly different and as long as the user 
software worked, the objective was achieved. 

I would restate your line to read 'one of the original objectives of SCSI-3 
was the transparency of the physical interconnect to the application.' 

Of course, given that all our memories are affected by selective recall to 
justify the arguments we choose to make, we ought to forget the history and 
concentrate on understanding the problem being faced. If you can collect the 
concerns and the issues it will be a big step forward. 

All the best,

Dal

P.S. Do I have to be careful to avoid opening boxes wrapped in brown paper 
     that are postmarked as being from New England? 


% ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ======
% Received: from mail11.digital.com by us2rmc.zko.dec.com (5.65/rmc-22feb94) id
   AA11532; Wed, 1 May 96 02:25:04 -040
% Received: from mpdgw2.symbios.com by mail11.digital.com (5.65v3.2/1.0/WV) id 
  AA26171; Wed, 1 May 1996 02:22:24 -040
% Received: (from root at localhost) by mpdgw2.symbios.com (8.6.8.1/8.6.6) id AAA2
  2368; Wed, 1 May 1996 00:16:32 -0600
% Received: from aztec.co.symbios.com(153.72.199.214) by mpdgw2.symbios.com via
   smap (V1.3) id smaa22359; Wed May  1 00:16:09 199
% Received: (from majordom at localhost) by Symbios.COM (8.6.8.1/8.6.6) id AAA0730
  9 for scsi-outgoing; Wed, 1 May 1996 00:14:35 -0600
% Received: from mpdgw2.symbios.com ([204.131.201.2]) by Symbios.COM (8.6.8.1/8
  .6.6) with ESMTP id AAA07303 for <scsi at symbios.com>; Wed, 1 May 1996 00:14:30
   -0600
% Received: (from root at localhost) by mpdgw2.symbios.com (8.6.8.1/8.6.6) id AAA2
  2343 for <scsi at symbios.com>; Wed, 1 May 1996 00:14:31 -0600
% Received: from hustle.rahul.net(192.160.13.2) by mpdgw2.symbios.com via smap 
  (V1.3) id sma022337; Wed May  1 00:14:01 199
% Received: from endl.UUCP by hustle.rahul.net with UUCP id AA03901 (5.67b8/IDA
  -1.5 for scsi at symbios.com); Tue, 30 Apr 1996 23:13:57 -070
% Received:  by endl.us.com (UUPC/extended 1.12b); Tue, 30 Apr 1996 23:11:24 pd
% Message-Id: <3187008c.endl at endl.us.com>
% Date:      Tue, 30 Apr 1996 23:11:24 pdt
% From: "Dal Allan" <dal_allan at mcimail.com>
% Organization: ENDL Inc (14426 Black Walnut Ct, Saratoga, CA 95070)
% To: scsi at symbios.com
% Subject:   re:software_concerns
% Sender: owner-scsi at symbios.com
% Precedence: bulk

------- End of Replied-To Message




More information about the T10 mailing list