IBM touts Power Systems prowess on SAP tests
ITG does some TCO touting, too
Server maker IBM is touting its ability to run ERP software from SAP as a means to promote its Power Systems servers running AIX, and it is using an SAP Sales and Distribution (SD) benchmark test to try to prove the value of its Power-based machinery.
For whatever reason - and we all have our guesses on this - IBM has not seen fit to run the SD test on Power-based servers running OS/400 or i operating systems for a number of years. This is odd, considering that OS/400 shops seem to be natural pairs to SAP software, given their desire for control and tight integration.
But it still does run the popular SD test - which is one of a handful of de facto server benchmarks for gauging the relative performance of servers within an architecture and across it - on Power iron using its AIX operating system and DB2 database variant for Unix, Windows, and Linux platforms. We are left to infer how well or poorly the i/DB2 for i combo does or how Linux on Power might do.
Last week, IBM announced the results of a two-tier run on the SAP SD test on a Power 550 server using the Power6+ chips. The machine was configured with four 5 GHz Power6+ chips, for a total of eight cores and 16 threads, and 64 GB of main memory. (The Power6+ chip has 128 KB of L1 cache and 4 MB of L2 cache per core and 32 MB of L3 cache shared by each dual-core chip.)
With AIX 6.1 and DB2 V9.5, and the SAP ERP 6.0 code, the Power 550, working as a database server, was able to push up to 99 per cent CPU utilization and drive 1.23 million dialog steps per hour, supporting 3,752 users with an average response time of 0.97 seconds.
IBM is touting this as the fastest eight-core result, but there are not very many eight-core results out there at this point that matter, except two-socket "Gainestown" Xeon 5500 machines, which come pretty close to IBM's performance. Bigger x64 servers, using the six-core "Dunnington" machines - and having four sockets just like the Power 550 - will smoke the Power 550, and have the same number of processor sockets.
If software vendors price their applications based on processor core count (as IBM does), then the fact that IBM can cram more performance into fewer cores (thanks to the higher clock speed of the Power6+ chips relative to most x64, Itanium, or RISC chips) matters a whole lot. If vendors price based on the performance inherent in the server, or on the basis of processor sockets, then the Power line can have no advantage or may even be at a disadvantage.
The SAP tests don't incorporate any economics, so you can't do any price/performance analysis. In the next few days I will fix that, considering that raw performance and price/performance have to both be taken into consideration when comparing across server architectures.
The full list of SAP SD benchmark tests can be found here, and for the sake of this discussion, I am just going to compare the Power 550 to its midrange peers.
Hewlett-Packard has just done its own SAP SD test on a four-socket ProLaint DL585 machine configured with Advanced Micro Devices' new "Istanbul" six-core Opteron 8439 SE processors, which technically don't debut until today. AMD doesn't have simultaneous multithreading on its chips, so the core count is the thread count, and this box brings 24 cores running at 2.8 GHz and 64 GB of DDR3 main memory to bear.
Re:Thread vs Process
Fenton, I think you might have mixed up the threads and processes of the Operating system with the concept of processor core threads.
On for example a niagara based processor each 'processor core thread' is actually capable of running a whole separate OS image, which then again can run many processes and threads.
And I have seen the same problems when migrating to Niagara based servers as you describe.
And don't get me wrong I think Niagara is great, for what it was designed for, workloads that will perform well with many light independent threads. But there is a long way from that to a general purpose Business platform.
Big Brother cause:
1984 was meant as a warning, not a manual.
Quite possible. I dont say that Niagara is best. I only say that it is not as slow as liar Matt Bryant claims. And I also say that Niagara is faster than Power6 on some benches, contrary to what FUDer Matt Bryant claims.
Thread vs Process
The problem with SAP and other ERP platforms is that in the main they are multi process and not multithreaded. Hence they cannot take much advantage of extra threads available but can take advantage of multiple cores.
Where threading does have an advantage is at the DB level, i.e. oracle 10 is multithreaded. In the past where processors where not multithreaded (but the database was) a process with two threads would take up two cores (if running full tilt) this would not have been available to the application. Now with Niagara/Nahalem it would use two threads on a single core thus leaving the other cores to the application.
However with the Niagara systems (and I know from personal experience, having be forced to migrate from 3Ghz windows machines to Niagara Solaris machnies) single threaded performance is terrible, the users where not happy. Most ERP systems usually run heavy batch load over night, e.g. extracts into BI systems, large interfaces, MRP runs, etc. If these have not been designed to work in parallel performance on slow cores suffers dramatically.
Unfortunatly SAP does not have a Java benchmark suite (e.g. for SAP portal, XI). Here Niagara does give you a massive benefit as Java is inherintly multithreaded and for web based applications single threaded performance is not so much of an issue as network and browser render speeds form the greater portion of the average response time.