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
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
Date: Tuesday, April 30, 1996 11:11PM
* From the SCSI Reflector, posted by:
* "Dal Allan" <dal_allan at mcimail.com>
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
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
- 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,
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