Date: Fri, 7 Apr 1995 09:34:46 -0700 (PDT) From: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com> To: taob@gate.sinica.edu.tw (Brian Tao) Cc: freebsd-current@FreeBSD.org Subject: Disk performance (was Re: Label/slices : how to add a disk ?) Message-ID: <199504071634.JAA07710@gndrsh.aac.dev.com> In-Reply-To: <Pine.BSI.3.91.950407202857.20266D-100000@aries.ibms.sinica.edu.tw> from "Brian Tao" at Apr 7, 95 08:51:32 pm
next in thread | previous in thread | raw e-mail | index | archive | help
>
> On Fri, 7 Apr 1995, Rodney W. Grimes wrote:
> >
> > This is on a 16MB machine, P54C-90, NCR810 controller iozone 2.01: The
> > buffer cache become ineffective at 8MB transfer size, but still skewed
> > the numbers some (~200K/sec).
Ooppss. left the drive model out, these tests where on a Micropolis 2112,
1Gbyte drive.
> [...]
> > Writing the 128 Megabyte file, 'iozone.tmp'...53.343750 seconds
> > Reading the file...51.906250 seconds
> >
> > IOZONE performance measurements:
> > 2516090 bytes/second for writing the file
> > 2585772 bytes/second for reading the file
>
> How much CPU is being eaten on your machine while performing the
> benchmark? My machine is a PCI 486DX4/100 machine (16 megs) with the
> NCR53810 controller and a Quantum Empire 1080. iozone 2.01:
>
...
>
> 'top' shows this (sometime during the latter half of the run):
>
> PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
> 20444 root 48 0 244K 424K run 0:41 51.76% 50.35% iozone
I get the following stats using 3 different utilities (I was glad to
see that thy agreed within reason!): [We are not comparing apples to
apples here, I am running on a P54C-90, your tests where on a DX4/100]
systat -vm processor mode line:
19.3%Sys 2.0%Intr 0.5%User 0.0%Nice 78.3%Idl
time iozone 128 8192:
0.1u 20.8s 1:46.42 19.6% 30+285k 2237+16675io 0pf+0w
top:
PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
138 root -6 0 248K 572K sleep 0:12 19.29% 18.46% iozone
> Is this a reasonable figure? At 3000000 bytes/sec using 8192-byte
> blocks, the CPU is shuttling about 366 I/O operations a second or
> about 2.7 ms per operation. That sounds like "a lot of time" from a
> CPU's viewpoint, most of it spent waiting for the disk (I assume?).
You forgot that the CPU is not 100% busy. What that 2.7mS number
relates to closest is the fact that 8192 bytes fly under the disk head
in ~2.7mS. Your Quantum 1080 is a 5400 RPM (90 RPS) drive, meaning
it takes 11.11mS for one revolution, turning a few more numbers through
xcalc 2.7mS/11.11mS * (16 sectors per 8192 bytes)=65 sectors/revolution.
I could check this if I had the number of cylinders reported by the
probe (my Quantum data sheet only shows total sectors and # of heads),
but I suspect that the average sectors/track is very close to 65 for
this drive.
>
> BTW, out of curiosity, if I do something like this:
>
> % time dd if=/dev/zero of=/dev/null bs=102400 count=10240
> 10240+0 records in
> 10240+0 records out
> 1048576000 bytes transferred in 30 secs (34952533 bytes/sec)
> 0.171u 28.688s 0:29.33 98.3% 56+529k 0+1io 0pf+0w
>
> ... just what am I measuring? CPU-to-RAM bandwidth? CPU-to-cache
> speed? Or nothing at all useful? :)
It is hard to be sure exactly what is being measure here, It is
a combination of bzero speed, RAM -> CPU and CPU <-> cache bandwidths.
If you think about every step along the way you could figure it out.
Here are a few of the steps.
a) bzero the 10k input buffer from /dev/zero.
b) either page flip or copy out the buffer to user space
c) copy the input buffer to the output buffer (reads here
are probably pure cache hit, the writes may or may not
be in the cache).
d) Call the kernel to do the output to /dev/null, no copy
occurs here, the fp is just advanced.
I tried to correlate the number with a memory benchmark program on
my system and it comes up to be faster than the CPU -> main memory
write bandwidth but about 1/2 the speed of main memory read bandwidth.
Using a 512k bs pushed the speed up a bit and makes sure we trash
my 256K cache, so I suspect the number is a combination of memory
read and write bandwidth, with memory write bandwidth having a very
heavy factor.
--
Rod Grimes rgrimes@gndrsh.aac.dev.com
Accurate Automation Company Custom computers for FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504071634.JAA07710>