Xref: utzoo comp.sys.amiga:24191 comp.sys.amiga.tech:2173
Path: utzoo!attcan!uunet!cbmvax!jesup
From: jesup@cbmvax.UUCP (Randell Jesup)
Newsgroups: comp.sys.amiga,comp.sys.amiga.tech
Subject: Re: Hard Disk Performance tests, comments invited
Message-ID: <5030@cbmvax.UUCP>
Date: 19 Oct 88 06:15:07 GMT
References: <10150@cup.portal.com>
Reply-To: jesup@cbmvax.UUCP (Randell Jesup)
Distribution: na
Organization: Commodore Technology, West Chester, PA
Lines: 76

In article <10150@cup.portal.com> thad@cup.portal.com (Thad Thad Floryan) writes:
>The following was posted verbatim to BBS-JC on 18-Oct-1988 in response to
>my original statement of disbelief at the claim posted to BBS-JC by a marketing
>person from C-Ltd last week of "500K per second."  I'm still incredulous, since
>these figures indicate performance surpassing Sun 3/50, Sun 4/260, Compaq, etc.
>which use SMD and ESDI interfaces.  Well, life is full of surprises!  :-)

	Suns? Ha! Slow as worms!  :-)  And anything with an _INTEL_ processor?
Evil, kill it before it infects something, slower than molasses!  :-)

>``               Comparison Shopping with Diskperfa....

	Diskperfa is rather dependant on stdio/library implementation.  Most 
of the calls used are C library calls meant to emulate Unix calls, and may
therefor have some amount of overhead.  For the read/write speeds, I'd think
that the speed of Read() and Write() would be better benchmarks (and less
dependant on compiler library implementation).

>From:     Brick Eksten  ( Ronin Research and Development )
>   
>   	The object of the comparisons are to show that "True DMA" controllers 
>     are not always the best.  In fact, the fastest times were obtained using
>     boards that use no DMA,  instead using polled I/O to read/write data.
>     These were early tests and are not the fastest times obtained.
>     These tests show the difference between the non DMA boards and DMA boards,
>     and how DMA boards are affected by the addition of memory that cannot
>     be accessed by the DMA process ( 32 bit memory).  DMA boards cannot 
>     access any 32bit memory, so they must write/read to/from chip ram,
>     or 16bit ram,  were it can then be copied by the operating system into
>     32bit ram.  This is only a sample document.  The complete tests will
>     be posted when I have the time to make them legible.  

	Disclaimer: As far as I know, Ronin boards are fine products.

	That said, note that not all 68020 boards have 32-bit ram that 
cannot be DMAed into.  The A2620 has up to 4Meg of 32-bit ram that can be
DMAed into, for example.  It may well be that with 32-bit non-DMA memory,
CPU-driven I/O is faster.  However, with FFS and DMA-able 32-bit memory, I
suspect a DMA controller would be faster (and tie up the bus less, due to less
interrupts/polling).

>Miniscribe 3053 5.25" 40meg, CPU=68030, 32bit memory, FFS , Commodore 2090
>Commodore A2090 is a DMA controller (ST-506)
>r/w speed:		buf 32768 bytes, rd 84562 byte/sec, wr 34492 byte/sec

Please note that the Minscribe is, I believe, a 40 ms or maybe slower drive,
unlike the Quantum 40S's you were using above.  Also note that the speed of
a 2090 may well be faster using SCSI than St506.

>Miniscribe 3053 5.25" 40meg, CPU=68030, 16bit memory, FFS , Commodore 2090
>r/w speed:		buf 32768 bytes, rd 238312 byte/sec, wr 154202 byte/sec

	With 32-bit DMA-able memory, the numbers would have been signifigantly
higher than the 16-bit figures.  Inability to do direct transfers to the
destination buffer GREATLY reduce the speed of FFS (everything must be copied
twice, plus it probably does I/O 1 block at a time, instead of just transfering
the entire amount in one transfer.)

>	As a side note,   A program that uses "Amiga" specific function
>    calls ( as opposed to using "C" function calls ) was able to achieve
>    800+kbytes/sec using the C-LTD or GVP controllers,  both controllers
>    were very similar in performance.   The C-LTD controller did much better
>    when reading/writing small files ( 10-30k ),  the GVP controller did 
>    its best reading/writing large files ( 300k-1meg ).  Both controllers
>    were very close in midrange file size performance, but peak performance
>    was reached when reading/writing files that take advantage of each boards'
>    type of hardware engineering.

	800K/sec is also achievable with the 2090/2090a, with a good SCSI
disk (like the Quantums mentioned above - the 64K cache does wonders).  I have
seen a controller load a 2-meg file into 32-bit memory in less than 4
seconds.  600K/sec can be easily achieved with a 2090 and a semi-reasonable
disk (and a 68000 processor).

-- 
Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup