🚀 go-pugleaf

In <34840@adm.brl.mil> sgi.com!pdi!shoshana@BRL.MIL (Shoshana Abrass) writes:


| >  The Mac is *incredibly* sloppy about ignoring bad bus phases, 
| >  {... }it has very unsatisfactory results in trying to make multiple
| >  devices work *reliably* at the "same" time.
| 
|   We've had far more cases of corrupted file systems or files on
|   the sgi's than on the macs. That's what I use to just the 
|   reliability of the bus.

It isn't just the bus.  It could also be the drives (what kind
were they, and were they SGI, or 3rd party?), or even (gasp!)
an OS bug.  How about some details.

| >  Sounds to me like you aren't using very high quality cables, 
| >  terminators, or devices then.  
| 
|   The devices are seagate disks. The terminators are, of course, 
|   from SGI. The cables are the best we can find to buy, though 
|   there may be better ones available.

Why of course?  Do you never have terminators on any of the
SCSI devices themselves?  If so, they usually come from the
drive manufacturer (or if external, from the distributor).
'best we can find to buy' is meaningless without knowing
where you bought them, what kind of connectors they have,
and how much the vendor cares about quality (there are things
you can do to improve the cables beyond what the current
standards call out, although some of them *are* part of the
the SCSI 3 draft).  A common failing of 'cheap' SCSI cables
is to use too small a wire gauge, not use twisted pair
wires, or even to not carry all the grounds through the
cable, but to just wire them together at the connectors
(and sometimes, not even there!).

| >  something like blow the SCSI termpower fuse, and not fixed 
| >  it; 
| 
|   Is there a diag test for this condition? Or do I get out the
|   ohmmeter?

Get the ohmmeter and check the fuse itself.  Checking the
termpower voltage can be done also, but don't do it with
terminators installed.  Checking the fuse is best.

| >  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.
| 
|   I want it to be both fast and usable. Maybe that isn't possible
|   in the world of scsi;  I'm not an expert. The point is, I don't

It *is* possible, but you have to pay attention to what you are
doing, particularly in cabling, and in using drives that have
been tested, and are known to work at high speed.  I can't begin
to tell you how many 'mature' drives we have tested that show
all kinds of firmware (and even hardware) bugs when run full out,
and no, these were *NOT* problems on our system that we made them
work around, they were definitely problems on the target drive.

|   want to _be_ an expert.  I want to attach new disks from well-
|   known vendors like seagate, and have them work without trauma.
|   I don't disbelieve that SGI has put a lot of work into its scsi; 
|   but I haven't had appreciably better behavior from the indigo 
|   R4000's than I had from the 4D/25's.

I wouldn't expect much difference (in 'reliability') between the
25 and the r4k Indigo.  I, the peripherals folks, and the hardware
folks have put a lot of effort into SCSI, pretty much starting with
the 25 (the 20 didn't have anywhere near the effort put into it,
as it pretty much took the 4D/70 implementation, and just shrunk
it down into an ASIC).  There have been *some* improvements,
particularly in performance, but basicly the implementation is
pretty similar.  The 25 had some pretty horrible internal SCSI
cabling in some revs, as various people 'improved' it, but those
were pretty much fixed by the 35 and later 25 revs, and of course,
there are no internal cables (except for drive sleds) on the Indigo.

| >  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!
| 
|   After several years of bad scsi behavior from many models of SGI
|   machines, I no longer believe the problem is with the devices.

As you have seldom given any details in your postings about the
problems, except for ones that point with > 99.9% certainty
to cabling or termination problems, it would be hard for me
to guess just what problems you are talking about, or what
the causes of them are.
--
Let no one tell me that silence gives consent,  |   Dave Olson
because whoever is silent dissents.             |   Silicon Graphics, Inc.
    Maria Isabel Barreno                        |   olson@sgi.com