Path: utzoo!attcan!uunet!ncrlnk!ncr-sd!hp-sdd!hplabs!sm.unisys.com!cs.utexas.edu!tut.cis.ohio-state.edu!mailrus!nrl-cmf!cmcl2!rocky8!cucard!ccnysci!alexis
From: alexis@ccnysci.UUCP (Alexis Rosen)
Newsgroups: comp.sys.mac
Subject: Re: Reeks on Disktimer (LONG)
Message-ID: <1001@ccnysci.UUCP>
Date: 17 Nov 88 10:00:04 GMT
References: <698@mouse.UUCP> <30643@think.UUCP> <989@ccnysci.UUCP> <31573@think.UUCP>
Reply-To: alexis@ccnysci.UUCP (Alexis Rosen)
Lines: 39

In article <31573@think.UUCP> ephraim@vidar.think.com.UUCP (Ephraim Vishniac) writes:
"In article <989@ccnysci.UUCP> alexis@ccnysci.UUCP (Alexis Rosen) writes:
"+In article <30643@think.UUCP> ephraim@vidar.think.com.UUCP (Ephraim Vishniac)
"+writes (in an article about J. Reeks vs. DiskTimer II):
"+>                        ... As I mentioned in an earlier posting, data
"+>transfer rate is highly overrated as a performance measure.  When
"+>running most applications, seek time is much more important.
"
"+This is what I used to think. ...  Later I bought a Quantum 80 MB
"+unit with a seek time 50% slower than the Maxtor (28 ms as opposed to
"+18 ms) which nevertheless performed much faster in many operations.
"+The speed came from use of the then-new "fake DMA" mode which used
"+hardware-assisted "blind" reads and writes on the Mac II. So transfer
"+speed had a major impact on perceived speed.
"
"But the Q280 also has a large (60KB?  I don't remember exactly.)
"on-board cache.  So the seeks may be slower, but they are also
"somewhat less frequent.  This is a prime example of why benchmarking
"or buying disks is so damned complicated.  We need an actual usage
"test, but I doubt we'll ever agree on one.

How large is large? My understanding was that it was a one-track cache.  This
is, I believe, exactly the same as the Maxtor. In any event, a one-track cache
can't have any effect on seeks, can it? I thought the primary use of this kind
of cache is to eliminate rotational latency delays on requests for different
sectors on the same track.

There is another factor- since the Maxtor had more platters (and thus more
R/W heads) it actually had to do less track-to-track seeking (more info under
the heads at any one moment). Of course, there could conceivably be a disk so
fragmented that this would be irrelevant. But in fact, my case was a pretty
controlled test: One large 40-odd MB datafile, pre-allocated and guaranteed
contiguous.

----
Alexis Rosen                       alexis@dasys1.UUCP  or  alexis@ccnysci.UUCP
Writing from                       {allegra,philabs,cmcl2}!phri\
The Big Electric Cat                                       uunet!dasys1!alexis
Public UNIX                           {portal,well,sun}!hoptoad/