I'm a member of
Quicksearch
Codenews Search
Disclaimer
The individual owning this blog works at Sun Microsystems GmbH in Germany, a subsidiary of Oracle. The opinions expressed here are his own, are not necessarily reviewed in advance by anyone but the individual author, and neither Oracle nor any other party necessarily agrees with them.
Navigation
Categories
About this blog- Apple
- iPhone
- Aviation
- Bahn
- Begriffe des Lebens
- Blogosphere
- Braindump
- Business Travel
- CANBOX
- CeBIT
- CEC
- Computing
- del.icio.us
- Fundsache
- General
- HHOSUG
- i hate sundays
- Kochen
- Mindfuck
- Movies
- Music
- On Benchmarketing
- Persoenliches Pech
- Photographie
- policy of ...
- Privacy
- Recommended Blogs
- Security
- Solaris
- Strange Days
- Sun/Oracle
- suncec2007
- suncec2008
- Technology
- The IT Business
- Toolbox
- Travel
- Work
Peoplesoft NA Payroll 240k benchmarks with 16 streams
Tuesday, January 26. 2010
One of the most annoying experiences of the last year was the "discussion" with Steve A. because of an PeopleSoft benchmark. I won't reiterate on this, but you may read about this issue at the article, that started the "discussion" (BTW: Didn't got an apology for his accusations). However i want to give you some hard numbers to proof my statements at this time. Giri Mandalika wrote about the newest addition to the Peoplesoft Benchmark series: There is now a benchmark result with 16 job streams instead of 8 stream on a Sun SPARC Enterprise M4000 with a F5100.
The result is really impressive. Whereas the gap between the HP solution and the Sun solution was just 33% at 8 job streams, the 16 streams result shows, that the Sun solution was able to deliver 55% more performance than the HP solution at 16 streams as well (Steve A. ... you shouldn't have asked for a 16-streams result
). Interestingly there is still headroom on the system. The M4000 runs at 50% utilization in this benchmark. And before you ask: The benchmark environment didn't change ... they just used more job streams.
The result is really impressive. Whereas the gap between the HP solution and the Sun solution was just 33% at 8 job streams, the 16 streams result shows, that the Sun solution was able to deliver 55% more performance than the HP solution at 16 streams as well (Steve A. ... you shouldn't have asked for a 16-streams result
). Interestingly there is still headroom on the system. The M4000 runs at 50% utilization in this benchmark. And before you ask: The benchmark environment didn't change ... they just used more job streams.
Trackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
Keine Wunder... allein der Platten I/O wird einiges davon ausmachen.
Yup ... ist nur schoen den Nachweis in Form eines Whitepapers zu haben, das sich HP beim letzten mal nur mit den 16 Threads in die Nähe von Suns Ergebnis gebracht hat und das Sun sogar den Unterschied bei 16 Streams noch vergroessern konnte 
Ansonsten habe ich ja nicht umsonst von "Solution" und nicht von "Server" gesprochen
Ansonsten habe ich ja nicht umsonst von "Solution" und nicht von "Server" gesprochen
1. the result is impressive (what is utilization of HP system?), but it makes me wonder WHY not make benchmark at 100% utilization? WHY benchmarking half-idle systems?
2. Side note: given such poor results of Itanium I just CAN'T understand WHY are people (businesses) using ANY Itanium based computers? It is not only slower than SPARC (what isn't surprising ad it is THE leading RISC architecture since its creation), but also slower than Intel's own x86 stuff!
2. Side note: given such poor results of Itanium I just CAN'T understand WHY are people (businesses) using ANY Itanium based computers? It is not only slower than SPARC (what isn't surprising ad it is THE leading RISC architecture since its creation), but also slower than Intel's own x86 stuff!
That's easy: With 16 job streams (roughly equivalent to threads) you can't load system with 32 HW threads (4 sockets with 8 hw threads each) at much more than 50 percent.
The HP system had an average load of 88 percent.
The HP system had an average load of 88 percent.
No, I dont like this comparison between SUN and HP machine. It looks like IBM FUD. I dont want SUN to do these kind of comparisons. SUN can let the bench be, but dont compare. It is not a fair comparison, and I hoped SUN plays fair? But not?
How can you compare HP 4 dual core 1.6GHz vs SUN 4 quad 2.53GHz? Even a dog would understand that it is not fair. This is something IBM could do.
How can you compare HP 4 dual core 1.6GHz vs SUN 4 quad 2.53GHz? Even a dog would understand that it is not fair. This is something IBM could do.
Well... it's not Sun's fault, that HP is still using those slow and expensive Itanics
Oh ... if we were IBM, we would have compared a system of the V880 era with an ultra new system.
But HP actually used that system at the end of 2009 to do a benchmark to show that they are in striking distance of the Sun M4000/F51000 solution with the trick of using 16 threads instead of 8. Many people asked why the Sun System wasn't to do more as we used flash storage.
So this benchmark was important to show that Flash makes a difference (16 Threads Sun vs 16 Threads HP) and that 16 threads vs. 8 threads deliver quite different results, when your system is capable to execute such task. I would assume that we see even better results with 24 or 32 job streams, but that wasn't in the scope of this demonstration.
But it was clever of HP to publish this result right before our result to give some people the opportunity trying to make a point that there is a problem with the F5100. In really they simply just didn't understood the benchmark and the application.
But HP actually used that system at the end of 2009 to do a benchmark to show that they are in striking distance of the Sun M4000/F51000 solution with the trick of using 16 threads instead of 8. Many people asked why the Sun System wasn't to do more as we used flash storage.
So this benchmark was important to show that Flash makes a difference (16 Threads Sun vs 16 Threads HP) and that 16 threads vs. 8 threads deliver quite different results, when your system is capable to execute such task. I would assume that we see even better results with 24 or 32 job streams, but that wasn't in the scope of this demonstration.
But it was clever of HP to publish this result right before our result to give some people the opportunity trying to make a point that there is a problem with the F5100. In really they simply just didn't understood the benchmark and the application.
Ok, so you mean that HP still uses that Intanium system today? It is HP's top offer, even today? I thought SUN had found an old benchmark that HP did, and compared with a new SUN system, but you mean that the HP benhmark is new?
Even if so, I still dont like benches where you compare an old and outdated system to a new system, and claim superiority of the new system. That is something that IBM does, but not Sun. Or?
Fair should be fair.
Even if so, I still dont like benches where you compare an old and outdated system to a new system, and claim superiority of the new system. That is something that IBM does, but not Sun. Or?
Fair should be fair.
What a load of nonsense -- there is NO meaningful comparison that can be made between RAID-0 and RAID-10.
The Sun/F5100/SSD benchmark was running on RAID-0 and the HP/HDD benchmark ran on RAID-10. Forget SSD -- RAID-0 >>alone
The Sun/F5100/SSD benchmark was running on RAID-0 and the HP/HDD benchmark ran on RAID-10. Forget SSD -- RAID-0 >>alone
...RAID-0 alone...is good for a 40% speedup in this workload!
So...we have 40 state-of-the-art SSDs plus 12 (fast) HDDs, (52 disks total) all of which are running RAID-0, and all of this is only 30% faster than an old HP/EVA setup with 50 mechanical HDDs... RUNNING RAID-10?!?!!?
Kebabbert is right -- Sun should shut up about this, it's a very poor reflection. Sun should be HIDING this result, not bragging about it!
Question...what's up with the f5100 -- it appears to be NO faster than spinning disk, even at a cost that's at least 10 x higher. WTF?!?!
So...we have 40 state-of-the-art SSDs plus 12 (fast) HDDs, (52 disks total) all of which are running RAID-0, and all of this is only 30% faster than an old HP/EVA setup with 50 mechanical HDDs... RUNNING RAID-10?!?!!?
Kebabbert is right -- Sun should shut up about this, it's a very poor reflection. Sun should be HIDING this result, not bragging about it!
Question...what's up with the f5100 -- it appears to be NO faster than spinning disk, even at a cost that's at least 10 x higher. WTF?!?!
Links in this article
The LKSF book
The book with the consolidated Less known Solaris Tutorials is available for download here
Twitterfeeds
twitter.com/c0t0d0s0
just blogged: Reengining: I've learned in the last few weeks that a simple design decision can make your life much... http://bit.ly/d9luy8
twitter.com/codenews
PSARC/2009/534 SMB/CIFS Standalone DFS http://bit.ly/c4cAA9
twitter.com/SunPatches
128365-04 - Sun Crypto Accelerator 6000 1.1: Driver Patch. Available for SPARC since Mar/19/10. http://bit.ly/agl9Nw
twitter.com/SolPatchesX86
118192-04 - SunOS 5.9_x86: gtar patch. Available since Mar/19/10. http://bit.ly/cbnoJ7
twitter.com/SolPatchesSPARC
118191-04 - SunOS 5.9: gtar patch. Available since Mar/19/10. http://bit.ly/cb2Drj
just blogged: Reengining: I've learned in the last few weeks that a simple design decision can make your life much... http://bit.ly/d9luy8
twitter.com/codenews
PSARC/2009/534 SMB/CIFS Standalone DFS http://bit.ly/c4cAA9
twitter.com/SunPatches
128365-04 - Sun Crypto Accelerator 6000 1.1: Driver Patch. Available for SPARC since Mar/19/10. http://bit.ly/agl9Nw
twitter.com/SolPatchesX86
118192-04 - SunOS 5.9_x86: gtar patch. Available since Mar/19/10. http://bit.ly/cbnoJ7
twitter.com/SolPatchesSPARC
118191-04 - SunOS 5.9: gtar patch. Available since Mar/19/10. http://bit.ly/cb2Drj
Web 2.0
Contact
Networking
open.bc
LinkedIn
Facebook
My photos
- mail: joerg@c0t0d0s0.org
- icq: 144000169
- Me, myself and I
- openBC
- My del.icio.us
- c0t0d0s0@twitter
- c0t0d0s0@last.fm
- wiki@c0t0d0s0
- Amazon Wishlist
Networking
open.bc
My photos
Syndication
Tagged articles
AMD Apple avs Bahn Blogging Blogosphere braindump Business Travel CeBIT cec cec2006 CMT del.icio.us deutsch dtrace fliegen Fundsache General Hamburg IBM i hate sundays Intel iscsi jumpstart Links Linux lksf Mindfuck Movies Music Musik Niagara Opensolaris Opteron Photographie policy of ... Politik Security Solaris storage Sun suncec2007 sunw t1 The IT Business Ultrasparc ultrasparc t1 Wirtschaft Work ZFS
Comments
about Reengining
Sat, 20.03.2010 21:36
I didn't have special interest
in airplanes, but your articl
es about airplanes are very go
od. They have made to ta [...]
Sat, 20.03.2010 08:55
Yes. And I just don't like the
way they're killing all of Su
n brands.
They could just buy
, help, let live, contro [...]
Sat, 20.03.2010 08:49
Well, I don't think many peopl
e were using Solaris at home b
efore Oracle acquisition too,
I see home servers more [...]
about Who are you?
Sat, 20.03.2010 02:15
Ich bin im Rahmen der Diskussi
on um das Zugangserschwerungsg
esetz auf dein Blog gestoßen.
Als Linux-Begeisterter d [...]
Sat, 20.03.2010 00:32
The article doesn't explain wh
y the adquisition of Sun is go
ing to be a sucessfull. It onl
y says that we all know: [...]
Buttons
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Germany License
