Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!uunet!xstor!bang!iverson
From: iverson@bang.uucp (Tim Iverson)
Newsgroups: comp.periphs.scsi
Subject: Re: Always IN-2000 SCSI host adapter (the real story)
Message-ID: <1991Jun23.105753.5484@bang.uucp>
Date: 23 Jun 91 10:57:53 GMT
References: <1991Jun13.142032.16772@bigsur.uucp> <1991Jun22.033501.17909@xstor.com> <1991Jun23.032656.3227@bigsur.uucp>
Reply-To: iverson@xstor.com
Organization: House of the Smoking Gun
Lines: 196

In article <1991Jun23.032656.3227@bigsur.uucp> mussar@bnr.ca (G. Mussar) writes:
>In article <1991Jun22.033501.17909@xstor.com> iverson@xstor.com writes:
>>In article <1991Jun13.142032.16772@bigsur.uucp> mussar@bnr.ca (G. Mussar) writes:
>>>In article <1991Jun06.204457.28453@xstor.com> iverson@xstor.com writes:
>[...]
>and the card now runs fine at 12.5MHz. But I do suppose it is good business
>practise to hold the original problem against the company forever. 

Well, I don't hold their technical problems against them forever, just their
sneaky tricks.  If they fix their technical problems that's great, but the
only thing that would satisfy me on the other is an admission of guilt on
the interrupt issue (even if it was confidential).

BTW, both systems I tested it on were using the standard 8Mhz bus speed and
(supposedly) they sent me their latest and greatest firmware and BIOS.

>Oh thank you. I've have been programming low level realtime I/O routines for
>over 15 years. I'm sure I did understand the impact of what you saying.

Sorry for the false assumption - your posting didn't seem to indicate
understanding, but then that's the beauty of our wonderfully ambiguous
english language ... well, maybe someone else got something useful from the
digression.

>I merely disagree with the "obvious" conclusions that you drew. 

I really would like to hear your reasoning - is it all gut feel or do you
have something concrete?  I've rejected numerous other scenarios (this one
gets about a 75% feel, all the rest are at about 5 or 10%), but a different
plausible explanation would certainly cause me to reevaluate my position.

>overflow, I think I would choose the latter. And if, just by chance, they
>are in fact being truthful about this being beta software, such disabling
>of interrupts just might be belts and suspender type programming rather

Could be.  Their code was very clean though - very easy to understand from
the dissassembly, unlike many other BIOSes (it took me about 2 minutes to
find the spot instead of 30).  The cli/sti really stood out as odd - why
not put the band-aid over the sore instead of wrapping the patient like a
mummy?  Judging from the rest of the code, the programmer should have been
competent enough to avoid doing it this way.

I'd give this a 10% likelyhood, but only if it's for a software issue, the
hardware issue is not possible.

>fact the production software) don't disable interrupts. But the fact that
>the network driver you received did it differently than the other driver
>makes it most apparent that this is a plot. I believe that it just might
>be possible that the net drivers are a little later vintage the the driver
>you are complaining about. But there I go again being ignorant of the fact
>that all software is of the same vintage, etc. when given to you. Sorry.

Arggh.  I really don't mind when you attack the facts (just when you attack
my integrity) - no need to apologize.  Yes, the netware driver could have
been a later vintage, but the real point is that it ran fine on the *same*
card that had the cli/sti BIOS.  This kinda zeros the software-bandaid for
flaky beta hardware scenario.

>>>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.
>>
>>Frankly, I don't like being called a liar.  I reported facts and used them
>>to justify my conclusions.  If you can't refute my *reasoning* (which you
>>made no attempt to do - perhaps you can't), then please refrain from
>>attacking my integrity and withdraw your accusation.
>
>Sir, I do not call you a liar, but, rather I believe you may not be taking

Hmm.  Your own words: "creating your own ... story".  Creating and stories
implies fictional.  Fiction is just sugar-coated lies, so pony up.

[ Actually, I guess your words could be construed as a form of apology -
  kind of a face-saving "I never called you a liar, you just thought I did"
  - so maybe I should consider it one ... rdly-rckn-snagl-fratzen ... ]

>all possibilities into account before YOU go and accuse a company of 
>plotting to deceive you and the rest of the world.

I took a large number of possibilities into account - I played devil's
advocate and tried to give a solid justification to their actions, then
tested to see if they were true.  I couldn't find a good engineering reason
for the hack.  That doesn't mean there isn't one (I'm not perfect - how
would you ever guess? :-) just that the real reason probably lies elsewhere.

>I made no attempt to
>reason why beta software might have the int disables in because there are
>many (both good and bad). But I suppose they would only occur to those
>ignorant of system programming. Those in the "know" would correctly assume
>a plot against the world. 

Another small factor in the "plot" scenario is that I would judge it's
chances of discovery (had I been on Always' side) to have been rather
small.  The only reason I caught it was that I have an extremely large
"curiousity bump" - if something's odd, I've *got* to know why.

>I still do not want to deal with people who jump to such conclusions based on 
>(in your own words) somewhat circumstantial evidence.

Unfortunately, that's the nature of some of my data.  When I get new data,
I'll reevaluate my conclusions.  However, I can hardly see Always coming up
with a scenario that I would believe.

>[horror story of adaptec customer relations]

>couple of bad things, but, those appear to be fixed). And I am impressed
>by the help provided by Roy Neese on the net. But there is a real (or
>perceived) problem with "little" folks getting info especially if they 
>don't have access to Roy on the net.

I don't know how to help out here.  I can say that if you or anyone ever,
ever gets that kind of treatment from Storage Dimensions (where I work),
just call the president and he'll kick some *ss for you.  You could call
me, and I'd rip the offending party up verbally, but for some reason his
words seem to carry a little more weight ... around here, the customer
isn't king, he's GOD :-).

>>	guess 1: 128 byte FIFO
>
>I believe the FIFO is 1-2K not 128 byte, But whats a factor of 8 or 16, eh?
>
>>	guess 2: 512KB/s (transfer rate for some hard drive somewhere)
>>	divide guess 2 by guess 1 to get ...
>>	512KB/s / 128 bytes = 4096 full FIFOs (or interrupts) per second.
>
>or 512 or 256 full FIFOs (or interrupts) per second if the real FIFO size 
>is being used.

Hmm, I just thought of another reason it probably isn't done like this - if
you wait for the FIFO to fill, you've got to stop taking in data from the
SCSI bus.  Chances are, with a fast drive, that data can come in as fast as
you can pick it up (it comes in on the i/o bus, not the memory bus).

>>magnanimous and say a 386 running Unix can handle 2K interrupts per second.
>
>I know I'm ignorant of system programming. I guess that why I can get a 
>10MHz 286 running 32 ports of synchronous X.25, interrupt driven with
>an average of 15,000 interrupts/sec (no, its not DOS compatible HW). OTOH,
>my lowly 25MHz 386 can easily run a 56K line while running Windows 3. It
>all depends on the OS and the programmer writing the SW.

I never said it was impossible - I once got a 12Mhz 286 to service approx.
56K interrupts/sec. with room to spare.  I was using Unix as an example.
Unless you've got a special real-time multi-tasking OS, the interrupt
overhead is real high.  Under Unix a limit of 2K i/s is pretty real.

Besides, even if they have a full track buffer like most ESDI controllers,
they've still got to carry the bytes into the system by hand.  This is the
same reason multi-drive SCSI beats multi-drive ESDI.

>Sigh. Tim, I am using this SCSI controller in my own personal system. I don't
>have the resources to purchase a number of controllers/ disks/ systems to get
>these numbers and I don't have companies mailing me boards to try out.

Actually, this was the first time I was singled out personally for this
"honor", but we do have lots of hardware lying around.  I may even get
curious enough to look into it on my own time, but I wouldn't count on
anything there for at least a month - it's real hard to measure overhead
on a Unix driver accurately from software, but I might have a way.

>I truely was interested in knowing what kind of difference a bus-master board
>in a multi-tasking system would be. Perhaps someone with both the resources

This I can answer in general: if you have one SCSI disk vs. one ESDI disk,
the ESDI comes out a little bit ahead.  If you have two vs. two, then the
SCSI wins.  This test was done about a year ago with the Adaptec 1542, the
results would probably be much different using a BusTek 540 - their per
command overhead is more than 1ms less Adaptec's.

>useful to me. After all, not all programs I run spend 100% of their time
>doing disk I/O.

Since you're talking about a home system, you may be satisfied with
something that has 10% or 20% more overhead, especially since you already
have a board that works for you.  If you're buying from scratch, though,
bus-mastering is worth it.

>If you really want to go 10 paces, then draw, be my guest, but don't expect me
>to continue in a flame fest with you.

Actually, my words were aimed at provoking a "flame-fest", but was I hoping
for something more civilized - sorta like a rationality test (you passed,
mostly :->).  

>I still don't like the "obvious" 
>conclusions you draw based on the evidence you presented.

That would be inhuman.  You have an Always board, which implies at least an
emotional interest in vindicating them.  I know I'd have a problem (a very
very small one :-) admitting to liking a board someone on the net was
calling the "Never IN-2000".  If it works for you, fine, but even ignoring
the interrupt issue, the other problems are such that I simply can't give
Always a thumbs-up.

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