Conference hydra::amiga_v1

	Stock Amiga 2000, 1MB memory.
	Commodore A2090 controller.
	Seagate ST-251-1 40 meg, 28ms avg seek.
	Buffers = 30 in Mountlist.
	Drive recently reformatted (for FFS conversion).

File create/delete:	create 13 files/sec, delete 43 files/sec
Directory scan:		94 entries/sec
Seek/read test:		99 seek/reads per second
Read/Write:		Buff		Read		Write
			----		----		----
			512		77101		27306
			4096		131072		104857
			8192		174762		124830
			32768		238312		137970

Mark

    There's a good article in November's Amazing Computing comparing
    the 2090a, Supra, OverDrive, GVP, and C.Ltd. controllers. The same
    Amiga 2000 and 63meg drive was used to test each controller. They
    used Diskperf alone, Diskperf together with a 4 voice Sonix player
    and a hi-res overscan display, Diskperf with Ramspeed, and various
    copies and loads. It was interesting that the non-DMA controllers,
    GVP and C.Ltd. had the best performance during heavy sound and graphics
    use. They did mention that the C.Ltd. controller was very sensitive
    to interleave setting and that you had to compromise between optimising
    reads or writes.
    
    tom

Amiga 2000
68000
3 Meg
Pacific Peripherals Controller
Seagate ST-157N 48 Meg Hard Drive
(a 3.5 inch SCSI drive, 40 ms)

The tests were all done on empty partitions.  PopCLI, Snipit, and GOMF
were running in background (these programs spend thier time waiting, and
so should not affect the timings).


I divided the disk into two equal partitions.  The partition tested
looked something like this:

DH1:	Device = overdrive.device
    FileSystem = l:FastFileSystem
	Unit = 1
	Flags = 0
	Surfaces = 6
	BlocksPerTrack = 26
	Reserved = 2
	Interleave = 0
	LowCyl = 305  ;  HighCyl = 608
	Buffers = 256
    GlobVec = -1
	BufMemType = 5
    Mount = 1
    DosType = 0x444F5301
    StackSize = 4000
#


DH1: interleave 2  BufMemType = 5
File create/delete:     create 15 files/sec, delete 30 files/sec
Directory scan:         102 entries/sec
Seek/read test:         80 seek/reads per second
r/w speed:              buf 512 bytes, rd 28493 byte/sec, wr 27887 byte/sec
r/w speed:              buf 4096 bytes, rd 154202 byte/sec, wr 65536 byte/sec
r/w speed:              buf 8192 bytes, rd 218453 byte/sec, wr 62415 byte/sec
r/w speed:              buf 32768 bytes, rd 291271 byte/sec, wr 65536 byte/sec

DH1: interleave 2  BufMemType = 3
File create/delete:     create 15 files/sec, delete 31 files/sec
Directory scan:         102 entries/sec
Seek/read test:         80 seek/reads per second
r/w speed:              buf 512 bytes, rd 28493 byte/sec, wr 27887 byte/sec
r/w speed:              buf 4096 bytes, rd 154202 byte/sec, wr 65536 byte/sec
r/w speed:              buf 8192 bytes, rd 218453 byte/sec, wr 62415 byte/sec
r/w speed:              buf 32768 bytes, rd 327680 byte/sec, wr 65536 byte/sec


The number of DOS buffers (given by Buffers =) didn't seem to affect
Diskperfa's results.  A smaller partition with Buffers = 30 yielded
the same results.

I started running with the buffers in fast memory because it frees up
chip ram for chip ram types of things.  It also removes any possibility
of "overscan" problems.  The disadvantage is that long DMA transfers can
lock the CPU out of the expansion bus--so I can see fast memory contention!

Unfortunately, using the above Mountlist caused the system to crash
frequently.  The crashes seemed to occur when two separate tasks
were doing disk I/O at the same time.

By using MaxTransfer =, I was able to decrease the number of crashes.
However, it had a drastic effect on performance:

DH1: interleave 2   MaxTransfer=512
File create/delete:     create 14 files/sec, delete 28 files/sec
Directory scan:         102 entries/sec
Seek/read test:         80 seek/reads per second
r/w speed:              buf 512 bytes, rd 28493 byte/sec, wr 27887 byte/sec
r/w speed:              buf 4096 bytes, rd 28493 byte/sec, wr 27887 byte/sec
r/w speed:              buf 8192 bytes, rd 28493 byte/sec, wr 27887 byte/sec
r/w speed:              buf 32768 bytes, rd 28493 byte/sec, wr 27887 byte/sec


The best results were when I changed the interleave of the disk:

DH1: interleave 10   MaxTransfer=512
File create/delete:     create 15 files/sec, delete 31 files/sec
Directory scan:         102 entries/sec
Seek/read test:         64 seek/reads per second
r/w speed:              buf 512 bytes, rd 45990 byte/sec, wr 37449 byte/sec
r/w speed:              buf 4096 bytes, rd 47662 byte/sec, wr 43690 byte/sec
r/w speed:              buf 8192 bytes, rd 48545 byte/sec, wr 45197 byte/sec
r/w speed:              buf 32768 bytes, rd 48545 byte/sec, wr 45990 byte/sec

Note that MaxTransfer is the number of bytes, not buffers.  The 1.3 Enhancer
docs got this wrong.  The MaxTransfer should be a multiple of 512.  The
system will round it up to a multiple of 512 if the value your supply isn't.

However, the system seems to fail at random, infrequent intervals even
with the MaxTransfer = 512.  I've dropped back the the old file system
to see if the crashes will seem to stop.  (So far, so good.)

Pacific Peripherals has a new software driver for their board.  They keep
promising to send it to me, but I haven't gotten it yet.  I suspect that
the new driver is the reason that they think that their board works with
no MaxTransfer specified.  They've told me I can post the driver to the
net when I get it.

(I've seen the recent postings on the Pacific Peripherals controller
and the FFS on Usenet.  They haven't come up with anything I haven't
already tried and rejected.)


Re: .0

Personally Ed, I think that your controller isn't doing too bad.  150000
bytes/second compares quite well with most of the PC world, and the DMA
controllers seem to have the super high speeds only for unrealistically
large buffer sizes.  Programs that use 32K buffers are rare.  (Well I
do know of one file viewing program that asks the system for size of
the file to be displayed, allocates a buffer large enough to hold the
whole file, and issues one read.  That program really screams under the
FFS on my system!  At least it screams when it doesn't crash :->.)

    re. 2 
    
    	I thought the GVP controller was a DMA controller.

    re .0 
    
    	I take it that BLITZDISK does (gag) read-only caching (no real effect
    on the perf of your writes)...
    
    CE:	Caching studies here (at DEC) and elsewhere tend to indicate
    that to achieve bend of the curve in performance that your cache
    size should 1% of the total amount of data that you are accessing.
    (not necessarily the size of your device).
    
    After that you *generally* need to double your cache size to see
    truly noticeable performance gains.  Just out of curiosity, did
    microsmiths mention anything about how the cache was implemented...
    Did they replace HD.device or is it a "new" device that you
    have to go through to gain the benefit of the cache.  or, did they
    mention the caching algorithm used? (I would guess simple-lru)
    Also, is it a system-wide cache ie. all devices benefit or is it just 
    one device per cache? (or cache per device..hehe)
    
    brad

Re: .4

>    re. 2 
>    
>    	I thought the GVP controller was a DMA controller.

The GVP controller is "half-DMA."  The controller does DMA from the
disk into a memory buffer on the controller board.  The board then
interrupts the CPU who then moves the on-board buffer to wherever
it is supposed to go in the Amiga's memory.

The first advantage of this scheme is that it works with memory that
is not-DMAable.  For example, the 32 bit RAM on some 68020 boards
cannot be DMAed to.  Second, the board doesn't run into problems with
overscan (both the video subsystem and the disk subsystem may want to
grab control of the memory buss at the same time).

The disadvantage is that the CPU gets involved in disk I/O.

    Re .3
    
    As another Overdrive owner I would be very interested in what Pacific
    Periph. has to say about the overdrive.device.  Please do upload
    any new versions you might be sent.
    
    We now return you to your regularly scheduled benchmarks...
    
    
    Gary

    
    By adding the line...
    
    MaxTransfer = 200
    
    to my mountlist, I've been able to dramatically increase the
    performance of my hard drive.  I've plotted the performance as a
    function of the MaxTransfer value, and it definately peaks at 200.
    Wierd.
    
    Ed. 
    
    

Ed,

    My disk setup is quite similar to yours:

>   Seagate ST277N (Imbedded SCSI), 40 msec seek, 65 MB
>   C Ltd SCSI controller running SCSIDos 3.0 (optimized<!> for FFS)
>   KS 1.2, WB 1.3

    I  have been playing with maxtransfer, buffers and buffersize (in
C-Ltd's devsetup file). Max transfer of 200 had a detrimental  effect
when I tried it. The larger block sizes stopped increasing
performance at 4K reads/writes.

    Adjusting  mountlist  buffers up helped a little, but not as much
as I would have expected.

    The   "big  one"  for  me  was  buffersize.  It  increased  small
read/write performance by as much as 50%  for  me.  Large  read/write
performance  flattened  out. I tried up to 26 buffers (26 sectors per
track on the 277N) and got great performance on small end with only a
25% performance boost on the high end. Best overall  performance  was
with the default value of 8 in the sample devsetup file.

    I am now re-formating for 1:2 interleave to see if it helps.

	Thanks,
		-SES

Re: .7

>    By adding the line...
>    
>    MaxTransfer = 200
>    
>    to my mountlist, I've been able to dramatically increase the
>    performance of my hard drive.  

This doesn't seem right.  MaxTransfer is the number of bytes that can
be transferred in one I/O operation.  This parameter is documented
wrong in the Enhancer docs: it erroneously claims it is the number of
blocks.  Commodore has admitted this mistake on comp.sys.amiga.

Also, the fast file system rounds this value up to the nearest block.
So, MaxTransfers of 1, 200, and 512 are equivalent: one block will
be transferred at a time.  In general, this parameter should be always
be a multiple of 512 (the number of bytes in a block).

If you don't want to cramp diskperfa's style, try a MaxTransfer of
32768 (32k bytes, or 64 buffers).  The last read/write test of diskperfa
does I/O in 32k chunks.

Are your sure you were not setting the Buffers= parameter instead of
MaxTransfer=.

My tests (which I've done a lot of since I was encountering gurus)
verified that the MaxTransfer parameter is bytes, not blocks, and
that values less than 513 severely limit the speed of the drive.

Re: .8

>    I am now re-formating for 1:2 interleave to see if it helps.

That will make a big difference.   The primary speedup in the Fast
File System comes from being able to do large multi-block transfers.
The limiting speed on these transfers is how fast the proper blocks
pass under the read heads.

The typical interleave for the old file system was 16.  This means
the system can only pick up two or three blocks per rotation of the
disk.  If the interleave is 2, twelve or thirteen blocks per rotation.
That's a factor of six speedup!

An interleave is too fast for the Fast File System.  Two seems just
right.

    
    Re: MaxTransfer Value in Mountlist
    
    It appears that BLITZDISK (my disk cacheing utility) was heavily
    skewing the DiskPerf times.  After speaking with C Ltd, I ended
    up with MaxTransfer = 230000.  This seems to give the best all-around
    performance with or without BlitzDisk.
    
    Ed.

    Does anyone still have diskperf.arc online?

Yup,  WJG::AMIGA:

JOhn