Path: utzoo!censor!geac!torsqnt!lethe!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!mintaka!spdcc!dirtydog!suitti
From: suitti@ima.isc.com (Stephen Uitti)
Newsgroups: comp.benchmarks
Subject: Re: Measuring disk read times for Unix
Message-ID: <1991Mar01.154559.4661@ima.isc.com>
Date: 1 Mar 91 15:45:59 GMT
References: <714@opus.NMSU.Edu> <23410002@misty.boeing.com> <1991Feb28.210620.21205@intellistor.com>
Sender: news@ima.isc.com (NEWS ADMIN)
Reply-To: suitti@ima.isc.com (Stephen Uitti)
Organization: Interactive Systems, Cambridge, MA 02138-5302
Lines: 40

In article <1991Feb28.210620.21205@intellistor.com> taylor@intellistor.com (Dick Taylor) writes:
>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 ?
>>
>As it turns out, mount/unmount is quite quick (relative to typical benchmark
>times, that is -- it's well under a second).  

Not on all systems.  Some systems convert free lists to bitmaps
on mount and back on umount.  For large filesystems with lots of
free space, this can take time.

On some systems, the free list, and therefore the file block
order is randomized by nearly any action.  So, to add to
repeatability, one such test used mkfs, or newfs between tests.

Maybe reading & writing separate files would be better.

Maybe accessing the raw disk would give more useful data.

The caching, read ahead and write behind are very important to
real throughput.  Disabling the buffer cache (if there is a
statically allocated one) may cause a good OS design to trash.

Stephen.
suitti@ima.isc.com
"We Americans want peace, and it is now evident that we must be
prepared to demand it.  For other peoples have wanted peace, and
the peace they received was the peace of death." - the Most Rev.
Francis J. Spellman, Archbishop of New York.  22 September, 1940