Tux

...making Linux just a little more fun!

2-cent tip: Getting the "true" transfer rate during disk I/O benchmark

Mulyadi Santosa [mulyadi.santosa at gmail.com]


Sun, 24 Feb 2008 15:23:23 +0700

So say you want to test how fast your disk does writing operation. You might do this:

dd if=/dev/zero of=/mount/point/of/your/partition/testfile bs=4K count=256M

It will write 1GB file to the target partition. But one thing you might don't know is that the filesystem system do it in so called "write back" style. In this mode, data actually transit in temporary cache before actually being flushed to the disk. As the result, you get faster I/O speed.

How to get the real number then? Try to add "oflag=sync" as the option of dd. Then repeat the test, possibly by combining "dd" and "time" to get real/sys/user time statistic. This way, writing will be done synchronously i.e a block of data will be pushed to the disk before next blocks are going to be written.

Other benchmark program also provide you the same mode. Check the related documentations so you really know the meaning of the numbers you get. Also, as the rule of thumb, write something bigger than your L2 (or L3, if you have it) cache size, so I/O is done mostly between RAM and the disk, not originated CPU cache. Cache is thousands time faster than RAM, which also gives you another layer of "speed illusion".


Top    Back


Karl-Heinz Herrmann [kh1 at khherrmann.de]


Sun, 24 Feb 2008 20:07:15 +0100

On Sun, 24 Feb 2008 15:23:23 +0700 "Mulyadi Santosa" <mulyadi.santosa@gmail.com> wrote:

> So say you want to test how fast your disk does writing operation. You
> might do this:
> dd if=/dev/zero of=/mount/point/of/your/partition/testfile bs=4K
> count=256M

Depending on your RAM size this might not be sufficient due to caching.

> It will write 1GB file to the target partition. But one thing you
> might don't know is that the filesystem system do it in so called
> "write back" style. In this mode, data actually transit in temporary
> cache before actually being flushed to the disk. As the result, you
> get faster I/O speed.

I usually use

hdparm -t -T 
/dev/md5:
 Timing cached reads:   1276 MB in  2.00 seconds = 637.36 MB/sec
 Timing buffered disk reads:  488 MB in  3.01 seconds = 162.26 MB/sec

if I'm in a hurry and want some numbers (will only do read).

If I want a more comprehensive disk performance I use bonnie or bonnie++

To reduce caching effects It uses twice your RAM as test file size and it will run not only block-access but also rather inefficient character wise access to assess seek performance (as an aside: SD-cards have almost the same performance per char as per block). You also get read, write and rewrite performance as well as massive random seeks from bonnie.

Version  1.03       ------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
blackbox         4G 37381  90 166777  50 56503  23 41093  90 134301  28 344.0   1
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 +++++ +++ +++++ +++ +++++ +++ 32021  86 +++++ +++ 32188 100
blackbox,4G,37381,90,166777,50,56503,23,41093,90,134301,28,344.0,1,16,+++++,+++,+++++,+++,+++++,+++,32021,86,+++++,+++,32188,100

%CP is CPU usage to see if disk or CPU is maxed (typically in Chr mode only).

Funny enough -- this 2 disk-raid0 is better in writing than reading. Then the hdparm result is close to the write throughput of 160MB/s. light system load in the write? Guess just shows how fickle disk performance measuring can be :-)

I'm not sure that I/O flag you mentioned is sufficient to stop all caching, manpage/source of bonnie was mentioning lots of problems to get accurate numbers.

K.-H.


Top    Back


Mulyadi Santosa [mulyadi.santosa at gmail.com]


Mon, 25 Feb 2008 11:07:44 +0700

Hi :)

First of all, thank you for adding some thoughts...

On Mon, Feb 25, 2008 at 2:07 AM, Karl-Heinz Herrmann <kh1@khherrmann.de> wrote:

>  Depending on your RAM size this might not be sufficient due to caching.

Absolutely correct, I should mention it too.

>  I usually use
>  hdparm -t -T
>  /dev/md5:
>   Timing cached reads:   1276 MB in  2.00 seconds = 637.36 MB/sec
>   Timing buffered disk reads:  488 MB in  3.01 seconds = 162.26 MB/sec
>
>
>  if I'm in a hurry and want some numbers (will only do read).

Correct again. Anyway, I skipped about hdparm since I assume many people already knows about it.

>  If I want a more comprehensive disk performance I use bonnie or bonnie++

yeah, dd is too simple. Maybe I should clarify my tip as "no brainer way to get disk I/O speed" :D

>  To reduce caching effects It uses twice your RAM as test file size and
>  it will run not only block-access but also rather inefficient character
>  wise access to assess seek performance (as an aside: SD-cards have
>  almost the same performance per char as per block). You also get read,
>  write and rewrite performance as well as massive random seeks from bonnie.

correct, rewrite case is also important to watch since there is a chance some data are already cached in hard disk internal cache.

>  Funny enough -- this 2 disk-raid0 is better in writing than reading.
>  Then hdparm result is close to the write throughput of 160MB/s.
>  light system load in the write? Guess just shows how fickle disk
>  performance measuring can be :-)
yeah, been there done that too actually when I wrote about I/O benchmarking for SysAdmin Magazine. Initially, I think disk benchmark was damn easy...but later I found myself completely wrong.

>  I'm not sure that I/O flag you mentioned is sufficient to stop all
>  caching, manpage/source of bonnie was mentioning lots of problems to
>  get accurate numbers.

Yup, shame on me :) So, I hope the reader read it with many grains of salt :) Mr Okopnik, anything you want to add? (At least, if it's not going to 2 cent tips, it is worth to be mentioned in mailbag)

regards,

Mulyadi.


Top    Back