performance measurement with dd

[Kenan Erdey]

Hi,

i run the below command in some servers.

timex dd if=/dev/zero bs=64k count=50000 | gzip -9 | dd of=/dev/null

Itanium 2 9340s
real 46.17
user 0.04
sys 1.45


POWER5
real 61.49
user 0.16
sys 1.18


Intel Xeon 5600
real 0m26.669s
user 0m23.720s
sys 0m0.860s

2530 Mhz SPARC64-VII
real 47.82
user 0.05
sys 4.18


I know this doesn't indicate a performance metric exactly. But between linux and unix servers there is a difference(linux on laptop run the command faster than aix,hpux). Also power seems to be run slower than others as unexpectedly. How can you explain this ? is this dd's behaviour ?

thanks.

[Duncan Edmonstone]

Could be many reasons, not least differing implementations of dd between the platforms, different memory speeds etc. etc.

One reason may well be down to how gzip is compiled - I would expect gzip is probably aimed more at x86 platforms these days, and I wouldn't be surprised if optimizations in teh compiler on x86 work much more effectively than those on Power/IA64/SPARC

What exactly are you trying to prove with this test? If you want straight-out memory/CPU tests, then SPECint and SPECfp probably give you a fairer reflection than any quick test like this (I can't believe I said that given my opinion of benchmarks in general!)

HTH

Dncan

[Duncan Edmonstone]

>> I wouldn't be surprised if optimizations in teh compiler on x86 work much more effectively than those on Power/IA64/SPARC

I just re-read that, and I don't think I was clear... I don't mean the compilers on x86 are _better_ at optimization, just that the gzip code has probably been written so that higher optimization levels on x86 don't cause issues (not necessarily the case on other platforms)

Another thought... what gzip release do you have on all these platforms - the same one? I think "gzip -h" should tell you.

HTH

Duncan

[Kenan Erdey]

ok, i tried againt without gzip. i just put it because specint is done with gzip etc..

intel: 0.11,
itanium 2:0.33
power5: 1.09.

this is my poor man's test :) just for cpu speed.

[Kenan Erdey]

>Could be many reasons, not least differing implementations of dd between the platforms, different memory speeds etc. etc.

in this test, is memory speed a factor ?

[Duncan Edmonstone]

>> in this test, is memory speed a factor ?

Hmmm now I think about it, possibly not with dd reading and writing only 64K at a time - more a test of CPU cache, and the inter-CPU links that are used.

On your laptop no doubt you have 1 CPU die, and possibly more than one CPU core. When the task runs, they are almost definately sharing the same CPU cache.

On the IBM and HP system, it kind of depends where the scheduler ends up putting the 2 dd processes - if they end up on the same socket you would expect good performance - on different sockets less so.

Have a read of this blog from Kevin Closson that might throw some more light on your test:

http://kevinclosson.wordpress.com/2010/01/05/an-intel-xeon-5400-system-that-outperforms-an-intel-5500-nehalem-ep-system-believe-it-or-know-it/

HTH

Duncan

[Kenan Erdey]

i will read it, but test on ibm was made on one core system( 5 ghz cpu). and also after removing gzip there was only one dd command.

[Duncan Edmonstone]

Ah, so you are saying after removing gzip you just ran:

timex dd if=/dev/zero bs=64k count=50000 of=/dev/null

If I run that on a system with 9340 processors I get:

# timex dd if=/dev/zero bs=64k count=50000 of=/dev/null
50000+0 records in
50000+0 records out

real 0.31
user 0.03
sys 0.27

Seems a little different from your values...

HTH

Duncan