Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!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: <1991Jun22.033501.17909@xstor.com> Date: 22 Jun 91 03:35:01 GMT References: <1991Jun06.204457.28453@xstor.com> <1991Jun13.142032.16772@bigsur.uucp> Reply-To: iverson@xstor.com Followup-To: comp.periphs.scsi Organization: Storage Dimensions, Inc. Lines: 165 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. >>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. >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 I don't care how you vary the buffer size, you simply cannot get CoreTest to report a rate that exceeds that drive's maximum rate. *Unless* someone cheats somewhere. You must have performed that test on a drive capable of transferring at 1.2MB/s. >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. Only to a point. If you thought for a moment, you would realize that speed burps due to translated geometry always *reduce* the reported transfer rate. They never increase it. CoreTest can still be used to provide a ball-park figure; so, when it reports Pee-Wee Herman hitting a grand slam, you've got to wonder a bit. [ Recently, we needed much more precise numbers. So, we developed our own much more accurate testing program that we now use internally. This is what I used in my most recent investigation. ] >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 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. 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. The telling blow is that their netware driver did not disable interrupts. This means that they didn't have to disable interrupts during a BIOS disk transfer - they must have had some other, non-engineering reason. Finally, they admitted to me that this hack was present only in a beta version they gave to SDI - no reason given for its presence or removal. >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. I admit, my conclusion is based somewhat on circumstantial evidence - I don't *know* what the programmer was thinking when he put the disable/enable interrupt instructions around the disk transfer. But, as they say, actions speak louder than words - the *only* gain to Always as a result of this action was to cause disk benchmarks to report wildly high rates, ergo that was the result intended by the programmer. [ N.B. I did indeed test the board by manually skipping the disable instruction; it worked fine with interrupts enabled - further proof that the hack was not done for any *engineering* reason. ] >I have found that Always are fairly approachable and willing to help >track down problems. Did you ever call them about this before spouting No. They called me and tried to *force* a posted retraction from me. This was unsuccessful, but if their board really was now as good as they said, my own sense of honor demanded that I correct my earlier statements. So, I offered to correct my earlier statements *if* he would send a board to me so I could verify things. They sent, I looked, I posted. Veni, vidi, vici? Perhaps. But I was aiming for more Joe Friday than Caesar. >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 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. >>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. If you are not capable of refuting my opinion via reasoning, please refrain from displaying your ineptitude by resorting to name calling. >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 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. 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). My guess (based more on intuition and experience than the above estimate) is that they probably work it just like ESDI, with a "rep insw" from the port and rely on the board to do the handshaking. Simple and direct. Overhead is still essentially 100% (i.e. only interrupt processing can happen during a transfer), but this way they can probably sustain > 1MB/s. >I guess we couldn't mulitask back then. , I never said bus-mastering was required, just that *I* would not recomend using a non-bus-mastering board for any multi-tasking OS. Bus-mastering is relatively cheap and provides such a large reduction in overhead w.r.t cost, that it is foolish not to use it when you can. >Lets get some real (honest) numbers >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). >Gary Mussar |Internet: mussar@bnr.ca | Phone: (613) 763-4937 - Tim Iverson iverson@xstor.com -/- uunet!xstor!iverson