From owner-freebsd-hackers  Sat Oct  7 17:05:06 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id RAA03509
          for hackers-outgoing; Sat, 7 Oct 1995 17:05:06 -0700
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA03497
          for <hackers@freebsd.org>; Sat, 7 Oct 1995 17:05:00 -0700
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id KAA07573; Sun, 8 Oct 1995 10:02:17 +1000
Date: Sun, 8 Oct 1995 10:02:17 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199510080002.KAA07573@godzilla.zeta.org.au>
To: bde@zeta.org.au, chuckr@eng.umd.edu
Subject: Re: VLB Disk Controllers
Cc: dennis@etinc.com, hackers@freebsd.org
Sender: owner-hackers@freebsd.org
Precedence: bulk

>Bruce, I have tried that on my 486/66, using a 2842 with a Seagate 
>ST42100, and I notice that I get different results every time I run it, 
>do you know why?  If that's supposed to be, then the results of that 
>program really should be averaged, across multiple invocations before 
>they really would show that accurately.

There's some inherent randomness, and the benchmark isn't as careful as
it could be.  It could begin by reading from track 0 to eliminate the
initial seek time, if any.  But you can run it twice ans mostly ignore
the results of the first run to get the same effect (of course the disk
must not be used by other processes or the contents of track 0 will be
flushed from the drive's cache.  It should have a time arg so that it
can run for longer itself...   

Bruce