performance comparison between rp7410 and rp8420

[RK_7]

Hi all,
Can I get the benchmarking tests and results for rp7410 and rp8420 servers.Is there any particular factor so that we can compare the performance?.

Thanks and regards

[Joseph Loo]

hi,

if u want to benchmark against other servers, visit http://www.spec.org/

regards.

[Sivakumar TS]

Dear RK,

Check this page,

http://www.abtechsys.com/hp_servers/hp_servers.html

WIth Regards,

Siva.

[Jeff Schussele]

Hi,

Well, the 7410 has the older PA8700+ single core CPUs whereas the 8420 has the newer dual core PA8800. So inherently the 8420 will be faster and coupled with the fact that it could have 4 times the CPU count, it would smoke the 7410.
Now if it was 7420 vs 8420 then it would be a 2 - to - 1 battle.
They're essentially the same speed system - it's just that the 8420 is twice the "size" of a 7420.

My $0.02,
Jeff

[Alzhy]

RK,

Are you exploring about the possibility if sticking with older hardware i.e. rp7410 with 875Mhz CPUs viz a vix PA8800 CPU Systems like the rp8420? Well, the rp8420 and newer PA8800/8900 systems have supposedly faster memory interfaces, busses, etc - but I suppose the difference will not be that great in certain situations.

Remember dual-core is not the same as 2 separate CPU sockets.

So in a situation wherein say an rp7410 with 8x875Mhz cpus compared with any PA8800 system with 4 CPU sockets or 8x1000Mhz CPU cores will not be that significantly far out.

I am seeing some proof to this on our environments - which are running your vanilla Oracle DB payload. Sama SAN/Disks .. same speed I/O channels used.

[Ted Buis]

I would say that a dual core pa8900 in the rp8420 is actually better than two single cores in most applications. First, each core is running faster(up to 1.1GHz for the pa-8900), second there is a 64MB level 2 cache on the module and no level 2 cache at all on the rp7410. However if your application doesn't benefit form a larger cache, then while memory latency is likely less on the rp8420, it isn't anywhere near half the latency of the rp7410. Memory bandwidth did increase per core by 50% going from the rp7410 to the rp8420, so that is a plus, but it is only 50%, not 100%, so that can limit the peformance increase for applications that are bottlenecked on memory bandwidth. The rp8420 clock rate improvement is modest so single threaded applications may not see much of a boost unless, they benefit from the Level 2 cache. The Level 1 cache per core is smaller on the pa-8800 and pa-8900 than on the 875MHz pa-8700+ processor, so there can always be a corner case where this makes a difference in favor of the rp7410, but I would think those to be quite rare for real applications. Remember always, that with faster CPUs, if you don't have more memory, you might just be getting to wait on disk sooner. If you are I/O bound, then having more and faster CPUs really doesn't do much. As Bob Sauers' says, "It depends", is always the first answer to these types of questions. If you have an rp7410 running your application, find out first what is limiting its performance before deciding on an upgrade path.

[Alzhy]

Dual Core is not the same as 2 separate Sockets in terms of performance gains.

This is the reason why most RDBMS vendors and other software vendors have revised their pricing policy. On high end RISC based systems - vendors now treat each "core" as simply .75 of a whole CPU core on non-multi core CPUs. Other software vendors even treat each core as .25 of a whole non-multi core CPU.

I believe there was once literature that claims only a 30-40% performance improvement in upgrading from PA8700+ (single Core 875Mhz) to Dual Core 2x1000 Mhz Cores on the PA8800 based systems.

[Ted Buis]

Nelson, I think the performance gains claimed for pa-risc were per core, not per chip. Remember also, that HP typically looks at system performance not just chip performance. Due to memory latency not being much greater and I/O possibly being no faster, your mileage will vary. I think that Oracle was reacting most to the dual core Opteron and dual core Xeon processors, not pa-risc. Benchmarks that I have seen get up to 1.6X better for the dual core Opteron versus the single core (not per core) even with the dual core running 10% slower clock rate, and up to 1.5X better for the dual core Xeon. I believe the main difference is that lower latency of the Opteron's memory system. Dual core UltraSparc IV did not get as much performance per core two UltraSparc III at the same clock rate, but this is because while the cache per core remained the same the memory bus bandwidth did not increase, so SUN effectively cut the bandwith per core in half with that "advancement". HP increase the memory bandwidth by 50% for the cell boards in the rp8420 over the rp7410, with two Itanium 2 buses (128 bit, 6.4GB/sec each) versus four turbo-runway buses (64 bit, ~2.15GB/sec each) on each cell board. The memory bandwidth doubled on the sx1000 chipset over the "yosemite" chipset. The memory bandwidth for the systems didn't increase at all in the DL585 or in the ProLiants with the dual core Xeons, or the SUN UltraSPARC IV. Thus most dual cores system have not lived up to their potential causing Oracle's response.

The SPECint_rate2000 for the rp8420 fully loaded with 1GHz pa-8800 is 266 (278 peak).
There are no published numbers for the rp7410 with 875MHz, but Superdome with 64 of those 875MHz pa-8700+ processors only got 394 (413 peak). If I look at how the SD scaled (I have to use the 750MHz processors), it was almost linear with the 16 processor SD getting 26% of the 64 processor SD. So since the rp7410 is only 1/8 of a SD, I would suggest that it is reasonable to extrapolate a best case of about 14% for the rp7410 versus the same chips in the 64 processor SD. This would put the 8x875MHz rp7410 somewhere about 55 (58 peak). I would estimate the error to be plus or minus under 5. Thus for this embarassingly parallel set of tasks that runs mostly out of cache, there is about the 4X gain one might expect from the maximum configuration for a rp7410 versus the rp8420. Most everyone, including myself, would not consider the SPECint_rate2000 benchmark to be a reasonable comparison to real world applications, which would show much less of a gain. But this does show that the potential is there for improved performance in certain cases. Again, "It depends."