Energy Star For Servers Falls Short

tsamsoniw writes "The newly released Energy Star requirements for servers may not prove all too useful for companies shopping for the most energy-efficient machines on the market, InfoWorld reports. For starters, the spec only considers how much power a server consumes when it's idling, rather than gauging energy consumption at various levels of utilization. That's like focusing on how much gas a vehicle consumes at stop lights instead of when it's moving. Also, the spec doesn't care whether a server's processors have one core or multiple cores — even though multi-core servers deliver more work at fewer watts. Though this first version of Energy Star for servers isn't entirely without merit, the EPA needs to refine the spec to make it more meaningful."

Comments

Improved Version Coming Next Year

[1sockchuck]

All fair criticisms, but it's a first step. The EPA plans to address many of the shortcomings of the current Energy Star for Servers program in an expanded Tier 2 spec that is scheduled to arrive in the fall of 2010. The update is intended to expand the program to include blade servers and servers with more than four processors.

Re:Improved Version Coming Next Year

[TooMuchToDo]

You're not the target market. My employer purchases tens of thousands of servers a year. One of our primary considerations is power efficiency. You know, total cost of ownership and all that jazz.

Atom

[googlesmith123]

Intel is releasing an Atom cpu for servers. It's not very powerful, but I reckon it has the highest power per watt of anything out there.

Re:Atom

[derGoldstein]

There's also the FAWN project (also on /.)

Cores-per-die is not a valid metric, not with emerging prototypes that could drastically change how web content is served.

Re:Atom

[mangu]

There's also the FAWN project

That's a very interesting link, I had never heard of that. I wonder how it compares with Cuda for parallel numerical computation? The article mention that they are considering using this concept for scientific computation.

Re:Atom

[drinkypoo]

FAWN is what Google is already doing. If you tried getting even cheaper compute nodes you'd run into price-per-port problems making it all talk. There IS a form of this that works, though, It's called blade computing, and we do it already. Using a stack of 500 MHz Geodes is NOT an effective way to get work done. Turning off idle servers IS. Server consolidation IS. Using a stack of commodity systems IS sensible, but not super-gutless ones. You need sigificant computer power per network port.

Re:Atom

[derGoldstein]

Google is leveraging economy of scale with their cargo containers. The primary benefits are modularity, and off-the-shelf components/interfaces.

However if you look at power usage and usage of space (which also translates into power, because of infrastructure costs), if you need "shallow web servers", then paralleling even "weaker" nodes could yield a better bottom line.

Blade computing, specifically, is extremely expensive. The reason is simply that you're buying high-end components which are intended for customers with cash reserves. What Google does is use CPUs/Motherboards/RAM/PSUs that are already on thin margins and massive distribution to a far broader audience. They've created their own modular, near-blade density model, which is far cheaper, and more robust (even if it does take up more space).

No, it isn't

[Idaho]

That's like focusing on how much gas a vehicle consumes at stop lights instead of when it's moving.

No, it's not. As usual, car analogies are stupid.

Cars do no spend the majority of their time idling at traffic lights. Computers (especially servers) however do often end up idling a very large percentage of the time.

Data centers do charge for (actual) power usage, so of course the actual (typically 95th percentile) usage should be taken into account, but still it's a broken analogy.

Re:No, it isn't

[value_added]

Well, it's less broken if you consider that in major metropolitan areas, cars do spend much of their time idling at traffic lights (typically with air conditioning running), as well as on congested city streets and freeways. Then, of course, there's the drive-thrus for those too fat to get out of their cars. ;-)

As for car analogies generally being stupid, yeah, you're right. But so are most of the alternatives. The reason why "sound bites", for example, are preferrable to hour-long analyses or 5,000 word flabby blog posts isn't that people don't want a full understanding, it's just that doing so is too much work. It's like having to evaluate a car purchase based on specifications instead of ... oh, wait.

Re:No, it isn't

[derGoldstein]

Regardless of the analogy (they were probably just thinking "dumb it down because we consider the people who read infoworld -- our audience -- to be idiots"), the part about the idling time usually isn't the case. Data centers will often outsource whatever "idle machine time" they have to various institutions, at least if they have any sense.
There are many computing tasks that aren't too time sensitive, and research projects can have considerable leeway in terms of when the final computation is done and the numbers need to be inserted into spreadsheets or whatever.

If there's low traffic during the weekend, get the machines to crunch data for some other purpose, otherwise they're not paying for themselves.

Possibly a better analogy for this would be "machine time scheduling" in a machine shop. You don't let the $200k CNC milling machine just sit there and take up space -- it cost too much. Find *something* for it to do.

By the way, your sig should say: "Every expression is true, for *any* given value of 'true'", IMHO.

Re:No, it isn't

[derGoldstein]

Well, it's less broken if you consider that in major metropolitan areas

It's less broken?

Listen here: either it works, or it's broken. There's no grey area here. I'm not going to buy an analogy and have it crap out on me when conditions become a bit sketchy. Reliability is key in this business -- if an analogy has any downtime, I'm liable for it. You might as well buy a car and expect it to...

ugh...

Re:No, it isn't

[mangu]

Cars do no spend the majority of their time idling at traffic lights.

I live in a place with severe traffic congestion problems, you insensitive clod!

Seriously, I think the car analogy is not so bad here. Too many people drive in the inner city using cars designed for cruising in an open freeway. Consider this: if so many cars weren't used in congested traffic, where would traffic congestion come from?

Re:No, it isn't

[MobyDisk]

Actually, I disagree. The analogy is very good.

Cars do no spend the majority of their time idling at traffic lights. Computers (especially servers) however do often end up idling a very large percentage of the time.

Both statements are not universally true.

Taxis, for example, may spend the majority of their time idling. So do big-city rush-hour commuters. And many servers idle 90% of the time, while others idle 10% of the time.

You can't make blanket statements about cars idle time, or computers idle time, since it probably varies 10000:1 based on the usage.

Re:No, it isn't

[iamhassi]

"That's like focusing on how much gas a vehicle consumes at stop lights"

No, it's not. As usual, car analogies are stupid.

I'd have to agree, bad analogy. MPG at stoplights is 0 for all cars since you're not moving. You'd have to come up with a whole new rating scheme if you wanted to determine how much gas a vehicle consumes at stop lights, like ounces consumed per hour while idling.

I'd say a better car analogy (if you must have one) would be to focus on what a vehicle gets on the highway only... and I mean all highway: fill-up, drive 60 until empty, fill-up again, compute mileage. Sure, it's a useful number, but it probably won't help you determine daily usage.

Re:No, it isn't

[Zerth]

Unless that CNC is the chokepoint for your shop or doesn't interact with any other resources in your shop, it should sit idle some of the time. Otherwise you are just creating excess work-in-process inventory.

Re:No, it isn't

[ergo98]

Data centers will often outsource whatever "idle machine time" they have to various institutions, at least if they have any sense.

I think you just imagined that.

Very, very, very, very (x4) few data centers do anything of the sort. And the truth is that the vast majority of servers spend the vast majority of their time waiting for something to do.

Yet Another Bogus Car Analogy

[Brama]

Comparing a server idling to a car in front of a red light is seriously wrong. Servers in general tend to spend a _lot_ more time idling than cars wait for a red traffic light. There'll always be servers that _do_ fully utilize their resources, but most of them will idle a lot. So it makes perfect sense to take that as a generic guide-line.

Re:Yet Another Bogus Car Analogy

[amorsen]

It's hard to even away the intra-day variation. I work for a phone company for corporate customers only, and basically all calls happen between 7am and 6pm. We run batch tasks at night, but they can't compare to the load that customers put on the servers during the day. The addition of cell phone calls have given our servers a bit more to play with at night, at least.

I suppose we could try to sell excess capacity at night, but I doubt we could make enough to make up for the required extra staff and hardware. Everyone else has idle servers at night too, except for other time zones, and latency generally kills any ideas to utilize servers across time zones.

Anyway, idle power is free for us (we pay for peak, whether we use it or not), so from an economic perspective there's no point to optimize for it. Marketing us as energy-conscious is worth a bit though, so we would get Energy Star compliant servers if the extra cost is small. So far we're focusing on reducing peak consumption, and in all modesty I think we're fairly good at it. (Our new 7600-routers ruin the score a bit. They suck too much juice. )

Re:Yet Another Bogus Car Analogy

[Abcd1234]

No. The biggest reason for virtualized servers is that everyone noticed that typical servers spend much of their time idle, so if we throw a 4 servers into one physical box, the hardware will stay utilized. This means we need fewer physical boxes, which means we need less power.

Except, of course, that those servers? Yeah, they're typically busy *at the same times*, because when they're busy, they're busy because people are working.

Personally, I'm extremely skeptical of the idea that virtualization means that overall utilization of hardware settles in at a higher median. My bet is that what you really see are larger swings. ie, all the servers on the virtualization box becoming busy during the same times (ie, work hours during the week), and then going largely idle during the same times (ie, at night and on weekends).

I'm looking forward to completing your training

[BadAnalogyGuy]

the spec only considers how much power a server consumes when it's idling, rather than gauging energy consumption at various levels of utilization. That's like focusing on how much gas a vehicle consumes at stop lights instead of when it's moving

In time, you will call *me* master.

This is a great v1

[sirwired]

Speccing by idle power consumption was a great idea. How exactly was the EPA supposed to grade servers based on CPU "efficiency" when each CPU differs so much? Which of the bazillion CPU benchmarks out there do you choose? This would be a short trip into an epic flame war between vendors, meaning that the spec would never get passed. "Politics is the art of the possible"

Given that most servers spend almost all their time idle anyway, this could certainly be a big money and energy saver. If you ever stroll through an actual large datacenter, you can see, via HDD ligts, that most of that gear just sits there all day long, doing little actual work. Certainly there are some servers lit up constantly, and virtualization will help to clean some of the idle servers up, but many shops don't do much virtualizing yet.

SiWired

Just use VMware's DPM

[acoustix]

VMware Distributed Power Management

Supposedly it will cut your server power usage by 50%.