software_concerns

Hallam, Ken MV KHallam at po2.mv.unisys.com
Wed May 1 14:01:00 PDT 1996


* From the SCSI Reflector, posted by:
* "Hallam, Ken                 MV" <KHallam at po2.mv.unisys.com>
*

I would have thought that by now, Dal would be dropping all packages 
recieved in plain brown wrapping into bucket of water before opening, 
regardless of the postmark. One of the hazzards of being a newsletter 
editor.

Most of us have two, often conflicting primary factors to consider in 
designing the migration strategy from parallel SCSI to serial Fibre Channel 
implementations. 1-Legacy software implementations, (where we are today). 
2-Functions and features we want to add to our product line, (where we want 
to go). I'm sure Unisys is not alone in that we have not fully utilized all 
of the advatages in parallel SCSI in all of our implementations yet. In some 
cases, by postponing the adoption of some specific SCSI feature, we have 
made the transition to serial FC even more painful. There are very few 
interface implementations out there that don't rely on several attributes of 
the physical interconnect today. None of us has made the clean separation 
between logical and physical relms that the committee has. I/O systems and 
software are in general, a mess.

The advent of Fibre Channel peripherals and Fibre Channel devices will focus 
a large spotlight back on the system. All of the warts and blemishes we have 
been living with in this area will soon show up in start relief under this 
harsh light. We will soon supply 100 MB/s channel capability to our 
customers, who will then soon be asking us why they don't see that kind of 
performance. Or worse, why what used to work now breaks. Think of it as job 
security.

Ken Hallam
 ----------
From: scsi-owner
To: scsi
Subject: re:software_concerns
Date: Tuesday, April 30, 1996 11:11PM

* 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?





More information about the T10 mailing list