NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/sys/sgi/misc/109

Internet Message Format | 1992-12-30 | 3.7 KB

Path: sparky!uunet!olivea!sgigate!odin!twilight!zuni!anchor!olson
From: [e-mail] (Dave Olson)
Newsgroups: comp.sys.sgi.misc
Subject: Re: Hard drives...
Message-ID: <[e-mail]>
Date: 30 Dec 92 05:44:54 GMT
References: <[e-mail]>
Sender: [e-mail] (Net News)
Organization: Silicon Graphics, Inc.  Mountain View, CA
Lines: 74

In <[e-mail]> sgi.com!pdi![e-mail] (Shoshana Abrass) writes:


| In <[e-mail]> [e-mail] (Dave Olson) writes:
|
| >  The problem with moving drives to the Mac is that many models
| >  of Mac (all but the most recent?) don't handle unit attention
| >  properly on power up or after SCSI bus reset.
| >
| >  Conversely, many drives for the Mac have rather poor SCSI
| >  implementations.  The Quantum drive will probably work, but
| >  there are no guarantees.  --
|
|   I can't let this pass without comment. Undoubtedly, from the
|   standpoint of a scsi technician, an sgi (indigoes and personal
|   irises) is superior to a macintosh.
|
|   Unfortunately, from the standpoint of Joe User, Mac scsi is a
|   dream to work with compared to the sgi. We can attach any number
|   of scsi devices to our macs - disks, scanners, tape drives, etc. -
|   from any manufacturer, and they just WORK.

Well, I'll bet you are installing software to make them work ;)

The Mac is *incredibly* sloppy about ignoring bad bus phases,
errors on the bus, and violations of the scsi spec.  While this
may make it easier to install random stuff and have it work, it
has very unsatisfactory results in trying to make multiple
devices work *reliably* at the "same" time.

|   With the sgi's, every time we attach a new disk drive we run
|   the risk of encountering scsi bus errors, timeouts, etc. When
|   we get above four scsi devices, we need to start messing around
|   with cables - a few inches in cable length can make all the
|   difference.  We've never had this problem on the macs.

Sounds to me like you aren't using very high quality cables,
terminators, or devices then.  Either that, or you have done
something like blow the SCSI termpower fuse, and not fixed
it; that causes quite a few random problems.  Indigo has a
PTF instead a of a fuse, so it can't blow, but it takes seconds
to minutes to fully recover after a short.

|   I wish sgi had made their scsi bus more robust even at the
|   expense of making it a "poor implementation". I'd rather have
|   it work in the real world, than have the comfort of knowing
|   it's a perfect implementation of the spec.

I suppose you'd rather have corrupted data, and data rates
on the order of 100KBytes/sec, instead of 2-5 MBytes/sec
also?  I doubt it.

If you have support, ask an FE to check over your system
for things like SCSI termpower problems.

If you are attaching 3rd party SCSI devices, ask the people
you buy them from to support them properly.  If the problems
occur with SGI purchased devices, by all means get the support
folks to make them work; escalate the call if necessary!

We have done a lot of work to try to support as many SCSI
devices as possible (or at least to make it possible to
support them by somebody).  Some systems have poorer SCSI
implementations than others (the old IP4's (4D70, etc.) had
same blatant SCSI spec violations.  The power channel boards
have slightly different termpower on channels 0 and 1.  My
belief is that the Indigo is pretty clean, although it isn't
perfect (few if any SCSI implementations are 100% compliant
to all the specs and implementors notes, for a number of reasons).

--
Let no one tell me that silence gives consent,  |   Dave Olson
because whoever is silent dissents.             |   Silicon Graphics, Inc.
    Maria Isabel Barreno                        |   [e-mail]