An ongoing discussion about SAP infrastructure

HPE, still playing fast and loose with the facts about SAP HANA on Power

Writing a blog post would be so much simpler if IBM permitted me to lie, but that is prohibited.  That is clearly not the case at HPE, see this recent blog post:

It contains so many lies, it is hard to know where to start.   Let’s start with the biggest one.  There is a 10x difference in performance KPIs required by SAP to certify and ship a HANA appliance vs. a solution certified for TDI only.

You really have to love those lies that are refuted by such easily obtained facts from documentation that is apparently not used by HPE called SAP Notes.  SAP note 1943937 specifically states: All HWCCT tests of appliances (compute servers) certified with scenario HANA-HWC-AP SU 1.1 or HANA-HWC-AP RH 1.1 must use HWCCT of SAP HANA SPS10 or higher or a related SAP HANA revision”  Interesting that appliances must use the same HWCCT test of SAP KPIs as used by TDI.  So, based on HPE’s blog post, does this mean that if an HPE appliance compute server is used for TDI, it will perform 10x worse than if it is used in an appliance? That would imply that the secret sauce of HPE’s appliances is so incredible that it acts like a dual turbocharger on a car!

The blog post goes on to say “It (Power) ‘works’ … but it is just held to a ~10x lower standard without any of the performance optimizations attributed to SAP’s co-innovation efforts with Intel.”  OK, two lies in one sentence, obviously going for the gold here.  As we have already discussed the 10x lie, let us just look at the second one, i.e. performance optimizations.  Specifically, the blog calls out AVX and TSX as the performance optimizations for the Intel platform.  They are correct, those optimization don’t work on Power as, instead of AVX (Advanced Vector Extensions), Power has two fully symmetric vector pipelines called via VSX (Vector-Scalar eXtensions) instructions which HANA has been “optimized” to use in the same manner as AVX.  And TSX, a.k.a. Transactional System Extensions, came out after POWER8 Transactional Memory, but HANA was optimized for both at the same time.

The blog post also stated “Intel E7v3 CPUs for HANA (TSX and AVX) that offer a 5x performance boost over older Intel E7 or Power 8 CPUs.“  Awesome, but where is the proof behind this statement?  Perhaps a benchmark?  Nope, not one published on SAP’s site, even the old SD benchmark backs up this claim (which shows, by the way, almost the same SAPS/core for E7v3 vs. E7v2 and way less than POWER8, but maybe that benchmark does not use those optimizations?  Ok, then maybe the sizing certifications show this?  Nope.  A 4 socket CS500 Ivy Bridge system (E7v2) is published as supporting up to a 2TB SoH solution where a 4 socket CS500 Haswell systems (E7v3) is shown as supporting up to a 3TB SoH solution.  So far, that is just 50% more, not 5x, but perhaps HPE can’t tell the difference between 0.5 and 5.0?  But didn’t Haswell have more cores per socket?  Yes, it had 18 cores/socket vs. 15 cores/socket for IvyBridge, i.e. 20% more cores/socket.  So, E7v3 based systems could actually host 25% more memory and associated workload than E7v2 based systems per core.  Of course, I am sure that the switch from DDR3 to DDR4 from E7v2 to E7v3 had nothing to do with this performance improvement.  So, 5x performance boost is clearly nothing but a big fat lie.

And the hits just keep coming.  The next statement is just lovely “Naturally, this only matters if you want to be able to call SAP support to get help on nuance performance issues impacting your productive SAP HANA deployment.“  I guess he is trying to suggest that SAP won’t help you with performance problems if you are running any TDI solution including Power Systems, except this is contradicted by all of the SAP notes about TDI and HWCCT, not to mention the experience of customers who have implemented HANA on Power.

IBM wants to be the king of legacy businesses like mainframe and UNIX. That’s pretty much the only platforms they have left. So now that they can state that HANA “works” on Power, they can make a case to their AIX/Power customers that they should stay on AIX/Power for SAP and HANA and avoid what IBM claims to be an “oh so painful’ Unix to x86 migration.“  HPE, suggesting that you can run HANA on AIX/Power since HANA only runs on Linux/Power, might not be telling a lie but might just be expressing ignorance and the inability to use sophisticated and obscure search tools like Google.   As to the suggestion of IBM having said that a SAP heterogeneous migration is “oh so painful” ignores the fact that we have done hundreds of such migrations from HP/UX among others.  Perhaps the author is reflecting HPE’s migration experience with what every other migration provider sees as very well understood and fully supported SAP process.  As to IBM’s motivation, HPE is trying to suggest that IBM is only in the HANA business to support its legacy SAP on AIX/Power.  Just looking at the thriving business of HANA on Power, over 850 HANA on Power wins since becoming a supported HANA provider, might suggest otherwise.  How about the complete absence of any quotes, marketing materials or other documentation that shows that IBM is in this market for any other reason than it is the future of SAP and IBM intends to remain a premier partner of SAP and our customers?

Taken together, this blog post shows that HPE must be using the advanced Skylake processors in their Superdome-X and MC990 X (SGI UV 300H) to generate lies at an astounding pace.  Oh wait, I forgot (not really) that HPE still has not announced support for Skylake in their high end systems and is only certified for BWoH, not SoH or S/4HANA, with Skylake and only up to 3TB at that, … one month after announcement of Skylake!  Wow, I guess this shows simultaneously how much their pace of technology innovation has slowed down and partnership with SAP has decreased!

And, let’s end on their last amazing sentence, “Every day you put off that UNIX to x86 migration, you are running HANA in a performance degraded mode with production support limitations.“  Yes, HPE seems to be recommending that you migrate your UNIX based systems, i.e. those running Business Suite 7, to x86.  In other words, do two migrations, once from UNIX to x86 and a second to HANA.  Sounds like a totally disconnect from business reality!  As to the second part of that sentence, it simply does not make sense, so we are not going to attribute that to a lie, but to a simple logic error.

What are we to conclude about this blog post?  Taken on its own, it is a rogue employee.  Taken with the deluge of other similar misleading and outright lies emerging from HPE and we see a trend.  HPE has gone from being a well-respected systems supplier to a struggling company that promotes and condones lies and hires less than competent individuals to propagate misinformation.  Sounds more like a failing communist state than a company worthy of a customer’s trust.


August 22, 2017 - Posted by | Uncategorized | , , , , , , , ,


  1. Alfred, thanks for those clear and consistent comments. Unfortunately, without real facts and real performance comparisons contained in the HPE article, only FUD HPE has been told to us. We can show a lot of succesful HANA on POWER customer references where CUSTOMERS stating how performant the HANA on POWER installation is compared to x86 and how satisfied they are with their HANA on POWER environment.

    Comment by Jochen Ziegler | August 25, 2017 | Reply

  2. Hi Alfred,

    Great article… we ever send feedback to the blog writers at HPE who
    generate this stuff?


    Skip Garvin
    Senior Technical Solutions Manager
    IBM Systems Lab Services Migration Factory

    Phone: 1-919-542-2843 | Mobile: 1-919-593-6334 916 Fearrington Post
    E-mail: Fearrington Village, NC 27312
    United States

    Comment by Skip Garvin | September 5, 2017 | Reply

  3. I went to the HPE article => and tried to post a comment over week ago. My comment has yet to be posted. I wonder why …. ???

    My “attempted” post on HPE site ….


    I’ll just state the results of my comparisons of running HANA on Intel vs Power

    I was able to get the same query performance with 50 Power8 CPU’s (virtualized) vs 300 Intel CPU’s (5 – 4 socket 15 cores / socket nodes)

    Intel was running HANA Scale-Out with 5 – 1 TB nodes with GAL set = 5 TB (appliance)

    Power was running HANA Scale-Up with a GAL set = 5 TB (TDI – always)

    Regarding the argument around specific HANA optimizations on Intel only, SAP would never release software for any platform that did note meet their specifications. Especially for HANA. Those Intel specific optimizations for HANA (AVX and TSX) were realized for the HANA on Power code stream with Power specific instructions (Power8 Transactional Memory Facility for TSX and AltiVec for AVX instructions).

    Also, HANA likes threads .. a lot. Intel Cores have 2 threads / core. Power8 Cores have 8 threads / core.

    Running HANA on Power in Production is always 100% virtualized for ALL node sizes. That is unique to HoP and a value proposition.


    I’ll keep checking but i suspect HPE will not publish my post.

    Continue to speak the truth. Best regards,


    Comment by Scott Groth | October 27, 2017 | Reply

  4. Scott, I am sure you are correct about the likelihood of a publish of your comment. Though I do not always agree with individuals that respond to my posts, I feel it is necessary to not act as a traffic cop in deciding which comments have merit and which do not. As you know, it is not just superior performance per core, but superior performance with a scale-up approach which delivers such outstanding results for BW. I suspect that the very low latency, very high bandwidth Power memory architecture enables this approach to work better than it would on a comparable Intel scale-up option, but there are very few ways of proving this other than to wait and see if any customers attempt to scale-up BW on Intel and show the results that you and other customers on Power scale-up have been able to demonstrate.

    Thank you for your comments.

    Comment by Alfred Freudenberger | October 27, 2017 | Reply

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: