Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uunet!xstor!iverson
From: iverson@xstor.com (Tim Iverson)
Newsgroups: comp.periphs.scsi
Subject: Re: Always IN-2000 SCSI host adapter (the real story)
Message-ID: <1991Jun25.234144.7465@xstor.com>
Date: 25 Jun 91 23:41:44 GMT
References: <1991Jun23.032656.3227@bigsur.uucp> <1991Jun23.105753.5484@bang.uucp> <1991Jun24.162514.17437@bigsur.uucp>
Reply-To: iverson@xstor.com
Organization: Storage Dimensions, Inc.
Lines: 75

In article <1991Jun24.162514.17437@bigsur.uucp> mussar@bnr.ca (G. Mussar) writes:
>In article <1991Jun23.105753.5484@bang.uucp> iverson@xstor.com writes:
>>only thing that would satisfy me on the other is an admission of guilt on
>>the interrupt issue (even if it was confidential).

>[quote reordered slightly ...] admitting guilt is usually only done
>if the party was guilty to start off with. There is the possibility that
>they are guilty but I don't believe the evidence presented (to date)
>indicates that (IMHO), emotions aside.

They are guilty of not informing us that they had done this prior to giving
us the board.  Why?  Did they not want us to know or was it a matter of a
slight mixup trampling alot of good intentions?

If the cli/sti hack had been explained up front, my opinion of Always would
be very different than it is now.  In fact, there would have been no reason
for me to have gotten involved at all, the spurious benchmark times would
not have been curious.

>I would be interested in the real reason you had trouble with the floppy
>just in case something starts acting up in my system. Speed and interacting
>hardware problems are fairly tough to track down especially without lots
>of fancy (expensive) equipment to help. I doubt that Always (or most other

The floppy didn't work on a Mitsubishi MP386S, a 16Mhz 386SX ISA-bus clone.
It did work on an AST 33Mhz 386 EISA-bus machine.  The MP386S is a known
flaky machine - I used it for the simple reason that it happened to be on
my desk that day.

>I've even let a few things manage to get out into the field with some
>debugging SW turned on (it does happen once in a while).

My software's always perfect, too (except for that one time about 3 years
ago when ... :-).  It could have been a simple oversight, yet why didn't
they explain up front or after the fact?

>FWIW, the price of the Adpatec (plus SW) came out to twice the cost for
>the IN-2000 (way up here in Canada). This ends up being a significant 
>factor for some people (as well as the customer support problem for us
>little folks who have lousy local reps).

That's one of my own peeves - everyone wants support, even the little guys,
but nowadays, you have to pay a premium to get it.  This isn't so much a
problem for Old Deep-Pockets, but the rest have to balance support with
performance, with compatibility, and with price.

It's even worse when you cross-over and see that same Old D-P that knows
good support really does cost money (and is willing to pay for it) never
realizes that bad support costs even more money in lost customers and lost
word-of-mouth sales.

>I have heard some rumors that Adaptec
>might be trying to get out of the "board" business and get more into the
>chip business with "Adaptec register compatible" boards showing up on the
>market. That could be a problem if true (lets hope not).

Actually, it wouldn't be such a big loss - there's already one Adaptec 1542
clone that has much less overhead than the 1542 (BusTek 540), and I've
heard rumors of a drive array adapter that speaks 1542 (from Dell?).  A
stable and accepted interface is far more important to the success of SCSI
in the market than any single vendor's board.

Snazzy new interfaces look neat but consistency is far more important.  Case
in point - Adaptec added a new interface to their EISA card, the 1740.  The
new interface is indeed improved, but it requires a new driver.  Result?
Initially, the new mode was completely ignored, and even now (more than a
year later) it is supported only by a scant handful compared to the support
available for the 1542 interface.

>Gary Mussar  |Internet:  mussar@bnr.ca                |  Phone: (613) 763-4937
>BNR Ltd.     |                                        |  FAX:   (613) 763-2626


- Tim Iverson
  iverson@xstor.com -/- uunet!xstor!iverson