Applications Matter - What Affects Server Power Consumption: Part 2

Tony Harvey — Wed, 10 Jun 2009 22:21:00 GMT

How does the application you are using and what it is doing affect the power consumption of system.

The first thing that everyone looks at when talking about power consumption is CPU utilization. Unfortunately CPU utilization is not a good proxy for power consumption and the reason why goes right down to the instruction level. Modern CPUs like the Intel Nehalem and AMD Istanbul processors have 100s of millions of transistors on the die. What really drives power consumption is how many of those transistors are actually active. At the most basic level an instruction will activate a number of transistors on the CPU, depending on what the instruction is actually doing a different number of transistors will be activated. So a simple register add, for example, might integer add the values in two registers and place the result in a third register. A relatively small number of transistors will be active during this sequence. The opposite would be a complex instruction that streams data from memory to the cache and feeds it to the floating point unit activating millions of transistors simultaneously.

Further to this modern CPU architectures allow some instruction level parallelization so you can, if the code sequence supports it, run multiple operations simultaneously. Then on top of that we have multiple threads and multiple cores. So depending on how the code is written you can have a single linear sequence of instructions running or multiple parallel streams running on multiple ALUs and FPUs in the processor simultaneously

Add to that the fact that in modern CPUs the power load drops dramatically when the CPU is not actively working, idle circuitry in the CPU is placed in sleep modes, standby or switched off to reduce power consumption. So if you're not running any floating point code, for example, huge numbers of transistors are not active and not consuming much power.

This means that application power utilization varies depending on what the application is actually doing and how it is written. Therefore depending on the application you run you will see massively different power consumption even if they all report 100% CPU utilization. You can even see differences running the same benchmark depending on which compiler is used and whether the benchmark was optimized for a specific platform or not and the exact instruction sequence that is run.

The data in graph below shows the relative power consumption of an HP BladeSystem c7000 Enclosure with 32 BL2x220c Servers. We ran a bunch of applications and also had a couple of customers with the same configuration who wre able to give us power measurements off their enclosures. One key thing to note is that the CPU was pegged at 100% for all of these tests, (except the idle measurement obviously).

As you can see there is a significant difference between idle and the highest power application, Linpack running across 8 cores in each blade. Another point to look at is that two customer applications, Rendering and Monte Carlo, don't get anywhere close to the Prime95 and Linpack benchmarks in terms of power consumption.

It is therefore impossible to say what is the power consumption of server X and comparing it to server Y unless they are both running the same application under the same conditions. This why both SPEC and the TPC have been developing power consumption benchmarks that look at both the workload and power consumption to give an comparable value between different systems.

SPEC in fact just added Power Consumption metrics to the new SPECweb2009 and interesting enoughly the two results that are up there have the same performance per watt number, but they have wildy different configurations, absolute performance numbers and absolute wattage numbers. So there's more to performance per watt than meets the eye.

The first part of this series was Configuration Matters

Chargeback Glitch

Daniel Bowers — Fri, 15 May 2009 16:25:00 GMT

Here’s a story about unexpected behavior prompted by some chargeback rules at Pfizer. (By 'chargeback' I mean the budgeting scheme where IT resources are metered, then costs are attributed to the business units that consume them.)

Larry Cannell notes that when department budgets were squeezed, users moved Sharepoint files to non-Sharepoint systems "all to avoid internal chargebacks. In the end...a lot of extra work...but no impact on the bottom line." For HP Bladesystem, tools that let IT departments implement chargeback are nothing new. There are ways to both measure resource utilization, and to implement high-level chargeback policies.

HP has even added some ground-breaking capabilities here -- bringing continuous capacity planning tools into the x86 space, for example. We’ve also added server power consumption as a resource that can be tracked historically for chargeback calculation – or even capped so businesses can predict their spend.

You have to think like a non-IT guy, though, to predict how your internal customers will react to your chargeback rules. Put yourself in the shoes of a line-of-business manager:

People will order from the "Value Menu". If someone thinks he could squeak by with some minimal level of service, he’s going to try.
Square pegs will wind up in round holes. To an HR guy, using a USB key as the primary backup device for your employee payroll database seems reasonable.
Exceptions have legs. That handshake agreement to charge a little less because the legal department promised they’d use minimal bandwidth? Ten minutes later, every other department will demand “the “low bandwidth deal”.
Don’t put nametags on hardware. Especially with bladed infrastructure, you need to use language that avoids the impression that groups have “bought a server”. They’re paying you for a service…How you deliver that is up to you, not them.

Search results matching tags 'BladeSystem' and 'data center'

Applications Matter - What Affects Server Power Consumption: Part 2

Chargeback Glitch