Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!convex!convex.COM
From: patrick@convex.COM (Patrick F. McGehearty)
Newsgroups: comp.arch
Subject: Re: Workstation Disk I/O
Message-ID: <107000@convex.convex.com>
Date: 9 Oct 90 17:41:08 GMT
References: <2387@van-bc.wimsey.bc.ca> <143502@sun.Eng.Sun.COM> <5725@mace.cc.purdue.edu>
Sender: usenet@convex.com
Reply-To: patrick@convex.COM (Patrick F. McGehearty)
Organization: Convex Computer Corporation, Richardson, Tx.
Lines: 22

In article <5725@mace.cc.purdue.edu> abe@mace.cc.purdue.edu (Vic Abell) writes:
...deleted stuff
>It is very difficult to disable the effect of a good buffer cache when you
>really want to measure I/O device or channel speed.  So far I've not seen
>any test that does a good job of that, nor have I been able to construct
>one myself.

I agree, direct measurement of HW performance can be tricky in the presence
of buffering, caching, etc.  When we (at Convex) wanted to measure our new
disks actual transfer rate potentials, I needed to solve this problem.

The first approach I tried was to write many large files, hoping they would
have the effect of flushing the test file out of the cache.  This method was
not particularly reliable, as it depended on the cache replacement algorithm.

The approach I like is to write a large file, dismount and remount the file
system being tested (which clears the buffer cache in our Berkeley derived
but heavily tuned implementation) and then measure the time to read the
file.  Repeat full process several times to obtain an idea of stability and
measurement error.  Of course, I had a dedicated machine with full root access.
But measuring I/O performance on a non-dedicated machine is not particularly
reliable anyway.