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: <1991Jun23.032656.3227@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> <1991Jun13.142032.16772@bigsur.uucp> <1991Jun22.033501.17909@xstor.com>
Date: Sun, 23 Jun 91 03:26:56 GMT


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, 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.
>
>Obviously, your system lies *within* the margin of usefulness.  My tests
>were on two systems (hardly a large sample, I know); the problems with the
>floppy on one of the systems make it essentially unusable for all but the
>most temporary work on that system.  So, yes, 1 out of 2 means MARGINALLY.
>
I run a lowly 25MHz 386 so I guess I'm just not in the same class as you
because it really is useful on my system. FWIW, I too had problems with 
the floppy but I traced it to the fact that I was running my bus at 12.5MHz.
Dropping the speed to 8 MHz fixed it. I called up Always, explained what was
happening and they sent me up a new chip (at their expense). I put it in
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. 

>Hmmm.  After looking over my original posting I see that I did leave out
>an explanation of why turning off interrupts like that was so obviously
>deliberate - only another programmer would understand from my posting.
>

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.
I merely disagree with the "obvious" conclusions that you drew. 

>Let me give a (very) cursory explanation: when interrupts are disabled, the
>system essentially goes deaf to the world (i.e. it cannot "hear" requests
>for service from any of it's peripherals); the only process that runs is
>the one that turned off the interrupts.
>
>What this means: the clock ticks, but the ticks are never counted, so no
>time passes; the serial ports receive data, but nothing is ever done about
>it, so you get overrun errors and data is lost; etc., etc..
>
>Only someone very ignorant about systems programming would ever disable
>interrupts for any longer that was absolutely necessary (usually it's done
>for only a few instructions).  A disk transfer takes forever in computer
>time (Lorne Green would love it ... CPU years! :-).  Much too long to even
>consider disabling interrupts.

Of course we are talking about DOS here, remember. I've spent a number
of hours tracing down crashes where "smart" systems programmers did the
Microsoft recommended thing and switched to a "private" stack inside their
code/drivers before re-enabling interrupts. Problem is that most of these
"smart" system programmers neglected to take into account that nested
interrupts (or any interrupts) might need stack space as well. I have
found a number of programs where their internal stack works "most" of the
time, but don't use a serial mouse (or at least don't move it) when they
are active. Given the choice of missed timing ticks or crashes from stack
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
than an outright plot to deceive you. You say the network drivers (and in
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.

>>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
all possibilities into account before YOU go and accuse a company of 
plotting to deceive you and the rest of the world. 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. 

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

>>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
>
>We have a very good relationship with Adaptec - Bruce Van Dyke sometimes
>seems to almost live over here, and while I've only met Roy a couple of
>times, I have the utmost respect for him.  BTW, SDI is a big customer of
>Adaptec, so that may explain the treatment.

Well I called to obtain some information on some of their products. It 
appears that local rep knew that were supposed to carry Adaptec products
but they didn't know what any of the products did or how to get any
additional info. At Adaptec, I got a lady who after finding out that I wanted
information, rudely cut me over to an automated system which informed me 
that glossy brochures for some products could be obtained by mailing down
a self address, sampled envelope along with $10.00 per glossy for each
product I wanted. I thought perhaps this might have been an exception, but,
numerous other people on BIX have complained about similar experiences. 

I have heard reassonably good things about Adaptec's products (and a 
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.


>>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,
>
>Think for moment: let's do a minor "back of the envelope" calculation ...
>
>	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.

>
>Your average 386 can't even handle two builtin serial ports running at 9600
>baud.  Actually it has a hard time with one 9600 and one 4800, but let's be
>magnanimous and say a 386 running Unix can handle 2K interrupts per second.
>Using an interrupt driven driver, it would be impossible to service any
>drive faster than 256KB/s without 100% overhead (worse yet, some interrupt
>somewhere is bound to loose out and not get serviced in time).

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.

>>about the overhead you talk about. Should I expect 10% of the throughput or
>>95% ?
>
>Arggh!  I feel like saying, "Okay pardner, 10 paces then draw!"  This is
>getting silly.  You want numbers, go get them.  If you can summon enough
>reasoning to convince me that my opinion is on shaky ground, I'll go get
>them myself, but so far all I've seen is hot air (hot bits? - whatever).

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. 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
and time has already done a comparison with either OS/2 or Unix.  I guess
I'll just wait for OS/2 V2.0 and see if my system is still marginally
useful to me. After all, not all programs I run spend 100% of their time doing 
disk I/O.

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. I still don't like the "obvious" 
conclusions you draw based on the evidence you presented.
>
>- Tim Iverson
>  iverson@xstor.com -/- uunet!xstor!iverson


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