Date: Sun, 22 Apr 2001 12:46:20 -0400 From: Seth <aberrant@superconductor.rush.net> To: Andrew Hesford <ajh3@chmod.ath.cx> Cc: freebsd-questions@freebsd.org Subject: Re: ATA100 read/write perofrmance disparity Message-ID: <20010422124619.A29944@superconductor.rush.net> In-Reply-To: <20010422110843.A99388@cec.wustl.edu>; from ajh3@chmod.ath.cx on Sun, Apr 22, 2001 at 11:08:43AM -0500 References: <20010422114836.A6234@superconductor.rush.net> <20010422110843.A99388@cec.wustl.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Apr 22, 2001 at 11:08:43AM -0500, Andrew Hesford wrote:
> It seems to me that a dd test is not very reliable. For one thing, if
> you make the block size 1, and increase the count accordingly, the time
> to write the file will skyrocket. Try these two commands to see what I
> mean:
>
> time dd if=/dev/zero of=test bs=1 count=1474000
>
> and
>
> time dd if=/dev/zero of=test count=1 bs=1474000
>
Yup. My point here was to try to document what I perceived as
sluggish disk performance -- not necessarily do raw benchmarking.
You're absolutely right, though, about block sizes making a difference.
However, if you compare the dd results with the dd results when
run on the old SCSI disks (don't have the exact numbers handy, but
they were around 7-8 MB/sec for both read and write), you see evidence
that there may be a problem. ("Problem", of course, being defined as
"unexpected behavior".) It certainly seems that disk writes are being
limited by CPU (see bonnie++ results, below)
> Of course, another thing to note is that you are using a multitasking
> system, and other things are going on in the background. This is why
> you run "time". Time will report the total elapsed real-world time
> (which is what dd uses), but it will also decompose this into system and
> user actual computing time. System sime is the time the kernel spends
> doing this task, user time is time the userland program spends doing
> this task. To see the difference, look at the output from my first timed
> dd above:
>
In this case, the system is almost completely idle, but here's the
dd "write", timed:
268435456 bytes transferred in 34.603850 secs (7757387 bytes/sec)
0.054u 8.725s 0:34.65 25.3 89+263k 19+2050io 0pf+0w
> For a real disk I/O benchmark, try bonnie. It's in the ports tree.
>
Using bonnie++ with -s256, I get:
Using uid:65534, gid:65534.
Writing with putc()...done
Writing intelligently...done
Rewriting...done
Reading with getc()...done
Reading intelligently...done
start 'em...done...done...done...
Create files in sequential order...done.
Stat files in sequential order...done.
Delete files in sequential order...done.
Create files in random order...done.
Stat files in random order...done.
Delete files in random order...done.
Version 1.01 ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
256M 7260 83 7501 22 2845 11 6137 87 25597 47 124.6 2
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 236 91 15170 99 3382 99 250 91 360 98 690 85
,256M,7260,83,7501,22,2845,11,6137,87,25597,47,124.6,2,16,236,91,15170,99,3382,99,250,91,360,98,690,85
(not sure how to read this, it's garbled like this on my system.)
The CPU appeared pegged at around 95% sys for most of the "Create files" and
"Delete files" tests. Other times, it was a mix of sys/int and idle.
This indicates to me that the CPU is the limiting factor here -- it is,
after all, a relatively sluggish PPro 200. Is this a sane conclusion to
reach given the evidence?
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010422124619.A29944>