Path: utzoo!attcan!uunet!decwrl!csus.edu!ucdavis!iris!becker
From: becker@iris.ucdavis.edu (Jeffrey Becker)
Newsgroups: comp.arch
Subject: IOStone
Message-ID: <7834@ucdavis.ucdavis.edu>
Date: 16 Oct 90 22:30:15 GMT
Sender: usenet@ucdavis.ucdavis.edu
Reply-To: becker@iris.ucdavis.edu (Jeffrey Becker)
Organization: U.C. Davis - Department of Electrical Engineering and Computer Science
Lines: 47

In article <143502@@sun.Eng.Sun.COM>, lm@@slovax.Sun.COM (Larry McVoy) writes:
> In article <2387@@van-bc.wimsey.bc.ca> jtc@@van-bc.wimsey.bc.ca (J.T. Conklin) writes:
> >In article <14900016@@hpdmd48.boi.hp.com> sritacco@@hpdmd48.boi.hp.com (Steve Ritacco) writes:
> 
> IOstone is misnamed and misleading.  It ought to be called "cachestone" or
> "buffer cachestone".  It does *not* measure I/O performance.  It measures
> cache performance.

We are sorry that you were mislead.  We would like to clarify a few
points:

1.  IOStone was designed to measure IO system performance on REAL SYSTEM
    WORKLOADS.  Consequently, our synthetic workloads are derived 
    from REAL PROGRAM TRACES.  You point out our program performs well
    with a large disk cache.  We completely agree with you.
    However, note that IO system workloads also benefit greatly from
    large disk caches.

2.  IOStone was designed to measure TOTAL IO SYSTEM PERFORMANCE.
    We do not desire to measure the performance of individual components 
    of the IO system performance such as the disk, controller or 
    the I/O channel alone.  Rather, we want to know how these perform 
    in conjunction with the other parts of the I/O SYSTEM, such as
    the cpu and the operating system. 

3.  We designed IOStone to be as simple to use and portable as
    possible.  We do not claim it is the MOST accurate measure
    of IO performance that can be constructed, but we do feel
    that it achieves a good compromise between portability,
    simplicity and accuracy.  

We feel that IOStone is the best widely used indicator of IO system
performance that is currently available.  

We do not mind criticism, but we prefer it to be CONSTRUCTIVE!
Other postings in this debate have mentioned the great difficulties 
inherent in producing a comprehensive IO system metric.  Please
consider these issues carefully before launching into another tirade.
We welcome any CONSTRUCTIVE SUGGESTIONS you might have in designing an
IO system metric.

If you would like a free copy of the IOStone code or a copy of our
Computer Architecture News (June 90) article,  
send email to becker@iris.ucdavis.edu

						Jeff Becker
						Arvin Park