|
Home > Archive > Unix Programming > October 2004 > hard disk benchmarking - HOWTO
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
hard disk benchmarking - HOWTO
|
|
|
| Hello,
I want to write a small benchmarking tool to see the performance of my
harddisk. How to I go about doing this? I was thinking of writing some
random characters to a swap file and reading it back. Will this do?
regards,
GVK
| |
| Steve Graegert 2004-10-29, 5:51 pm |
| GVK wrote:
> Hello,
> I want to write a small benchmarking tool to see the performance of
> my harddisk. How to I go about doing this? I was thinking of writing
> some random characters to a swap file and reading it back. Will this do?
I don't think this alone will do it. You will need to think about
important points before writing a benchmarking tool:
1.) What about caching? Caching influences a harddisk's performance
significantly. Most SCSI disks allow turning on and off their internal
cache.
2.) What about the OS and its underlying filesystem? Not to mention the
OS's I/O library (buffering, etc.).
3.) Make tests for different blocksizes and file sizes (1K to 2 GB for
example.
What about measurements? You need to implement a sophisticated algorithm
to make sure that the results are true and not influenced by timing
errors. There are several other points I am not aware of right now, but
others will, for sure.
But hey, try it! I'm going to help whenever I can. Developing a bechmark
is not as trivial as it might seem to be at first.
\Steve
| |
| Mark Rafn 2004-10-29, 5:52 pm |
| GVK <vamsee_k@students.iiit.net> wrote:
> I want to write a small benchmarking tool to see the performance of my
>harddisk.
Sorry for this somewhat glib answer, but there are dozens of these already
available. On Linux, hdparm -T gives you a starting point.
>How to I go about doing this?
1) decide which performance characteristics you want to test.
2) test them.
>I was thinking of writing some
>random characters to a swap file and reading it back. Will this do?
It will do if you care about how fast the system can write characters to a
file and read them back. If you write enough data, you'll probably even
get a sense of media transfer speed. If you'd rather know bus transfer speed,
system block cache speed, random access latency, filesystem write performance
on large or small files, or performance for a given app, you'll need a
different benchmark.
--
Mark Rafn dagon@dagon.net <http://www.dagon.net/>
| |
| Nick Landsberg 2004-10-29, 5:52 pm |
| Steve Graegert wrote:
> GVK wrote:
>
>
>
> I don't think this alone will do it. You will need to think about
> important points before writing a benchmarking tool:
>
> 1.) What about caching? Caching influences a harddisk's performance
> significantly. Most SCSI disks allow turning on and off their internal
> cache.
>
> 2.) What about the OS and its underlying filesystem? Not to mention
> the OS's I/O library (buffering, etc.).
>
> 3.) Make tests for different blocksizes and file sizes (1K to 2 GB
> for example.
>
> What about measurements? You need to implement a sophisticated algorithm
> to make sure that the results are true and not influenced by timing
> errors. There are several other points I am not aware of right now, but
> others will, for sure.
>
> But hey, try it! I'm going to help whenever I can. Developing a bechmark
> is not as trivial as it might seem to be at first.
>
> \Steve
All very good points, Steve. I would just like to add
a few more.
The elements defining hard-disk performance are influenced
by the way the disk will be used by applications.
For example, if your application is something like
a database system where the next request could be
for a record anywhere on the disk, the disk latency
is dominated by the average seek time. If your
application writes huge gobs of data to contiguous
disk sectors and tracks, one would guess that the
data transfer rate dominates.
In other words, I/O time can be sub-divided into:
Seek Time + Rotational Latency + Transfer Rate.
Seek Time will depend on how far the physical disk
blocks are from one another and how efficiently the driver
software orders the the I/O's. If the next physical read
is only a track away, this time is small. If it's half
the disk away (on average), you can look up the "average
seek time" in the maufacturer's specs. Most modern
drives have an average seek time of about 6-8 ms.
(but check the maufacturer's specs!). If it's closer
than half a disk away, i.e. you are hitting a particular
partition pretty hard and there is no other traffic to
that disk, then you can adjust this downwards mostly
in proportion to the size of the partition vs. the
size of the whole disk.
Once the physical mechanism gets to the right track,
there is rotational latency. You can expect to be
(on average) half a rotation away from the actual sector
you need to be at.
At 7200 RPM, that's 120 rotations per second, or about
8 milliseconds (if I did the arithmetic correctly).
Half a rotation would be about 4 milliseconds.
Adjust the numbers for mirrored drives, downwards
for reads, upwards for writes.
So, in my experience you can expect most drives
to be capable of about 100 I/O's per second at
100% drive utilization. I, personally, wouldn't
want 100% utilization of any resource, so I would
use a figure something like 50-75 random I/O's
per second.
All of the above was for random I/O's. The equation
changes when you're dealing with something like
a bulk copy of Disk A to Disk B using a utility like
DD on the raw devices. Seek times are not an issue since
you will be copying whole tracks at a time and then
only seeking to the next track (much, much less than
"average seek time"), and the rotational latency
comes into play only after a whole track has been
written. In this case, the transfer rate and the
bus speeds tend to dominate. Note that manufacturers
tend to emphsize these particular rates in their
glossy brochures since these are more impressive
than the random I/O rates.
As far as writing/reading to/from a swapfile, it will
probably not pick up the seek latencies at all
since the file will be localized to some small
area of the disk. I would access the *raw* device
which encompasses the whole disk, and do random
reads of blocks of data, making sure that
the range of randomness was all the blocks
on the disk[1]. Report back the blocks read
every minute, and run the test for at least
15 minutes.
Just my opinions.
NPL
[1] - Back in the old days, when disk drives were the
size of washing machines, you could actually make the
suckers move across the floor if you adjusted the
parameters appropriately. This was called "walking
a drive." It was frowned upon by management. 
--
"It is impossible to make anything foolproof
because fools are so ingenious"
- A. Bloch
| |
|
| Steve Graegert wrote:
>
> I don't think this alone will do it. You will need to think about
> important points before writing a benchmarking tool:
>
> 1.) What about caching? Caching influences a harddisk's performance
> significantly. Most SCSI disks allow turning on and off their internal
> cache.
>
> 2.) What about the OS and its underlying filesystem? Not to mention
> the OS's I/O library (buffering, etc.).
>
> 3.) Make tests for different blocksizes and file sizes (1K to 2 GB
> for example.
>
> What about measurements? You need to implement a sophisticated algorithm
> to make sure that the results are true and not influenced by timing
> errors. There are several other points I am not aware of right now, but
> others will, for sure.
>
> But hey, try it! I'm going to help whenever I can. Developing a bechmark
> is not as trivial as it might seem to be at first.
>
I guess I forgot to mention all these point. You are right. If I'm gonna
be writing any benchmark, all these things should be taken care of.
Thanks a lot. Looks like there's a lot of study I got to do :-)
GVK
| |
|
| GVK wrote:
> Hello,
> I want to write a small benchmarking tool to see the performance of
> my harddisk. How to I go about doing this? I was thinking of writing
> some random characters to a swap file and reading it back. Will this do?
>
Check out bonnie++, it tests both block and random access.
http://www.coker.com.au/bonnie++/
Ian
| |
| Juha Laiho 2004-10-31, 5:49 pm |
| SPAMhukolautTRAP@SPAMattTRAP.net said:[vbcol=seagreen]
>Steve Graegert wrote:
....
Number of good points snipped to add still more;
Data transfer speeds may (and often do) vary between inner and outer
cylinders, the outer cylinders providing higher bandwidths.
Transfer rate ceilings in real systems may come from multiple sources,
not just from disks themselves -- examples:
- combined transfer rate of disks connected to a single channel
exceeding bandwidth of the channel
- combined transfer rate of disks (or multiple channels) exceeding
bandwidth of system I/O buses
- even CPU may become the bottleneck (thus less often nowadays)
.... so testing single disks may not be feasible (except to help determine
location of the bottleneck).
--
Wolf a.k.a. Juha Laiho Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)
|
|
|
|
|