Compuadd ESDI and UNIX - Summary

[Wm E Davidsen Jr]

  I indicated that I would post a summary of responses to my question
about using a Compuadd cached ESDI controller with Xenix. Since I got
some information about unix as well I am posting to both groups.

  Summary of experience with Compuadd cached ESDI controller and UNIX

The following people asked for a copy of the summary but didn't 
have any information:
	jackson at udel.edu
	virtech!cpcahil at uunet.uu.net
	sherpa!rac at uunet.uu.net
	usource.SARASOTA.FL.US!daveg at cs.utexas.edu
	mickey at cis.ohio-state.edu


The following replies were received:
________________________________________________________________

Date: Tue, 9 Jan 90 12:56:33 cst
From: pipkins at imagen.com (Jeff D. Pipkins)

  >Have you used the Compuadd cached ESDI controller with UNIX or Xenix?

   No.

  >Were there problems with installation?

  No, other than the fact that when you change ESDI controllers, you
  must redo the low-level format.  I do not know why, but experience
  seems to support this rule.

  >Does it work well in terms of reliability?

  Haven't had the first problem out of it.  There are two on site.  I
  have had enough reliability problems out of software disk cache
  emulators that I will not use them under any circumstances.  (Well,
  okay, only if it is built-in to the operating system.)

  >How much cache do you have on the controller?

  Three megabytes.  Ordered it with one, later added two more because
  I got it (virtually) free.

  >How large or small is your kernel buffer pool?

  Sorry, I've only used it under MS-DOS.

  >If you upgraded to Compuadd, what was the performance gain
  >over your previous controller?

  I conducted my own performance tests using a moderately large commercial
  software package.  The benchmark is the time it took to do a complete
  make of the package.  Using the software that came with the card, I
  temporarily disabled the cache.  It took 3 minutes on my 386/33 Gateway
  (17ms drive).  I then enabled the 1 megabyte cache and performed the
  exact same operation (the make was forced; no work was skipped).  It now 
  took only 1:10.  A few weeks later I aquired an extra 2 MBs of ram
  (from a MAC II.  They weren't surface mount, so the fit was kinda tight,
  and you wouldn't be able to get 4 MBs on there.  I sandwiched the smaller
  surface-mount SIMM between the larger through-hole SIMMs.)  It worked
  just fine, and the controller automatically recognized the extra ram.
  The hit rate climbed from 74% to 89%.  The time was still 1:10.  I chalk
  this up to the test now finally being CPU-bound.  A friend who also has
  a 3-MB version says he loves what it does with an image-processing program
  he has, but I haven't heard any numbers.

  >Any other info to prospective buyers.

  I recommend it.  If I had a choice of a 386/20 with a 1MB ESDI cache
  vs. a 386/33 with no hardware cache, I would choose the former without
  hesitation because I am confident that the performance would be better
  with the kind of work that I do.
________________________________________________________________

Date: 9 Jan 90 20:21:13 MST (Tue)
From: loft386!dpi at uunet.uu.net

Bill,

    I was one of the people who posted my experiences.  I still want
this to work since it was exactly what I wanted.  I tried it under
386 Xenix (the latest version I dont remember the number) which I borrowed
from work.  I couldn't get to to run its version of fdisk.  Actually
fdisk worked, but the part that scans the disk thought the whole thing
was bad.  Kept telling me to move the partition to a place that wasn't
bad.  I had Zero trouble under DOS and it worked under Bell Tech Unix
3.2u but the writes were terrible.  I had a 250k kernel buffer and
4mb of cache on the thing.  I also tried other Cache sizes before I sent
it back.

If you find out that it is fixed I would like to know so that I can
order one again.

Could you please send me the email address of the person who did QA
for it.

Thanks
________________________________________________________________

From: mic1!gary at uunet.uu.net
Date: Wed, 10 Jan 90 0:30:41 CST

Bill,

>   Have you used the Compuadd cached ESDI controller with UNIX or Xenix?
I have been using the Compadd controller for about a month under ISC
version 2.02 UNIX.

>   Were there problems with installation?
None at all.  I had read about about the card in Computer Shopper and
thought it worth a $500.00 gamble.  There were some cautions in the
magazine article about jumper settings.  I followed the manual and
article instructions, plugged in the card and have made no changes since.

>   Does it work well in terms of reliability?
There has been no problem of any sort.  So far, the card has proven
to be VERY reliable.  In my case, the card gets a real work-out.
System mic takes a full news feed and transfers to several other
systems in the Dallas area.  It is controlling 2 hard drives (1- 320MB
and 1- 150MB).

>   How much cache do you have on the controller?
Only 1 MEG, since the chips were just laying around (256K, 100ns SIMMS).
This is soon to be expanded to the full 4 MEGs.  Right now, the cache
hit rate is running around 46%.

>   How large or small is your kernel buffer pool?
If you are referring to NBUF, the current stune setting is 250.

>   If you upgraded to Compuadd, what was the performance gain
>   over your previous controller?
The performance gain for reading and writing /unix to /tmp/unix is
double the time it took for a WD1007 to perform the same task.  In
other words, using this primitive benchmark test, the Compuadd card
is twice as fast as the WD1007.  There is a qualifier here, though.
A lot depends on disk fragmentation.  All it takes to kill the
cacheing advantage is to reconfigure a kernal, for instance and then
rerun the above test.  My tests leave a lot to be desired.  Since you
have 30 days to return the card, try your own tests and keep it or
return it.

>   Any other info to prospective buyers.
Not much to say here since it has been said above.  The Compuadd card
is not the <BEST> cacheing card available.  Neither is it the fastest.
But it may well be the most cost effective, this month, anyway.
________________________________________________________________

That's all folks!

-- 
bill davidsen	(davidsen at crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen)
            "Stupidity, like virtue, is its own reward" -me