HPE 9000 and HPE e3000 Servers
cancel
Showing results for 
Search instead for 
Did you mean: 

New server benchmarks

 
steve_26
Occasional Contributor

New server benchmarks

I'm looking to buy an rp4440 with 2 dual-proc 1GHz pa8900. This is replacing a V2600 with 12 550MHz cpu's(pa8600). HP shows relative benchmarks of 113000 tpm for the rp and 60000 tpm for the V. I know the V is dated, but I have a hard time believing the 4-way RP's throughput will be this much faster. Thoughts?
10 REPLIES 10
Chan 007
Honored Contributor

Re: New server benchmarks

Steve,

All the old Model names are now gone, Like A,B..T, V etc. RP4440 is pretty good and reliable. They are quite faster and boots faster than a V Class. Also Less of problems.
You can manage using a GSP instead unwanted console.

You can go ahead for the new one..

All the best ...Cheers ...007

Re: New server benchmarks

Steve,

I susepct I know the tool this data has come from and you need to understand some things about it:

- Nearly all the figures in the tools are estimates, and under the 'fair use' guidelines that tpc.org publish, you shouldn't really post this information into a public forum...

- The figures are based on OLTP type loads - is that what you are using the system for?

- Its quite possible for a modern PA8900 to be that much faster than the old PA8600s, but again, you do need to consider your workload - having four engines that can run 2-3 times as fast as 12 engines might help most of the time, but there are some workloads where the ability to execute 12 operations in parallel will still be faster... I would suggest that most of these are edge cases though.

What sort of workload are you working with?

HTH

Duncan

Accept or Kudo
Andrew Rutter
Honored Contributor

Re: New server benchmarks

hi steve,

I havent ever booted a v class with 12 cpu's but know they were a long time in booting and could be problematic at best, aswell as having alot slower throughput on bus speeds. IO cards and disks run alot slower aswell on the v class, due to mostly FWD devices.

The cpu bus speed and memory bus speed and disk I/O is alot faster on the newer rp's along with alot quicker bootup.
I have configured many rp3xxx and RP44xx's for customers and they have always been very impressed with them, and so far had very little trouble.
I was surprised the first time I ran a RP4440 how quick it was at just installing software and configuring vg's and lvols.

Of course it helps if you have plenty of memory aswell.

I personally do not think you will be disapointed.
Thats my 2pence worth

Andy
steve_26
Occasional Contributor

Re: New server benchmarks

Duncan

This server is dedicated to running a Sybase database with mainly an OLTP workload.

These new cpu's would have to be 3 times as fast just to break even and more than 5 times as fast to meet the benchmark numbers mentioned. I realize the cpu's aren't the only component of throughput.

My concern is I'm expecting to get 3 years out of this server so I need some breathing room over current capability. (I'll be fine if the relative benchmark numbers are in the ballpark )
steve_26
Occasional Contributor

Re: New server benchmarks

I also realize there is room to add cpu's, however that would drive my Sybase license and support cost's up quite a bit. (Funds that aren't currently available.)
rick jones
Honored Contributor

Re: New server benchmarks

Don't forget that the cache memory on the PA-8900 is positively HUGE compared to the PA-8600. OLTP seems rather to like cache.

I'm not sure if HP have published any SPECint_rate2000 numbers for the rp's but you might look at www.spec.org and/or ask your reps and compare with what you may find published for the V2600.

I suspect the memory latency is much lower in the rp than it was on the V. If you have a chance and your V is still up and running and reasonably idle you might try running lmbench's memory latency tests. OLTP likes low latency very much.

IIRC HP published between 112 and 150 ish nanoseconds memory latency for the original rx2600 with 1GHz Itanium CPUs (might be in a whitepaper somewhere). The latency for an rx4640 is slightly higher. The latency for an rp4440 wouldn't be any worse (IIRC) than the rx4640's memory latency - the difference being the CPUs - the memory controller is the same.

WRT licensing costs, if this is already running on a 12 CPU V2600, wouldn't the license be rather lower even if you went with three or four dual-core PA-8900's?
there is no rest for the wicked yet the virtuous have no pillows
steve_26
Occasional Contributor

Re: New server benchmarks

Rick,
No on the licensing cost. The plan calls for going to cpu licensing from the current per seat licensing to drive down the cost.
Ted Buis
Honored Contributor

Re: New server benchmarks

Well, the first pass, should be to multiply 12x550 and compare it to 4x1000, and that doesn't look too favorable. The V class did get over 100,000 tpmC in benchmarks at one time with slower disks, but the real edge that the rp4440 has over the V-class is the maximum RAM of 128GB versus 32GB for the V.

If you have the same amount of RAM you may get similar performance, but more RAM can often do wonders and this is the case with the TPC-C benchmark. "YOUR MILEAGE WILL VARY". Consider getting more RAM on hte new system than the old. Lower support costs are the main advantage over the V-class. Personally, I would look at getting three of the dual core processors (6 cores) to match up against the 12 in the V. I would also look at I/O on the new system. If you hook up the same old disks, they might be the limiting factor.
Mom 6
Highlighted
Jeff Schussele
Honored Contributor

Re: New server benchmarks

And don't forget to count up the I/O slots you're NOW using in that ole 1/2 ton beast.
It has *5* times the slot count as an rp4440.
~ 30 avail in a V
as opposed to
~ 6 in an rp4440.

I would know - I had a couple of Oracle "dump-truck" 2600s that I had to end up having 10 Fibre channel HBAs spread across the 4 I/O cages to my SAN to get the desired total throughput. And that was the main bottleneck in Vs - total I/O bus speed/throughput. They were fairly good with their cpu -> memory bus, but their cpu -> I/O busses couldn't handle sustained loads.

The new systems can & do & need a LOT less CPU overhead in doing so. I was totally amazed watching the poor CPU that would be assigned the task of handling ALL interrupts for the FC driver. It would *stay* pegged at 100% all the time whilst all the other CPUs would just "cruise" at 30 - 40%.

HTH,
Jeff
PERSEVERANCE -- Remember, whatever does not kill you only makes you stronger!