Conference hydra::amiga_v1

2552.0. "A HD controller review" by FRAMBO::BALZER () Wed May 10 1989 08:12

V 1.5  05-May-1989

	An Amiga Hard Disk controller review
	------------------------------------

Copyright 1988, 1989 by Christian Balzer
This material may be non-commercially used, as long as the author is
credited for it.

I've just completed a series of HD controller tests for a local
distributor, who supplied me with a GVP Impact 2000, a Supra 2000 DMA
controller and a Rodime 3085S (70MB, 28ms, SCSI) hard disk.
I also tested my A2090 with the same hard disk, while the distributor
tested it with a Cltd controller.

Feel free to take a look at the results below, make your own
conclusions and then read mine at the end of this article.

All the results were obtained by using the unmodified Diskperf
program from Fish disk #48.  
Where not otherwise stated, Blitzdisk, a cache program (sorta
Facc-II for hard disks) by Microsmiths, was run with 200 reserved
blocks (=100KB) with the DIRONLY option enabled (only FileInfoBlocks
are cached, no FileData). 
My standard environment consists of AmiCron, Facc-II, the memory
clock (mclk) by Mike Meyer, an AntiVirus program and in this special
case a full size PerfMon (Performance monitor by Dale Luck). 
I ran these tests from a 3MB (2MB FastMem) B2000, with a 680 *
274 * 2  PAL WB screen, using Kickstart 1.2 and Workbench 1.3.

The tests were conducted on empty, freshly formatted partitions, so
take these results with some grain of salt. As time goes by (don't you
just love that quote? :-), you should expect a performance 10 to 20%
less than stated below. Anything worse than 80% of the initial
performance (you did test your HD, didn't you?) is the perfect reason
and time for a full backup, formatting and re-installing of that HD. 

Running "alone" means all background tasks were killed and priority of
the diskperf CLI raised to 3 (This way you can compare these results to
some extend with monotasking systems).

----------
GVP Impact A2000 with Rodime 3085S, FFS.
With Blitzdisk, standard environment:

File create/delete:	create 15 files/sec, delete 29 files/sec
Directory scan:		84 entries/sec
Seek/read test:		66 seek/reads per second
r/w speed:		buf 512 bytes, rd 26479 byte/sec, wr 25954 byte/sec
r/w speed:		buf 4096 bytes, rd 145635 byte/sec, wr 113975 byte/sec
r/w speed:		buf 8192 bytes, rd 163840 byte/sec, wr 124830 byte/sec
r/w speed:		buf 32768 bytes, rd 262144 byte/sec, wr 201649 byte/sec

Without Blitzdisk:

File create/delete:	create 15 files/sec, delete 30 files/sec
Directory scan:		87 entries/sec
Seek/read test:		66 seek/reads per second
r/w speed:		buf 512 bytes, rd 26479 byte/sec, wr 25954 byte/sec
r/w speed:		buf 4096 bytes, rd 145635 byte/sec, wr 113975 byte/sec
r/w speed:		buf 8192 bytes, rd 174762 byte/sec, wr 145635 byte/sec
r/w speed:		buf 32768 bytes, rd 262144 byte/sec, wr 201649 byte/sec

Without Blitzdisk, running "alone":

File create/delete:	create 16 files/sec, delete 31 files/sec
Directory scan:		104 entries/sec
Seek/read test:		75 seek/reads per second
r/w speed:		buf 512 bytes, rd 28187 byte/sec, wr 27306 byte/sec
r/w speed:		buf 4096 bytes, rd 174762 byte/sec, wr 131072 byte/sec
r/w speed:		buf 8192 bytes, rd 174762 byte/sec, wr 154202 byte/sec
r/w speed:		buf 32768 bytes, rd 291271 byte/sec, wr 201649 byte/sec
----------
CBM A2090 controller with Rodime 3085S, FFS.
With Blitzdisk, standard environment:

File create/delete:	create 16 files/sec, delete 52 files/sec
Directory scan:		87 entries/sec
Seek/read test:		60 seek/reads per second
r/w speed:		buf 512 bytes, rd 22598 byte/sec, wr 25954 byte/sec
r/w speed:		buf 4096 bytes, rd 174762 byte/sec, wr 137970 byte/sec
r/w speed:		buf 8192 bytes, rd 291271 byte/sec, wr 187245 byte/sec
r/w speed:		buf 32768 bytes, rd 524288 byte/sec, wr 262144 byte/sec

Without Blitzdisk:

File create/delete:	create 15 files/sec, delete 47 files/sec
Directory scan:		87 entries/sec
Seek/read test:		94 seek/reads per second
r/w speed:		buf 512 bytes, rd 62415 byte/sec, wr 25700 byte/sec
r/w speed:		buf 4096 bytes, rd 163840 byte/sec, wr 137970 byte/sec
r/w speed:		buf 8192 bytes, rd 262144 byte/sec, wr 187245 byte/sec
r/w speed:		buf 32768 bytes, rd 436906 byte/sec, wr 262144 byte/sec

Without Blitzdisk, running "alone":

File create/delete:	create 16 files/sec, delete 50 files/sec
Directory scan:		104 entries/sec
Seek/read test:		109 seek/reads per second
r/w speed:		buf 512 bytes, rd 70849 byte/sec, wr 27594 byte/sec
r/w speed:		buf 4096 bytes, rd 174762 byte/sec, wr 154202 byte/sec
r/w speed:		buf 8192 bytes, rd 291271 byte/sec, wr 201649 byte/sec
r/w speed:		buf 32768 bytes, rd 524288 byte/sec, wr 262144 byte/sec
----------
Supra DMA 2000 controller with Rodime 3085S, FFS.
With Blitzdisk, standard environment:

File create/delete:	create 13 files/sec, delete 43 files/sec
Directory scan:		87 entries/sec
Seek/read test:		82 seek/reads per second
r/w speed:		buf 512 bytes, rd 59578 byte/sec, wr 25206 byte/sec
r/w speed:		buf 4096 bytes, rd 163840 byte/sec, wr 131072 byte/sec
r/w speed:		buf 8192 bytes, rd 262144 byte/sec, wr 174762 byte/sec
r/w speed:		buf 32768 bytes, rd 436906 byte/sec, wr 262144 byte/sec

Without Blitzdisk:

File create/delete:	create 13 files/sec, delete 28 files/sec
Directory scan:		86 entries/sec
Seek/read test:		80 seek/reads per second
r/w speed:		buf 512 bytes, rd 59578 byte/sec, wr 25206 byte/sec
r/w speed:		buf 4096 bytes, rd 163840 byte/sec, wr 131072 byte/sec
r/w speed:		buf 8192 bytes, rd 262144 byte/sec, wr 187245 byte/sec
r/w speed:		buf 32768 bytes, rd 436906 byte/sec, wr 262144 byte/sec

Without Blitzdisk, running "alone":

File create/delete:	create 15 files/sec, delete 30 files/sec
Directory scan:		102 entries/sec
Seek/read test:		90 seek/reads per second
r/w speed:		buf 512 bytes, rd 65536 byte/sec, wr 27594 byte/sec
r/w speed:		buf 4096 bytes, rd 174762 byte/sec, wr 145635 byte/sec
r/w speed:		buf 8192 bytes, rd 291271 byte/sec, wr 218453 byte/sec
r/w speed:		buf 32768 bytes, rd 436906 byte/sec, wr 291271 byte/sec
----------
C Ltd SCSI-Controller (SCSI_DOS 3.0), FFS, RODIME 3085S.
With Blitzdisk buffers 100 dironly, no other tasks.

File create/delete:	create 10 files/sec, delete 26 files/sec
Directory scan:		89 entries/sec
Seek/read test:		82 seek/reads per second
r/w speed:		buf 512 bytes, rd 45990 byte/sec, wr 42974 byte/sec
r/w speed:		buf 4096 bytes, rd 87381 byte/sec, wr 67216 byte/sec
r/w speed:		buf 8192 bytes, rd 104857 byte/sec, wr 79437 byte/sec
r/w speed:		buf 32768 bytes, rd 124830 byte/sec, wr 100824 byte/sec

Without Blitzdisk, no other tasks.

File create/delete:	create 9 files/sec, delete 13 files/sec
Directory scan:		82 entries/sec
Seek/read test:		73 seek/reads per second
r/w speed:		buf 512 bytes, rd 42281 byte/sec, wr 42974 byte/sec
r/w speed:		buf 4096 bytes, rd 84562 byte/sec, wr 65536 byte/sec
r/w speed:		buf 8192 bytes, rd 100824 byte/sec, wr 81920 byte/sec
r/w speed:		buf 32768 bytes, rd 119156 byte/sec, wr 100824 byte/sec
----------
(Here's an example for a "good" ST-506 (MFM = max 5Mbit/s !!!) drive)
CBM A2090 controller with Micropolis 1325 aka RD53 (70MB ST-506), FFS.
With Blitzdisk, standard environment:

File create/delete:	create 16 files/sec, delete 55 files/sec
Directory scan:		98 entries/sec
Seek/read test:		57 seek/reads per second
r/w speed:		buf 512 bytes, rd 22028 byte/sec, wr 27306 byte/sec
r/w speed:		buf 4096 bytes, rd 131072 byte/sec, wr 113975 byte/sec
r/w speed:		buf 8192 bytes, rd 187245 byte/sec, wr 131072 byte/sec
r/w speed:		buf 32768 bytes, rd 218453 byte/sec, wr 163840 byte/sec

Without Blitzdisk, running "alone":

File create/delete:	create 16 files/sec, delete 50 files/sec
Directory scan:		102 entries/sec
Seek/read test:		96 seek/reads per second
r/w speed:		buf 512 bytes, rd 62415 byte/sec, wr 28493 byte/sec
r/w speed:		buf 4096 bytes, rd 131072 byte/sec, wr 119156 byte/sec
r/w speed:		buf 8192 bytes, rd 187245 byte/sec, wr 154202 byte/sec
r/w speed:		buf 32768 bytes, rd 238312 byte/sec, wr 174762 byte/sec
----------

Now for my resumee:
The clear winner (speedwise) is the A2090 by Commodore, something
that doesn't surprise me, but may confuse some of you. But if you
take a look at way the 2090 does it's thing (A500/2000 Tech. Ref.
Manual), it get's clearer. The only possible competition (again
speedwise) are Supra and Microbotics , but the Supra has some problems.
An interresting tidbit seems to be the fact that Blitzdisk only helps
"slow" disks/controllers while "fast" ones suffer from the obvious
overhead. I still use Blitzdisk though, trading transfer speed for less
disk access and faster directory searches.

Some things to consider:

- Cltd is creeping even with FFS and their SCSI-DOS 3.0, due to their
non DMA concept, but they've got the most flexible controller with
the most (non HD) SCSI applications. Their software was a pain
userfriendlywise, and to some extend still is.  Data transfer with
this controller is the CPU's job, which really hurts multitasking. 
Their current line of controllers can't autoboot.

- GVP has the ideal combination of a RAM board and a hard disk
controller, their speed is reasonable and they seem to be as immune
as possible to severe (and deep) overscan. Their software is
straightforward, not too userfriendly but painless. And for a "half"
DMA style controller (DMA to onboard static RAM, CPU transfer to
final destination), their CPU usage is pretty low and acceptable. 
This controller has AutoBoot capability, that is two empty sockets
for the AutoBoot EProms, which are (to the best of my knowledge)
currently available. One more plus is that the newest GVP software
supports the hardblock protocol (see Supra), and thus allows booting
from a FFS partition.

- Supra has the most userfriendly software, but this is also their
biggest caveat. The diskperf results are close to that of the
2090(a), but since the Supra is also a DMA controller, that was to be
expected.The usage of Supramount (their replacement for binddrivers
and mount) the need to partition your hard disk and the enforced
device names (DH0:, DH1:. etc.) with Supraformat may be helpful for a
beginner but can be very disturbing for a "pro" (I know they were for
me, hell, I couldn't even install a partition to be mounted with
"MOUNT" without their (helpful) tech support). A big plus is the fact
that Supra is the first company to support the "HardBlock" standard
HD identification method proposed by CBM, which will allow the usage
of a HD formatted by controller X with controller Y without the need
to reformat it. 
This controller also has AutoBoot capability, that is two empty sockets
for the AutoBoot EProms, which are (to the best of my knowledge)
currently available.
But one thing that really made my cortex ripple is the fact that
during data transfer this controller STOPs ALL multitasking. Yuck.
And this with a MC68440 DMA chip on their board.
<Head shaking in amazement>  
The 2090(a) currently performs better or equal with a considerably
lower CPU and bus usage. Perfmon showed during the Supra diskperfs a
solid 100% CPU usage, while the 2090 only used about 50% (with a
"standard" usage of 25% in my environment, thats only a 25%
additional usage).

- Commodore did quite a good job on the 2090, despite all the
critisism I heard on this and other forums. All HD DMA vs. Video DMA
problems were solved with Fastmemfirst and their latest driver
software, although the transfer speed suffers badly with severe
(deep) overscan. But I'm willing to bet some vital organs, that the
2090A will be even faster, due to their new onboard driver and
enhanced firmware. And from what I hear in this newsgroup, the prep
kludge seems to be more userfriendly now. The real nice thing about
the 2090x is the fact that it transfers data via "hidden" DMA, with
nearly no loss in CPU performance. And that's what an Amiga (or any
multitasking system) controller should do.
The 2090A comes with AutoBoot software already onboard, so you'll
only need a 1.3 Kickstart ROM to get the benifits of autobooting.
A minus for the 2090x is the fact that the initiators (CBM) of the
Hardblock standard don't support it. Hopefully they'll do so in the
next software release, since the A590 controller for the A500 fully
supports it. The performance of the A590 is minimally slower
than the 2090x, but it has NO problems with massive Video DMA.

- The first experiences with the Microbotics Hardframe showed a
performance slightly better than the Supra. While the installation
software was kinda confusing, the overall impression was a good one.
One very nice detail is that the Hardframe is currently the only
controller that FULLY supports the Hardblocks standard (GVP and Supra
do only a subset, Supra claims to be changing that)

- From a large number of data I received from fellow Amigoids, you
should expect IBM PC ST-506 controllers connected to the Amy (ie the
Wedge) to top at around 180000 bytes/s read. Depending on the drive
(RLL = max 7.5 Mbit/s!!!) and optimized driver software, values as
high as 400000 bytes/s read can be reached. But of course the CPU has
again to do all the shuffling.

And as a last measure, compare the pricing of these products.

I really hope that this wasn't too long, and I don't have any
affiliation(sp???) with one of the mentioned companies, nor did they
bribe me (although I wish someone would :-).

Eagerly awaiting your comments,

- <CB>
--  _  _
 / /  | \ \  <CB> aka Christian Balzer  - The Software Brewery -
< <   |-<  > UUCP: decwrl!frambo.dec.com!cb OR cb@frambo.dec.com
 \ \_ |_/ /  CIS : 71001,210 (be brief!) | Phone: +49 6150 4151 (CET!)
------------ Mail: Im Wingertsberg 45, D-6108 Weiterstadt, F.R.G.
             EasyNet: FRAMBO::BALZER	or	Balzer @ FRN

"The first cut won't hurt at all, the second only makes you wonder,
 the third will have you at your knees, you start bleeding, I start screaming"
	From the song "Duel" by Propaganda.

    Thanks Christian, very enlightening.
    
    Has anybody had any experience with (or heard anything about)
    TrumpCard?  I see a lot of packages being advertised at attractive
    prices, but haven't heard from *anyone* actually using one....

    
    Just a comment about true DMA controllers...
    
    I've found (through personal experience) that certain 'pop-into the 68K
    socket' accelerator boards, such as the CMI 16 MHz Processor
    Accelerator, cannot co-exist with true DMA controllers, so factor this
    into your purchase equation.  I like the speed and functionality of my
    MicroBotics HardFrame (it's amazing how the mouse pointer never jerks
    while the drive is seeking) but I'd really like an inexpensive CPU speed
    increase.  I wonder how CSA's 68020 based Midget Racer would handle a
    DMA controller?
    
    Thank you for a very extensive review.
    
    Ed.
    
    

    
    Yeah, true DMA can be a problem with certain hardware (and even
    the internal hardware = Video DMA).
    Another thing to consider is the fact that currently only the RAM
    of the A2620 can be DMA'ed into, CSA and Hurricane RAM is outside
    the OS boundaries and may so be faster filled with a non-DMA
    controller!                  
     
    Regards,
    
    
    - 	<CB>

re                       <<< Note 2552.0 by FRAMBO::BALZER >>>
>                          -< A HD controller review >-

	OK, its 18 months later....  What, of significance, has changed ?
Supra looks to be the cheapest right now, but does the current version 
also stop multi-tasking during transfers ?   is the 2091 a vast 
improvement over the 2090a ?  ...and what of the Trump card, and trump
prof ? 

	Are there any recent magazine comparative tests that someone 
can point me towards ?

	I'm thinking of trying to get the drive either used from 
someone who has outgrown a < 40 Meg drive;  or a field service return 
that has grown  "too many"  bad sectors, maybe one with a whole bad 
head.  If I do this I'll need cables, do they come bundled with the 
controller (I hope) or with the drive (I suspect so, just my luck).

	R

re .0

	Another parameter of performance is reliability - well, 
reliability(or lack of it) impacts performance.  I am interested to 
know how these controllers and their drivers continue to perform as 
the disk gets more and more fragmented - I don't know what units of 
measure could be used for this, but something along the scale of 

crashes and loses 		to		gradual degradation
all data without warning			of performance with
						several levels of alarm
						to indicate urgency of 
						de-frag.

	OK, its subjective - which controller and software package is 
most fault tolerant, particularly with respect to fragmentation ?

	Reg

    Re: .5
    
    The fragmentation is caused by the file system and thus can also be
    cured to a certain amount by it. The drivers of all HD controllers
    should be able to handle any amount of fragmentation and the ones I
    encountered and tested over a longer period of time certainly did so.
    I once had my DATA: partition fragmented so heavily that after a
    reorganisation the DIR command performed about 10 times faster than
    before...
    
    <CB>