I did a write IO test in IBM P690 and HP SUPERDOME.
When I tested the local disks in P690,use this:
----------------------------------------------------
time dd if=/dev/zero of=/tmp/test.dat bs=1024 count=300000
300000+0 records in
300000+0 records out
real 0m42.01s
user 0m0.85s
sys 0m6.18s
The Speed should be 7MB/s almost,and the P690 is running none except
this.

When I tested the local disks in the SUPERDOME,
---------------------------------------------
time dd if=/dev/zero of=/tmp/test.dat bs=1024 count=300000
300000+0 records in
300000+0 records out

real 2.9
user 0.2
sys 2.5
The Speed should be 100MB/s almost!!!!
=======================================
I used the same method to test the Storage of HDS 9980,which is
connected to the P690 and SUPERDOME.
-----------------------------
the result of P690 is 56MB/s almost,and result of SUPERDOME is 90MB/s
almost !!!

I'll cry for explaining this to the customer.
Anyone can help me to explain this?

In article <a2efdbbd.0411112105.d210392@posting.google.com> ,
dean.sun@gmail.com says...
> I did a write IO test in IBM P690 and HP SUPERDOME.
> When I tested the local disks in P690,use this:
> ----------------------------------------------------
> time dd if=/dev/zero of=/tmp/test.dat bs=1024 count=300000
> 300000+0 records in
> 300000+0 records out
> real 0m42.01s
> user 0m0.85s
> sys 0m6.18s
> The Speed should be 7MB/s almost,and the P690 is running none except
> this.
>
> When I tested the local disks in the SUPERDOME,
> ---------------------------------------------
> time dd if=/dev/zero of=/tmp/test.dat bs=1024 count=300000
> 300000+0 records in
> 300000+0 records out
>
> real 2.9
> user 0.2
> sys 2.5
> The Speed should be 100MB/s almost!!!!
> =======================================
> I used the same method to test the Storage of HDS 9980,which is
> connected to the P690 and SUPERDOME.
> -----------------------------
> the result of P690 is 56MB/s almost,and result of SUPERDOME is 90MB/s
> almost !!!
>
> I'll cry for explaining this to the customer.
> Anyone can help me to explain this?
>
Now I'm no expert on HP/UX but is their /tmp a RAM filesystem? And how
many paths to the disk get used? And what is the time taken for a second
test, following from the first?

"Dean" <dean.sun@gmail.com> schrieb im Newsbeitrag
news:a2efdbbd.0411112105.d210392@posting.google.co m...
> I did a write IO test in IBM P690 and HP SUPERDOME.
> When I tested the local disks in P690,use this:
> ----------------------------------------------------
> time dd if=/dev/zero of=/tmp/test.dat bs=1024 count=300000
> 300000+0 records in
> 300000+0 records out
> real 0m42.01s
> user 0m0.85s
> sys 0m6.18s
> The Speed should be 7MB/s almost,and the P690 is running none except
> this.
>
> When I tested the local disks in the SUPERDOME,
> ---------------------------------------------
> time dd if=/dev/zero of=/tmp/test.dat bs=1024 count=300000
> 300000+0 records in
> 300000+0 records out
>
> real 2.9
> user 0.2
> sys 2.5
> The Speed should be 100MB/s almost!!!!
> =======================================
> I used the same method to test the Storage of HDS 9980,which is
> connected to the P690 and SUPERDOME.
> -----------------------------
> the result of P690 is 56MB/s almost,and result of SUPERDOME is 90MB/s
> almost !!!
>
> I'll cry for explaining this to the customer.
> Anyone can help me to explain this?

Hallo Dean,

I would guess that the difference of the first comparison can be explained
by caching. 7MB/s sounds 'normal' for accessing one or two SCSI disks
depending on lv layout. 100MB/s can not be done with the same number of
physical disks.
Second comparison looks to me like you where writing to 7 or 8 physical
disks that would result in a throughput of 56MB/s (for serial I/O) while
90MB/s might have to do with caching again (i.e. different handling of this
I/O).

These values for I/O can differ to a great extent depending on lv layout and
caching. E.g. I have seen p690 writing to 6+p hdisks RAID5 devices 100% busy
and 2MB/s (!) I/O (because of some bad misconfiguration) as well as 75% busy
with 56MB/s on the same device after the config was fixed. This was almost
the maximum (constant) I/O the physical disks could handle. When the amount
of data fitted into the fastwrite cache the peak value almost doubled. Can
you see the picture?
Now, if I wanted to compare p690 with Superdome I would either use no
caching at all (neither on the operating system layer nor on the hardware
layer) for the comparison or have each system fine tuned by some dedicated
expert. The second variation seems more appropriate to me actually. Only
this way you can be sure that you do not compare apples with pears. Just my
5c.

Regards,
Andreas

Also check that you have 300MB free space in /tmp.
I just did the same test on my p630 workstation ...
time dd if=/dev/zero of=/junk/dat bs=1024 count=30000>
300000+0 records in
300000+0 records out
real 0m4.79s
user 0m1.00s
sys 0m6.21s

Also note the AIX likes 4KB disk writes so I tried
time dd if=/dev/zero of=/junk/dat bs=4k count=75000
75000+0 records in
75000+0 records out
real 0m2.33s
user 0m0.29s
sys 0m2.97s

Also, remember that this write test is not actually doing disk I/O - the
data is put in the filesystem cache and written later. So kernel tuning on
the filesystem cache options and the amount of memory can effect the
performance more than the disks involved!!

Hope this helps, Nigel nag@uk.ibm.com

Dean wrote:
> I did a write IO test in IBM P690 and HP SUPERDOME.
> When I tested the local disks in P690,use this:
> ----------------------------------------------------
> time dd if=/dev/zero of=/tmp/test.dat bs=1024 count=300000
> 300000+0 records in
> 300000+0 records out
> real 0m42.01s
> user 0m0.85s
> sys 0m6.18s
> The Speed should be 7MB/s almost,and the P690 is running none except
> this.
>
> When I tested the local disks in the SUPERDOME,
> ---------------------------------------------
> time dd if=/dev/zero of=/tmp/test.dat bs=1024 count=300000
> 300000+0 records in
> 300000+0 records out
>
> real 2.9
> user 0.2
> sys 2.5
> The Speed should be 100MB/s almost!!!!
> =======================================
> I used the same method to test the Storage of HDS 9980,which is
> connected to the P690 and SUPERDOME.
> -----------------------------
> the result of P690 is 56MB/s almost,and result of SUPERDOME is 90MB/s
> almost !!!
>
> I'll cry for explaining this to the customer.
> Anyone can help me to explain this?


On a 7043-150

time dd if=/dev/zero of=/dev/null count=300000
300000+0 records in.
300000+0 records out.

real 0m12.72s
user 0m4.58s
sys 0m8.14s

Don't assume that /dev/zero and /dev/null times are negligable. They
aren't necessarily written efficiently or intended for use in benchmarks.

-- Jason

On 12/11/04 5:05 am, in article
a2efdbbd.0411112105.d210392@posting.google.com, "Dean" <dean.sun@gmail.com>
wrote:

> I did a write IO test in IBM P690 and HP SUPERDOME.
> When I tested the local disks in P690,use this:
> ----------------------------------------------------
> time dd if=/dev/zero of=/tmp/test.dat bs=1024 count=300000
> 300000+0 records in
> 300000+0 records out
> real 0m42.01s
> user 0m0.85s

> I'll cry for explaining this to the customer.
> Anyone can help me to explain this?

I'm sure you are not trying to sell the benefits of running dd to the
customer. Performance comparisons are very hard to quantify properly unless
you install an exact duplicate of the app / database on both systems and
measure actual throughput by simulating the customers expected experience -
expensive and hard to do and even then, tuning would probably improve
performance on either system.

Unfortunately this usually comes down to the preference and comfort factor
of the customer i.e. If they are used to running HP, then stick with HP.
Same with IBM unless there is an overwhelming reason to use either i.e. You
want to use LPARing specifically on IBM / you have more HP people than IBM /
you need high availability rather than absolute performance etc. From
experience of HP / Sun and IBM, these systems can all be coaxed into giving
adequate performance to customer requirements unless you are vying for the
Super500 computer award then obviously go for IBM ;0)

dean.sun@gmail.com (Dean) wrote in message
news:<a2efdbbd.0411112105.d210392@posting.google.c om>
....
> I did a write IO test in IBM P690 and HP SUPERDOME.
> When I tested the local disks in P690,use this:
> I used the same method to test the Storage of HDS 9980,which is
> connected to the P690 and SUPERDOME.
> -----------------------------
> the result of P690 is 56MB/s almost,and result of SUPERDOME is 90MB/s
> almost !!!
>
> I'll cry for explaining this to the customer.
> Anyone can help me to explain this?


Maybe You start thinking about it beforce crying?

at first
- unless You plan to be swapping a lot, 56MB/s would still be ok.
- maybe You should consider filesystem caching as a reason? It's
benefit will disappear with 10 Oracle databases running
If You meant to test disk throughput use
vgdisplay -v /dev/vg00 | grep /dev/dsk # get disk disk below /tmp/
dd if=/dev/rdsk/<harddisk> of=/dev/null bs=1024k # look how fast it is
I guess You know how to do the same on AIX?
- I'm quite sure the cpu time used in /dev/null is quite negletible on
a p690, especially for something like 100MB/s - we might talk about
that on a 200MHz sgi doing >800MB/s.
- has it ever occured to You the the superdome might simply have been
shipped with different disks? (if hp used 73GB 15K drives in the
surestore 2100, 100MB/s would be a fair guess)
- Did You look into filesystem mount parameters? (e.g. mounting on
hp-ux with 'nodatainlog' would surely be a point to search at for the
difference in performance)

- also both 56 and 100MB/s are just fast, not really very fast, unless
the Hitachi is highly loaded. For external storage I'd expect
something better, so
some baseline tuning might be reasonable.
- check the fc adapters - maybe it's something trivial like a broken
gbic in
the p690, also check if it's 1 or 2Gbit FC Ports they are connected
to.

Two general points:

The Superdome IMHO has a bad ratio between cpu's and I/o. Ask HP how
many PCI-X slots You get when using the usual configuration of 4 I/O
drawers. If I remember correctly it's only 4 per drawer. Which is not
so much for 128 CPUs.
If Your customer really needs high I/O potential, this might not be
the perfect choice, and the p690 will probably much better suited.

To some of the other posters:
I agree in that dd really is not a reasonable benchmark. But first
things come first! Horrible performance on /tmp? (and 7MB/s is far
from what one should expect today, not even 4 years ago). I wouldn't
care for the difference in between 30 and 40 MB/s, but to get down to
7MB/s something has to be wrong.
In addition to that, if it were a memory filesystem and only made
100MB/s it would be even worse
I get 3-7MB/s on my stone-age 4.3GB seagate disks in a B50 at home.
both the p690 and the superdome a bit heavier on the wallet, and it's
just
fair Dean expects a bit more performance.

Regards,
Florian

On 16/11/04 5:43 pm, in article
29a7918d.0411160943.48dd2444@posting.google.com, "Florian Heigl"
<florian.heigl@gmx.de> wrote:

> dean.sun@gmail.com (Dean) wrote in message
> news:<a2efdbbd.0411112105.d210392@posting.google.c om>
> ...
>
>> I did a write IO test in IBM P690 and HP SUPERDOME.
>> When I tested the local disks in P690,use this:
>> I used the same method to test the Storage of HDS 9980,which is
>> connected to the P690 and SUPERDOME.

> To some of the other posters:
> I agree in that dd really is not a reasonable benchmark. But first
> things come first! Horrible performance on /tmp? (and 7MB/s is far
> from what one should expect today, not even 4 years ago). I wouldn't
> care for the difference in between 30 and 40 MB/s, but to get down to
> 7MB/s something has to be wrong.
> In addition to that, if it were a memory filesystem and only made
> 100MB/s it would be even worse
> I get 3-7MB/s on my stone-age 4.3GB seagate disks in a B50 at home.
> both the p690 and the superdome a bit heavier on the wallet, and it's
> just
> fair Dean expects a bit more performance.
>
> Regards,
> Florian

That is correct - but as you know if you work with big systems, there are so
many factors that it can be impossible to diagnose without looking at
exactly how the system is set up and configured. For example, I was asked to
look at a large Sun installation where the backup (of all things) was
running incredibly slow. After investigating, it appeared that the new
version of Solaris combined with an SDLT 320 drive in the tape array and a
particular type of ultra-SCSI-3 card meant that the Solaris Volume Manager
internal mirroring strategy had to be changed from round-robin to
concurrent. A simple command in Solaris and this changed output from 3Mb/s
to 30Mb/s. Sun were not aware of this but they are now.

Incredible performance issues can have many causes and sometimes have a
simple solution. Sometimes the don't. My point is that running arbitrary
performance benchmarks is not the correct way to diagnose a problem. As you
quite rightly demonstrate Florian, experience is a big player here and in my
opinion, that is the most important factor that differentiates a great
system administrator from a mediocre one, but also luck ( I know, hope
management aren't reading this but haven't you investigated a major problem
to discover that it's suddenly solved itself but you take the credit!!!) and
the ability to think laterally but also very importantly to really
understand what is going on!

That's why they pay us lots of money to run their computers IMHO!