Return to BSD News archive
Path: sserve!manuel.anu.edu.au!munnari.oz.au!news.hawaii.edu!ames!haven.umd.edu!uunet!news.tek.com!vice!enky!espace!implode!agora!davidg
From: davidg@agora.rain.com (David Greenman)
Newsgroups: comp.unix.bsd
Subject: iozone bogusness
Message-ID: <BxE8q0.Czn@agora.rain.com>
Date: 8 Nov 92 10:49:11 GMT
Organization: Open Communications Forum
Lines: 79
Sorry for the "late" response here, but the first attempt at posting this
never made it through the net. Anyway...
>I only use iozone 1, just to be consistent and make the test more realistic.
>Most applications do not need more than 1 Megabyte of sequential access..
I don't know what you mean by 'realistic'; your results certainly aren't.
Using iozone with a larger value is necessary because, on most machines, the
filesystem cache is at least 1MB and using a test size of less than the cache
size will generate useless results.
To illustrate my point, here is what I get for write performance when I
do the same thing:
Writing the 1 Megabyte file, 'iozone.tmp'...0.483333 seconds
....
2169467 bytes/second for writing the file
>Writing the 1 Megabyte file, 'iozone.tmp'...3.333333 seconds
>Reading the file...2.483333 seconds
>
>IOZONE performance measurements:
> 314573 bytes/second for writing the file
> 422245 bytes/second for reading the file
>
>The test completed too quickly to give a good result
>You will get a more precise measure of this machine's
>performance by re-running IOZONE using the command:
>
>Julian's machine, 486/50, Bustek SCSI-2 1.3G hard-disk(?)
>
>IOZONE performance measurements:
> 683854 bytes/second for writing the file
> 499322 bytes/second for reading the file
>
It also seems pretty obvious by your read results that your filesystem
parameters have not been optimized; you are getting one 8K block per
revolution? I would guess that you have the 'rotdelay' filesystem parameter
set at 4ms (the default), which is less then optimal for today's CPUs and
disks. If your disk(s) have a read-ahead buffer, a 'rotdelay' parameter of
0ms will yield much better read results.
Here are the results of a 600MB Wren-5 (SCSI on 1542B) with read-ahead
cache enabled and 'rotdelay' set to 0ms:
Writing the 10 Megabyte file, 'iozone.tmp'...26.200000 seconds
Reading the file...9.333333 seconds
IOZONE performance measurements:
400219 bytes/second for writing the file
1123474 bytes/second for reading the file
I get the same figures on both a 386SX/25 and a 486DX/50 with either
Julian's SCSI code or the originaly SCSI driver.
Note that the results will vary depending on filesystem fragmentation and
other factors. The theoretical for this disk should be about 1500KB/sec; the
difference in the case of writes is due to writing only 8k/revolution (which
is expected when rotdelay is set to zero). I could possibly improve write
performance by optimizing rotdelay for writes, but this would be at the
expense of read performance. Since the number of sequential reads far exceeds
the number of sequential writes on my machine (and most machines), 0ms yields
the best overall results for disks with a readahead buffer/cache.
If your disk(s) don't have a read-ahead buffer, then a rotdelay setting of
between 1 and 3ms would be more appropriate. This will require some experi-
mentation. See the manual page for newfs, tunefs, and dumpfs. Changing this
parameter on a filesystem that is already full of files will have no affect.
rotdelay affects how blocks are allocated for new files. If your disk(s) are
mostly full already, than the remaining blocks might be too fragmented to
see much benefit. It is best to set this parameter before any files are
created on the filesystem.
Also note that the write results will be only half this if the filesystem
block size is 4KB rather than 8KB, which is one of several reasons why you
should always use 8KB blocks unless you are extremely short on disk space.
---
David Greenman
davidg%implode@percy.rain.com