Compuadd Disk Controller?

[Doug Ingraham]

In article <201 at sixhub.UUCP>, davidsen at sixhub.UUCP (Wm E. Davidsen Jr) writes:
> 
>   Has anyone tried the caching ESDI controller from Compuadd? Especially
> with Xenix or UNIX. THis could be a cheap alternative to the DTP.
> -- 
> 	bill davidsen - sysop *IX BBS and Public Access UNIX
> davidsen at sixhub.uucp		...!uunet!crdgw1!sixhub!davidsen
> 
> "Getting old is bad, but it beats the hell out of the alternative" -anon

First the good news!

I got one of these babies last week.  Its easy to install.  The manual
tells what all but one of the jumpers does.  It comes with a special
format program called FMT.exe which you must use.  This is the best format
program I have seen under DOS.  It allows you to specify the # of sectors,
heads, cylinders interleave, head skew and cylinder skew.  The manual
indicates that the factory bad track table will be accessed if found (mine
had been overwritten so I don't know if this really works).  The other
program HCU.exe Hard Cache Utility allows you to look at statistics and
to disable cacheing.  Soft re-boot doesn't clear the statistics so you
can boot up under dos and see how good a job the cache controller does.
It comes with 1 256k x 9 bit 100ns simm installed.  I happened to have
4 1mb x 9 80ns simms so I was able to test several combinations of cache
size.  It runs under Dos 3.3 and Unix System V 386/3.2 (Bell Tech/Intel)
and SCO Xenix 386 2.3.  I did all my testing on my CDC Wren III model
94216-106 which is 106 MB unformatted and has 1024 cylinders and 5 heads.
The FMT program wanted it to have 36 sectors/track which comes out to
94,371,840 bytes.  Using my old WD controller I was only able to get 34
sectors/track (but the drive looked perfect to Unix and DOS).  With 34
sectors per track that was 89,128,960 bytes.  Since this drive has 21 bad
blocks on it and the Bell Tech does sector mapping this resulted in a
loss of 10752 bytes.  An overall increase of 5,232,128 bytes of usable
space.  On a Wren V 383 mb drive this would be about 20mb of additional
usable space.

Now for the bad news.

There is something wrong with the way it schedules writes to the drive.
As long as you are reading, it seems to work pretty well, although
even there I was unable to do a copy of a 48k file to nul: and have the
whole file reside in the cache (4mb of cache).  Doing multiple chkdsk's
would after 3 repetitions be completely from the cache.  As soon as you
start writing to the drive it becomes slow.  Installing Unix from Streaming
tape was agony as the tape would spin for a few seconds and then the disk
would be slightly active for several minutes.  It sounded like it might
have been writing a sector and then going back to track 0 for some reason.
After installing I ran a couple of simple tests to demonstrate the poor
performance.  You can try this at home!

Hardware was a 16mhz 80386 with 80387 and 4mb of memory.
Size of /unix = 439548 bytes.

Unix System V/386 ver 3.2u with 256k disk buffers and a WD 1007 controller.

time dd if=/unix of=/dev/null bs=256k	# first trial
real        3.8
user        0.0
sys         1.3
time dd if=/unix of=/dev/null bs=256k	# second repetition results are similar
real        3.7
user        0.0
sys         1.2
time dd if=/unix of=/tmp/junk bs=256k	#first trial
real        8.4
user        0.0
sys         2.1
time dd if=/unix of=/tmp/junk bs=256k	#second repetition results are similar
real        8.5
user        0.0
sys         2.1

Unix System V/386 ver 3.2u with 256k disk buffers and a Compuadd
HardCache/ESDI version 1.02 with 256k on board.

time dd if=/unix of=/dev/null bs=256k	# first trial
real        3.6
user        0.0
sys         1.1
time dd if=/unix of=/dev/null bs=256k	# second repetition results are similar
real        3.5
user        0.0
sys         1.1
time dd if=/unix of=/tmp/junk bs=256k	#first trial
real     1:08.7
user        0.0
sys         1.8
time dd if=/unix of=/tmp/junk bs=256k	#second repetition results are worse!
real     1:21.8
user        0.0
sys         1.9

Unix System V/386 ver 3.2u with 256k disk buffers and a Compuadd
HardCache/ESDI version 1.02 with 1mb on board.

time dd if=/unix of=/dev/null bs=256k	# first trial
real        3.2
user        0.0
sys         1.1
time dd if=/unix of=/dev/null bs=256k	# second repetition cache is working!
real        1.9
user        0.0
sys         1.0
time dd if=/unix of=/dev/null bs=256k	# third repetition slightly faster
real        1.5
user        0.0
sys         1.1
time dd if=/unix of=/dev/null bs=256k	# fourth repetition results are similar
real        1.5
user        0.0
sys         1.0
time dd if=/unix of=/tmp/junk bs=256k	#first trial
real     1:32.8
user        0.0
sys         1.7
time dd if=/unix of=/tmp/junk bs=256k	#second repetition cache is working!
real     1:17.1
user        0.0
sys         1.8
time dd if=/unix of=/tmp/junk bs=256k	#third repetition results are similar
real     1:16.9
user        0.0
sys         1.8

For those who want to use Xenix with this card, I couldn't get version 2.3.2
to install.  It kept telling me to move the partition past the bad spot
and I never found a place that was acceptable to it.  I tried to use the
whole drive for Xenix and then after that message I kept moving forward
to keep it on a cylinder boundary so it wouldn't complain about that.

The controller mapped this drive to 362 cylinders of 8 heads and 63 sectors.
There was no reason top do any mapping for this drive.  There is no way to
specify the mapping either.  If I had a choice I would have selected 1024
cylinders of 10 heads and 18 sectors.  With this configuration some of
the programs that expect less than 35 sectors/track would have been able
to run.  My old version of ATDISK failed with 63 sectors, but I knew about
that.

Conclusion:

    As things stand this controller seems to work OK for DOS.  A cache
program will give better performance for the money considering that
$500 will buy 4mb of 1 meg simms + the cache program.  SCO Xenix 2.3.2
wouldn't install (at least I couldn't get it installed and I have installed
it many times before).  Write performance was poor under Unix System V/386
ver 3.2 because the controller was probably doing a restore before every
write.  This wasn't a problem under DOS.  The manual mentions Unix and
Xenix and this is where this product would shine.  Maybe I'll get another
in a few months after they get the bugs out.

Any questions?

-- 
Doug Ingraham (SysAdmin)
Lofty Pursuits (Public Access for Rapid City SD USA)
uunet!loft386!dpi