Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!hellgate.utah.edu!csn!arrayb!taylor
From: taylor@intellistor.com (Dick Taylor)
Newsgroups: comp.benchmarks
Subject: Re: Measuring disk read times for Unix
Message-ID: <1991Feb28.210620.21205@intellistor.com>
Date: 28 Feb 91 21:06:20 GMT
References: <714@opus.NMSU.Edu> <23410002@misty.boeing.com>
Organization: Intellistor, Longmont, CO
Lines: 37

In article <23410002@misty.boeing.com> jsadler@misty.boeing.com (Jim Sadler) writes:
>>/ misty:comp.benchmarks / taylor@intellistor.com (Dick Taylor) /  3:30 pm  Feb 27, 1991 /
>>In article <714@opus.NMSU.Edu> pfeiffer@nmsu.edu (Joe Pfeiffer) writes:
>>>...
>>>In order to measure write times, I'm using the O_SYNC to flush my data
>>>to disk on each write.  So far so good.
>>>
>>
>>There are a number of ways to do it.  The niftiest that I ever found was
>>to use the mount() and unmount() system calls to unmount the filesystem
>>between each iteration of the benchmark.  One warning, though -- this
>	.
>Would it possible to regen the kernel with the buffer set to the lowest
>value, for the purpose of this type of test ?  Then you wouldn't have to
>pass as much data though to clean out the buffer or have the unwanted
>overhead as the mount(), unmount() way.  Of course if the overhead of
>cleaning out the buffer is the same or greater than un/mount() it's not
>such a great idea.
>
>jim

As it turns out, mount/unmount is quite quick (relative to typical benchmark
times, that is -- it's well under a second).  If you do your own timing (that
is, if you avoid crutches like /bin/time), there's no impact on program
performance and the impact on run time is minimal.  Any kernel hacking has the
nasty side effect that changing the buffer size can change your results, and
it's tough to shrink the buffers down to a size that can be cleared faster
than the unmount/mount can take place.  (Not to mention the fact that it's
kind of a trick to change this size at all under many memory-mapped file
systems).  What I've always really wanted is a syscall to invalidate either
the whole system cache or a piece of it qualified by file or directory.  I've
always thought it was ironic that system designers wouldn't be caught dead
without a way to invalidate the cache on, say, a processor, but they never
bother to extend the same feature to their users.  It's not terrible or
heinous or anything, just ironic.

			-- Dick Taylor