Why upgrade your hardware when migrating to SAP ERP 6.0?  Because it makes simple, practical, business sense that is all.  SAP has identified several key reasons why customers are concerned about migration and several among them are as follows:

·         Cost, Cost, Cost

o   HW infrastructure cost is highlighted as one of the key barriers of migration

·         Business Justification

o   Is there a compelling business reason to upgrade the hardware?

·         Additional risk of business disruption

o   Migration of ERP environment is complex enough…how much more risk is there when upgrading your hardware?

From a cost perspective, the perception that hardware is a barrier to migration can be easily overcome.  Based on research, the hardware cost as a percentage of the overall migration cost is only about 7%.  That means 93% of the cost is in licensing, consulting, etc, etc.  HW costs are only the “tip of the iceberg” and the real $ investment lies elsewhere in the equation.

Is there a compelling business reason to upgrade your hardware? Well…frankly, it does not make sense not to do it.   One, we showed above that the hardware investment is minimal compared to SW licensing, consulting, service, etc.  Two, the hardware requirements of ERP 6.0 are significantly higher than previous versions. ERP 6.0 requires up to 2.5x more CPU performance, 2.5x more memory and 1.5x more I/O!  You will need the increased performance and scalability that Intel provides in our microprocessors.  While the ERP performance requirements have increased 2.5x, Intel performance with SAP has increased 10X!  Oh, btw…energy efficiency does matter and in your new ERP environment you will be able to consolidate servers and save on power and cooling costs.  TCO will be significantly reduced and from hardware investment standpoint, you are likely going to recover the cost of the servers in a very reasonable timeframe.

From my discussions with the IT community, their major concern and number one focus area is to prevent business disruption and downtime.  This costs companies real and significant money.  The fact is that an ERP migration is a complex enough project managing the strategic, functional and technical portions.  Adding a server infrastructure change increases fundamental risk.  But, the key here is that it is done often and done successfully.  Intel IT has published several whitepapers on the subject and communicated “Best Known Methods” to minimize that risk.    A quick summary is inserted here:

Challenge:

•         Convert Intel’s Worldwide Warehouse Management Software

•         Upgrade from SAP* ERP version 4.7 to 6.0, change the DBMS, and perform a Unicode* conversion as well as a hardware upgrade

•         Minimize downtime

Benefit to Intel IT:

•         SAP ERP 6.0 improves Intel supportability

•         Increases ease of integration to SAP NetWeaver* 7.1 Suite

•         Provides access to Enhancement Packs and Enterprise Services

•         Intel^® Itanium^®-based servers provide access to 128 GB of memory for database and SAP operations and significantly increased performance from true 64-bit processing

Key Results:

•         Reduced downtime of upgrade by 50% by using Intel Architecture

In summary,  upgrading your server infrastructure when migrating your ERP environment is a very, very complex task, but form a business perspective, it should be fairly easy to see the true benefits from combining the ERP migration and hardware upgrade at the same time.

The need to write scalable applications has been important for programmers in the HPC community for years. Now, with the proliferation of multi/many-core processors developing scalable software is now a top priority for many programmers. 

Andrew S. Tanenbaum stated at the USENIX ’08 conference last year that developing “sequential programming is really hard” … the difficulty is “parallel programming is a step beyond that.” 

He is right, but let’s illustrate why it is just a small step.

Here is the point – parallel architectures will continue proliferating and we will need to develop and refine parallel algorithms that exploit parallelism. While difficult, to develop and refine parallel algorithms, the actual programming of these new algorithms, does not need to be hard.  However, if the developer is required to know the intimate details of the hardware then the development and refinement parallel algorithms can be very difficult, and very time consuming.

One approach provided by Intel software developer tools is to abstract away the details of the hardware.  This allows the developer to focus on their algorithms /applications, and rely on Intel software developer tools to provide the best optimizations for current and future platform While you may give up some performance by being abstracted away, what you lose in performance will be rewarded by your ability to quickly iterate through more iteration of your parallelization ideas in less time.  You may find yourself designing and developing better approaches to parallelism because you were able to test more hypotheses. 

An additional by-product of being abstracted away from having to know the intricacies of the hardware is that your software will be highly adaptable to future platforms.  You will see tremendous improvements on multi-core solutions and will be in a great position scale your application performance forward as newer architectures are made available. 

To learn more Intel Software Tools and the benefits of optimizing your software on multi core based solutions first visit http://software.intel.com/en-us/intel-sdp-home/

Are you a developer writing applications to run on the Solaris operating system?. Are you looking for ways to optimize your Solaris solution on industry standard architecture based on Intel microprocessor? If you answer yes to either of these questions then please read on.

Intel and SUN have been working closely together to optimize the Solaris operating system on the Intel Xeon 5500 processor. Most of you probably know the Xeon 5500 better by its product codename Nehalem. The Xeon 5500 is the the product that fits into 2 socket platforms.

SUN have just published a very compelling quick reference guidethat will assist both Developers and System Administrators looking to optimize Solaris solutions on Xeon based processors. The guide talks about the work that Intel and SUN are doing together, technical descriptions of specific features and capabilities that can be implemented in the Solaris OS to optimize the capabilities of the Xeon.

I have just finished reading this and it is a very compelling paper covering topics such as

- How Solaris takes advantage of Intel Turbo Boost Technology to use available power headroom to deliver higher performance based on workload demand

- How Solaris can take advantage of new Intel Quickpath Interconnect (better known as QPI) and other innovations in the OS to reduce memory latency

- How Solaris performance counters help to better manage workloads

- How Solaris takes advantage of many of the power efficiency capabilities in the processor. Things like Power Aware Dispatched in Solaris enable the processor to stay longer in idle states. In non tech talk this saves power.

Solaris has been a tried and tested operating system for along time for companies running their most business critical workloads. This paper talks about the combination of Solaris and Xeon to deliver improved reliability and availability for these critical workloads. Detail information on predictive self healing, fault management, leveraging Intel Machine Check Architecture and more all included in this paper.

Probably my favourite section is around the developer tools optimizations and the different tools available for developers that want to run and optimize their applications on Solaris and Xeon.

Ok, I'll stop waxing lyrical now. This is a very compelling paper and it does certainly construe that Solaris and Xeon 5500 could be the perfect combination for your Solaris solution. What do you think?

I was thinking about what to write in my next blog and what I could share beyond what I have written previously about Intel Vs RISC in terms of TCO, performance and the customers that are choosing to move.

Luckily I didn't have to think too long on a Friday morning as a a topic came to mind instantly. There are numerous articles flying around this morning that picked up on the Oracle comments yesterday about how SPARC based systems compare to Intel. Thanks for providing me with an appropriate topic.

So in case you missed it, there was a question and answer session with Larry Ellison. When asked about SPARC, this was the reply "SPARC is much more energy efficient than Intel while delivering the same performance on a per socket basis. This is not a green issue, its an economic issue. Today, database centers are paying as much for electricity to run their computers as they pay to buy computers. SPARC machines are much less expensive to run than Intel machines"

1) SPARC more energy efficient than Intel?  Seriously, in what parallel universe does that exists?

SUN continues to use watts per thread as measure of energy efficiency. The recognized industry standard benchmark for measuring energy efficiency is SPECpowerand I don't see any SPARC based results in the 91 results published. The absence of a result certainly says something very clear to me - no story.

These UltraSPARCT2+ systems get loaded with a lot of memory to deliver the their results, so when you look at overall system power (what people care about) they are not as energy efficient as Intel based systems.

SPECpower is effectively based of SPECJbb-2005 so another way of loking at this is to look at the SPECJbb-2005 results for a 4 socket UltraSPARcT2+ system and a Xeon 7400 system. The 4s UltraSPARCT2+ delivers 693k BOPs while Xeon 7400 is 532kBOPs. So you conclude that SPARC is better than Xeon?. That would be the wrong conclusion

UltraSPARCT2+ system would consume 1525 watts Vs Xeon 7400 at 816 watts. If you look at BOPs per watt (another way of looking at energy efficiency and performance) then you would see that Xeon 7400 is 43% more energy efficient. Doing a similar comparison with Xeon 5400 (I haven't even talked about our latest Xeon 5500, Nehalem) would be up to 77% more efficient than UltraSPARCT2+.

And lastly before I forget to mention the 4s UltraSPARCT2+ had 128GB memory and costs over $150,000for the system, while Xeon 7400 based system had 64GB memory and costs around $32,000.

2) SPARC deliver same performance on a per socket basis?

2S Xeon 5500 has performance leadership over 2S UltaSPARCT2+ across a wide range of benchmarks. Up to 70% more performance and up to 60% lower system cost. 4S Xeon 7400 has price/performance leadership over 4S UltraSPARCT2+, UltraSPARCT2+ results achieved with system loaded with lots of memory that drives the cost up to 3-4Xthat of Xeon 7400 system

3) SPARC machine are less expensive to run?. I can't for the life of me work this one out!.

Hardware systems based on Intel have leading price/performance (read cheaper), lower energy needs (so electrivity bill lower) and any software product with a license per core strcuture is less expensive on Xeon system than an 8 core UltraSPARcT2+ (which also has higher multipler per core)

That's all for now folks. I just wanted to share some data on why I know that SPARC machines are much MORE expensive to run than Intel machines

Here’s the final follow-up post in my 10 Habits of Great Server Performance Tuners series. This one focuses on the tenth habit: Compare apples to apples.  

Much of performance analysis involves comparisons: to baselines, to competitive systems, or to expectations. It is surprisingly easy to make an inappropriate comparison. I have seen it done many times and certainly been guilty of it myself. So the final habit to be aware of is to always compare apples to apples.

Make sure that the 2 systems or applications you are comparing are being run the same way, with the same configuration, under the same conditions. If there is a difference, understand (or at least hypothesize about) the impact of that difference on the performance. Dig into the details about experiments – for some ideas on what to look for, see habit 7.

You should always make this a habit – but it is especially important when you are making decisions based on the comparison. Double-check your work in this case!

This series has given you 10 of the habits I have learned in my years tuning server performance. Of course there are other tricks of the trade and BKMs, which I will try to cover in future blogs. But making these habits part of your routine will help make you a better, more consistent performance tuner. Good luck with your optimization projects!

I'll be up front, I really don't know what Brittany Spears, Miley Cyrus or Susan Boyle would say about moving from RISC to the Xeon 5500 processor!. What I can share is the feedback that I'm getting direct from customers. I'm currently out on the road and have got some real feedback direct from customers on why they are looking at migrating their solutions from RISC  processors to Xeon processors.

Over the past couple of days I have had the opportunity to meet directly with individual customers and hosted a roundtable with several customers to discuss their plans to replace their RISC based infrastructure. The conversation has been very open and frank and has not been about 'should I move' but more focused on 'how do I make the move'. As could be expected the down economy is placing big taxes on the ability of IT organizations to support their business units need for organic growth in a flat to down IT spending environment. A big priority for most of the customers that I spoke with is how to reduce their overall TCO while still meeting the increased demands being placed on IT by their business Partners. Most of the customers are already engaged in active projects to assess moving from RISC or are building their plans to make this migration.

During the roundtable I had opportunity to share the latest Xeon 5500 processor performance comparisons Vs the main SPARC and POWER based solutions out there. There was great rejoicing and joy (ok I'm taking poetic license here) in the roundtable when we share some of the results that we highlighted when we launched the Xeon 5500 processor just over 3 weeks ago. So I want to spread the joy and let you read for yourself the performance and price performance benefits.

We compared the Xeon 5570 processor vs the top UltraSPARCT2+ in a 2 socket configuration. We took best published results on spec.org and sap (so no funny games at play). The results comparing best UltraSPARCT2+ vs best Xeon 5500 with 1 taken as baseline for SPARC redults were amazing

- 20% better on SAP-SD

- 62% better java performance for Specjbb2005

- 69%better for integer performance SPECIntrate-2006

- 75% better for floating point performance SPECfprate-2006

But the best bit was the cost competitiveness of the Xeon 5500 solutions. Comparing both solutions with 32GB memory, the Xeon 5500 based solutions are offered at approx $11,000 whereas the UltraSPARCT2+ is at $36,000.

Compared the Xeon 5570 processor vs the top POWER6 in a 2 socket configuration gave even more staggering results. At the roundtable today customers were amazed. They keep hearing that POWER 6 has leading performance and more GHz so better performance. Right?. Wrong is the answer and I noticed many customers scribbling down the comparisons. Again taking 1 as baseline for POWER results

- 150% better on SAP-SD

- 190% better java performance for Specjbb2005

- 126%better for integer performance SPECIntrate-2006

- 90%better for floating point performance SPECfprate-2006

But the best bit was the cost competitiveness of the Xeon 5500 solutions. Comparing both solutions with 32GB memory, the Xeon 5500 based solutions are 92% less expensive than equivalent POWER 6 offerings.

I only shared the specific comparisons vs RISC and have not gone into the architectural advancements of the Xeon 5500 processor and how it addresses real business needs that have been flagged to us. There have been lots of other blogs out in cyberspace over the last few weeks on improvements in IO, low latency etc. so you don't need my 2 cents.

I think now is the time to make the move from RISC, what do you think?

This blog post is meant to discuss some of the considerations for performance tuning your Intel® Xeon® Processor 5500 (“Nehalem-EP”) series based server. I’d like to do this by discussing the un-boxing process.

Step 1. Place the box on the floor

Step 2. Open the box

Step 3. Carefully remove the server.

Step 4. Plug the server into a keyboard, mouse, and monitor.

Step 5. Plug the server into the wall socket.

Step 6. Power on the server.

There. You are done tuning your Nehalem-EP based server for performance. “Really?” you ask? Well mostly. There are some considerations and I’ll discuss them. I can speak to this subject as I was asked to tune this class of system using the TPC-Cand TPC-Ebenchmarks.

BIOS / Firmware / Drivers

It is very important to remember to update your system's BIOS, firmware, and OS drivers before you do any deep performance tuning. I cannot over state the importance of this step. Your system's manufacturer should be able to provide the latest BIOS and firmware associated with your server. OS drivers are available through many sources these days. Typically these can be downloaded from OS vendors, hardware vendors, from the Linux open source community, or the platform's manufacturer.

A good example of this is the SATA driver associated with the ICH10. The ICH10 is part of the chipset that supports Nehalem-EP. I recommend going to Intel’s website and using the Intel Matrix Storage Manager driver for the SATA controller.

Understand your system

Last year, Nehalem launched for the desktop market segment. Now it is time for the server market. The Nehalem-EP processor is meant to be used in dual processor (DP) socket systems. Nehalem-EP is the follow on to the Intel Xeon Processor 5400 (“Harpertown”) series. However, Nehalem-EP is really very different from Harpertown. The Nehalem-EP processor is based on the Intel Core i7. The Nehalem-EP processor inherits the same architectural features as the Intel Core i7. Once you understand these features, then you can better tune your system for performance.

L3 Cache:

Nehalem-EP uses a level 3 cache. Depending on which SKU you are using it can be 4MB or 8MB in size. If you are interested in performance, then I would encourage you to pick the larger cache size SKU.

Hyper Threading Technology:

If some threads is good then more threads is better. This is where Hyper threading technologycomes in to play. Nehalem-EP provides this technology out of the box. So, on a typical DP server this will give your system 16 threads of processing goodness.

Intel Quick Path Interconnect:

Nehalem-EP supports a CPU interconnect known as Intel Quick Path Interconnect (QPI). This interconnect is the replacement for the Front Side Bus of old. QPI provides a point to point link to each of the processors and the Intel X58 chipset. The Nehalem-EP supports QPI speeds of up to 6.4GT/s. This provides a theoretical bandwidth of 25.6 GB/s. This is a welcome shift for Intel’s designs for the future.

Turbo Boost Technology:

As with the desktop SKUs of Nehalem, the Nehalem-EP supports Turbo Boost technology. This technology will run the CPU at a higher frequency than its rating. It will increase the frequency in steps of 133MHz until it achieves its upper thermal and electrical design requirements. Turbo Boost Technology is dynamic. In other words, the processor will decrease its core frequency if the temperature is too high. If your application is sensitive to core frequency changes and does not fully utilize all cores, then it may benefit from this technology.

Integrated Memory Controller:

Another key feature of Nehalem based processors is that they have the memory controller integrated into the processor. This allows for much lower memory latencies. The Nehalem-EP supports three channels of DDR3 memory. It is important to talk about DDR3 memory and population on Nehalem-EP based servers. As mentioned before Nehalem-EP supports three channels of memory and supports 800, 1067, and 1333 MT/s memory speeds. Those speeds are dependent on how many channels are populated with DIMMs. For instance, 1333 MT/s is supported in a single DIMM per channel configuration. 1067MT/s is supported in a single DIMM per channel and two DIMMs per channel configuration. 800MT/s is supported in all configurations. These speeds are based on dual ranked DIMMs. If you plan on filling up all the memory slots with as many DIMMS as possible you will end up running at 800MT/s. So, here is the consideration. Does your application need all that memory or could it use less memory running at a higher speed? If the answer is yes to the latter, then perhaps running two DIMMS per channel at 1067 MT/s is the best configuration.

To wrap things up here, we have looked at the new and Nehalem architecture, the importance of BIOS/ firmware/ OS drivers, and memory population. Your application's performance will vary, but I hope I have given you some things to narrow down your performance testing. Thanks for taking the time to read this blog post. For more great performance methodology tips please check out Shannon Cepeda’s blogposts on performance tuning.