Zen and the Art of Data Center Greening (and Energy Efficiency)

This is a summary of the Green Software Unconference that took place August 19.

I chaired two breakout sessions. In this blog, I will cover the overview and the first session. I’ll present the second session later.

The first picture is of all the sponsors. AltaTerra was proud to be one of them.

A large number of sponsors

Mary Vincent presented the agenda for the day. (Sorry, Mary, I cut you in half in the picture.) See, this conference had a very grassroots feel, using a piece of paper on the wall.

Mary Vincent giving the agenda for the day

Following the self-introduction of 106 people (even without a big star like Al Gore, 106 people showed up, due to Mary and Mark’s efforts but also the high interest in this subject), some people, including Don Bray (founder and president of AltaTerra) and I, suggested 25 topics for breakout sessions that were then consolidated into 24 with 4 time slots and 6 parallel sessions. This is very much like the unconference look and feel.

Final breakout sessions (24 in total)

I chaired two sessions:

Energy Star for software
Power consumption monitoring for data centers

Since I couldn’t take my own picture while I was moderating, here’s my proxy picture.

My proxy picture for the unconference

Session-1: Energy Star for software
Fewer but enthusiastic people attended this session, and I enjoyed talking with them. Here’s what we discussed.

Green software means two things: (1) make software greener and (2) make other things greener with software. The second definition is easier to consider. It can include telepresence and measuring power consumption. The first definition is much harder because there are many kinds of software, and even the same kind of software can behave differently on different platforms. So to measure its performance or energy efficiency (which requires CPU time and memory capacity), we must specify some specific platform to use for comparison.

It is not reasonable to assume the same platform for all software. For example, software for embedded systems runs only on a particular hardware/real-time operating system, but other application software, like web applications, will not run on such a platform. So it may be necessary to classify software as different kinds. This may open up a can of worms. How do you classify software? It can be utilities like OS/middleware and application software that, in turn, may be classified as embedded, database, financial (real-time requirement), web (forgiving time requirement), mission critical (strict real time), and so on.
Hardware is easier because, whatever its purpose, you can easily measure its power consumption and compare it with other hardware with the same purpose. That is why most energy efficiency rating/metrics are for hardware but not for software. Many people do not even see the necessity of such a rating/metric. For example, The Green Grid’s power usage effectiveness (PUE) metric measures data center energy efficiency, which is easy to measure. PUE is widely used since you only observe total power consumption against the power consumption by IT loads. However, people have started to realize that the really important metric is the amount of useful work per watt. But each application defines amount-of-useful-work completely differently (for example, data base transactions vs. web server processing abilities). Instead, they decided to go with a proxy for this metric. Judging from this, coming up with an Energy Star rating/metric for software will be hard.
There are things we can do improve each kind of software, even though each is so different from the rest. But we can do the following. Obviously, we could not cover all the details of each point, and besides, this is not a comprehensive list.

Parallel programming—hard to program, nondeterministic (such as race condition)
Design/architecture—modularized structure vs. big monolithic chunk (e.g., SMTP server)
Interpretive vs. compiled—web languages vs. C, C++, and Java
Performance vs. ease of use—heavy on the ease of use and leave the heavy lifting to hardware
Optimization—optimizing compilers and other utilities

We have to start somewhere. I suggested educating and re-educating programmers for energy efficiency and changing their attitude towards it. Most programmers tend to program in the easiest way and leave the heavy lifting to the hardware. There should be a balance between ease of programming and energy efficiency. If we seek only energy efficient software, we must program in machine language. As we know, machine language was so hard to program in and so error-prone that assembly language was invented. Even assembly language was so hard to program in that high-level language was invented. Then object-oriented and web-friendly languages (mostly interpretive) and so forth came to the market. It is important to keep energy efficiency in mind, but if the programming language you use is so hard to program in, your program would contain a lot of bugs and crash often, you need to spend a lot of energy (pun intended) to fix it, and that may consume a lot of machine time (wasting energy). So a balance is necessary.
Finally, a gentleman from Symantec arrived at the last minute and shared Symantec’s experience with discussions with EPA, which is somewhat interested in an Energy Star rating for software. Symantec has its own idea for an Energy Star rating for software, and I will talk to him more about it.

Overall, this was a very good session. I would like to thank everyone who joined in the conversations, especially Jane Chung (Jetro) who took notes for me.

More later.

Tags: Day 1 Energy Star for Software Green Software Unconference My session

Edit This Favorite

My Two Sessions at the Green Software Unconference --1