Rob Aldrich Nov 11, 2008

Hi Sean,

Good point of clarification, how do you represent a normalized (average over time) kW/hr per transaction?

What we’ve done with this large retailer is in essence a lot of % work across different infrastructure sets.  For example at one of their many branch locations we have an IBM POS (desktop) cash register consuming about 220 Watts per hour (nameplate) which we we first normalize by removing 30% of the nameplate = 154 W/hr (we apply this to all infra) and then further normalize by dividing 154 W/hr’s by the average number of total transaction that POS unit performs (720 transactions per day, roughly 1 every 2 minutes).  This is our first data set.

We then trace the transaction path all the way to storage in the data center using the same basic methodology.  The next transfer point is the branch back office which has 2 x 400 W/hr servers and a small all in one switch/router 1 x 160 W/hr.  We then jump to the front end core of their data center as they don’t own the service provider infrastructure.  Across the data center we have of course multi use and highly modular equipment which makes it more complex but basically the same basic formula applies with one new variable which is the estimated percentage of chip allocation required to move a single transaction.  For example, they have a volume (1U) server farm (400 units) that primarily handles this transaction load so we took an estimate to say that 90% of the power required for these servers goes to the transactions.  We took the same agreed upon percentage approach for core, access and storage switching and even went so far as to break out the LUN’s in storage.

What we were left with was a rationalized Watts per transaction (average out across 24 hours) number.  We then went through the same process with new approaches to the network architecture which showed big gains in a before and after scenario.

Forgive for not being more specific with figures but there is only so much I can share.

To summarize if you have a use case model (in this case a common retail transaction) and can inventory the infrastructure along the transactions path you get a general sense of what energy is needed to make that transaction happen across the architecture.  This is your benchmark by which you can analyze potential improvements.

Your point on the temporal is spot on, a Watts/hr per transaction is truly telling if you want to be exact.  However, for the sake of this exercise it was enough to average out the Watts over a 24 hour period and by total daily transactions.

Sadly, I don’t have more reading on the metric as I don’t believe it exists (at least not at the industry level).  I’m hoping that maybe some folks out there have done some work here and we can compare notes on the best way to approach a Wattage measurement for the logical elements (apps, transactions, VM’s, VLAN/SAN’s, etc).  I fear consensus on something like this will be difficult at best as the number of variables here is mind boggling if one really wants to be exact.

If the industry had this I tend to think IT bill back for power becomes much more prevalent and business unit bill back in turn.

Thanks for the comment Sean!

Sean Nov 12, 2008

Hi Rob,

Hope I’m not coming off as a smartass here, but a Watt is a rate, so it is already divided by time (1 Watt = 1 Joule/Second).  So above, when you’re dividing the percentage of nameplate draw by an hour you’re really supposed to be multiplying by an hour.  Or, put another way, you’re billed in KW*h, not KW/h or even KW.  Your numbers end up being correct, the units are just off, and I’d hate to see the work get dismissed by a customer for what is otherwise a small error.

Back to more practical matters, I think virtualization will be the catalyst for more accurate measurements of power draw on shared infrastructure, since all the CPU time is usually recorded. Shouldn’t be that much of a leap to use all that information to figure out the relative use of power within a virtual switch, router, server, or widget.

You’re doing some good work here—power is a huge operating cost but all the details are hidden (for the moment). I’ll be keeping an eye out for more research on the topic.

Sean

Giovanni Oct 16, 2009

Hi Rob,Thankyou for sharing this information