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!gamma!epsilon!zeta!sabre!petrus!bellcore!decvax!wanginst!wang!ephraim
From: ephraim@wang.UUCP (pri=8 Ephraim Vishniac x76659 ms1459)
Newsgroups: net.micro.mac
Subject: Diskbench Misleading? (Re: Delphi Mac Digest V2 #11)
Message-ID: <780@wang.UUCP>
Date: Tue, 25-Mar-86 08:34:04 EST
Article-I.D.: wang.780
Posted: Tue Mar 25 08:34:04 1986
Date-Received: Thu, 27-Mar-86 07:25:04 EST
References: <4608@topaz.RUTGERS.EDU>
Organization: Wang Labs, Lowell MA
Lines: 53

> From: BRECHER (6675)
> Subject: Hard Disk Benchmark
> Date: 21-MAR 05:48 Hardware & Peripherals
>  
> I wrote a simple disk performance benchmark program and have submitted it 
> with its MDS assembler source code to the Hardware database. [on Delphi,
> also posted to net.sources.mac]
>  
> The test is designed to measure hardware and disk driver performance, with no
> influence from the file system (HFS/MFS) or volume/file/Finder configuration.
> The program issues I/O requests directly to the disk driver.
>  
> The benchmark consists of three parts:
>  
> (1) 100 reads of 32KB of data from the start of the volume;
> (2) 100 writes of 32KB of data to the start of the volume;
> --the above two tests measure data transfer speed; 32KB was chosen to
> be a reasonably large chunk, but not so large that it would cross a
> cylinder boundary (thus not requiring any head movement).
>  
> (3) 40 iterations of:  read one 512-byte block from an offset of 1MB, followed
>                        by read of one 512-byte block from start of volume;
> --the above test measures access time, i.e., seek or head movement speed.
>  
> [some test results...]
>
> I encourage those with access to other hard disks to report results with this
> benchmark.

I would be very wary of taking results from this benchmark at face value.
Why?  Because the results of read/write speed tests are strongly dependent
on the unit transfer size.  32KB is a convenient choice for the test, but
I'm sure it's not a *realistic* one.  What is?  I don't know (yet).

In choosing the interleaving for my own hard disk (MacSCSI interface with
my own MDS-assembler driver), I ran a benchmark that did read-write tests
for a series of transfer sizes from 1 to 20 sectors, reformatted with different
interleaving, and ran again.  To optimize for Brecher's Diskbench, I should
have chosen an interleave factor of 4.  To optimize for single-sector transfers,
I should have chosen an interleave factor of 17!  (I've since improved the
driver, but haven't re-run the benchmark lately.)

Before people start making buying decisions based on the results from part
one or two of Diskbench, let's get some idea what the distribution of read
and write sizes really is.  Unless someone else has a tool handy, I'm 
volunteering to write a program that will hook into disk driver calls and
collect this data.  Please mail any suggestions to me directly at
	[most backbone sites]!decvax!wanginst!wang!ephraim
since followups to net.micro.mac probably won't reach me before I've written
the program.

Ephraim Vishniac
decvax!wanginst!wang!ephraim