Newsgroups: comp.periphs.scsi
Path: utzoo!utgpu!cunews!bnrgate!bigsur!bcars53!mussar
From: mussar@bcars53.uucp (G. Mussar)
Subject: Re: Always IN-2000 SCSI host adapter (the real story)
Message-ID: <1991Jun13.142032.16772@bigsur.uucp>
Sender: news@bigsur.uucp
Reply-To: mussar@bnr.ca (G. Mussar)
Organization: Bell-Northern Research, Ottawa, Canada
References: <1991Jun06.204457.28453@xstor.com>
Date: Thu, 13 Jun 91 14:20:32 GMT


In article <1991Jun06.204457.28453@xstor.com> iverson@xstor.com writes:
>
>Recently, it has come to my attention that the current BIOS in the Always
>IN-2000 SCSI host adapter no longer disables interrupts during transfers.
>And, despite other problems, seems to be marginally useful as a host
>adapter for a DOS only system.

I'm glad to hear that I am running an adapter that is MARGINALLY useful.
It runs as fast as a friend's ESDI system, plays ball with Hyperdsk and
Windows 3.0. 

>A little over a year ago, Always gave SDI a board to eval saying it would
>make any disk run faster, just use CoreTest and see.  So, we tested it with
>CoreTest and found that a drive capable of max. 200KB/s transfers was
>turning in >1MB/s transfers.

Coretest on systems that translate (fake out DOS) is inaccurate. I've gotten
values ranging from 200KB/s to 1.2MB/s on the same drive with the same
controller in the same system just by varying the xfer size (this is on
both SCSI and ESDI translating controllers). Coretest thinks that it is
xferring one track (no head movement) but due to the translating, the head
needs to move. I hope you don't trust those numbers.

>So, point 1. - they knew their board caused drives to run faster on
>benchmarks.  Point 2., the code is obviously deliberate.  Conclusion?  They
>(both their engineers and marketeers) tried to pull a fast one.
>
>My personal opinion?  I will never, ever, do business with them because of
>their (apparent) complete lack of integrity on this one point.

My personal opinion? I think YOU would have us believe thank Always tried
to pull a fast one. Unless you have hard proof that Always deliberately
tried to perturbate the benchmark tests (say like a commented source code
listing) then I believe you creating your own (potentially incorrect) 
story. FWIW, I would rather not deal with someone who comes to such a
"scientific" conclusion from the data you had anymore than I would like
dealing with a used-car salesman.

I have found that Always are fairly approachable and willing to help
track down problems. Did you ever call them about this before spouting
off to the net? BTW, have you ever tried to get a hold of a real person
at Adaptec? I was quite surprised to see Roy Neese (of Adaptec) so active
on the net after I received extremely shabby treatment when calling them
on the phone. I never had that kind of problem with Always. (BTW, thanks for
the manual Roy.)


>The doc's also state that the board's FIFO uses dual-ported RAM for high
>performance and no 1st party DMA to avoid incompatibilities.  This is 100%
>correct, but very misleading.  Lack of "bus-mastering" ability does reduce
>incompatibility, but it also means this board is suitable only for DOS; it
>would introduce too much overhead on a multitasking system.

Gee, there is that great "scientific" mind at work again. I wonder how
anyone ever got along without bus mastering in the early days. Are you
saying that the only way for Always to use a FIFO is to sit in a spin loop
waiting for it to fill? Is there no way to interrupt when filled and
retrieve the data from the FIFO? That is what we did in the old days, but,
I guess we couldn't mulitask back then. Lets get some real (honest) numbers
about the overhead you talk about. Should I expect 10% of the throughput or
95% ?

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