Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site wang.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!wanginst!wang!ephraim
From: ephraim@wang.UUCP (pri=8 Ephraim Vishniac x76659 ms1459)
Newsgroups: net.micro.mac
Subject: Re: Delphi Mac Digest V2 #13 (Diskbench)
Message-ID: <790@wang.UUCP>
Date: Wed, 9-Apr-86 08:49:08 EST
Article-I.D.: wang.790
Posted: Wed Apr  9 08:49:08 1986
Date-Received: Fri, 11-Apr-86 01:00:54 EST
References: <4683@topaz.RUTGERS.EDU>
Organization: Wang Labs, Lowell MA
Lines: 42

> Delphi Mac Digest          Sunday, 6 Apr 1986      Volume 2 : Issue 13
> ----------------------------------------------------------------------
> From: BRECHER (7032)
> Subject: DiskBench results
>  
> The DiskBench application does low-level performance testing on hard disks,
> providing some indication of the relative speed of the disk hardware and
> driver software combination among competing products.

It disturbs me to see the diskbench results gathered and disseminsated with
such enthusiasm when their value is so questionable.  Thinking about how the
benchmark works, I have two *major* reservations about it:

	1.  The data transfer size of 32K is *grossly* unrealistic.  While
	launching and running programs, opening, saving, and closing 
	documents, a read or write of 32K is almost unheard of.  Copying
	files under the finder is the only common activity that does large
	reads or writes.  The performance of a disk with 32K transfers may
	have little to do with its performance on more typical small
	transfers.

	2.  Doing the reads or writes consecutively with no delay causes
	a bias that is consistent for a particular disk but varies 
	unpredictably from one disk to another.  Since all the operations
	start at the same sector (zero), the disk has to rotate to a
	fixed point to start data transfer.  This forces an overhead
	between consecutive tests.  In "real" operation this overhead
	is randomized, averaging half the rotation time of the disk.  In
	DiskBench, this overhead is consistent for a particular disk,
	depending on where the previous operation ended and the time to
	return from the driver to DiskBench and start the next operation.

So, a *realistic* disk benchmark would have to survey a variety of transfer
sizes and would have to "dither" the delay between tests to avoid bias.
Note that the rotational bias problem also affects the seek test, since it
seeks to a particular sector, and not to a particular track.  By 
varying the interleaving of my disk, I've varied the "seek" result of
DiskBench from 315 to 367!  Obviously, this test is not a very pure test
of seek overhead.

Ephraim Vishniac
decvax!wanginst!wang!ephraim