Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!usc!jarthur!nntp-server.caltech.edu!toddpw
From: toddpw@nntp-server.caltech.edu (Todd P. Whitesel)
Newsgroups: comp.sys.apple2
Subject: Re: DMA?
Message-ID: <1991Apr17.210147.13550@nntp-server.caltech.edu>
Date: 17 Apr 91 21:01:47 GMT
References: <613@generic.UUCP> <1991Apr17.143801.22825@m.cs.uiuc.edu>
Organization: California Institute of Technology, Pasadena
Lines: 41

bazyar@ernie (Jawaid Bazyar) writes:

>   The RAMfast cache is what is termed as "write-through", i.e. any data
>written to the card is immediately written through to the disk.  This is

I thought the writes were supposed to be done in the background in order to
speed things up!

Just copying files in finder (and this is with a Zip at 10 mhz) the Ramfast
and quantum doesn't seem to operate as quickly as a Ramfast and a 'dumber'
drive like a seagate or a syquest. I get this feeling that the Ramfast's
transfer algorithm causes track-caching drives like the Quantum and Conner
to thrash somewhat -- the fastest I seem to be able to get is 512K/sec
(finder Verify on a 32 meg partition) and 200K/sec (finder Validate on a
32 meg parition w/ 176k free and files of various sizes). Writes are also
slower.

I have a theory on this: ProDOS is very space efficient, but it wasn't
designed for raw speed when the seek time outweighs the time to read a
single block. This is a real problem when you have 1 block of file data,
an index block, ~128K of file data, a master index block, another index
block, another ~128k of file data, and so on. Add to that the fact that
the Quantum reads a track at a time, and you have at least one guaranteed
thrash when reading a >128K file. Worse, the RAMfast may be assuming that
it can sync to the drive per block read (ok for Seagates and such) as
opposed to a track read (which is more appropriate for Quantum and Conner
mech's). I can easily see lots of unnecessary delays, because the RAMfast
is assuming that the drive will be free as soon as the block comes back,
but instead the drive is not free until the entire track containing that
block is available.

Somebody, please tell me the 2.0 ROMs do something about this. I paid more
money for a quantum and with a Ramfast it's actually slower than a Seagate
I was helping somebody set up. The only other alternative is to optimize
my filesystems but that doesn't solve the problem with write synchronization
(I figure the RAMfast is waiting on writes as well and not taking into
account the fact that the quantum will perform a background write of its
own).

Todd Whitesel
toddpw @ tybalt.caltech.edu