Low Power Server CPUs: the energy saving choice?
by Johan De Gelas on July 15, 2010 4:54 AM EST- Posted in
- IT Computing
Translated to the datacenter
Before we make any conclusions based upon what we learned in this testing session, we should not forget the lessons learned from previous experiments. And those tests tell us that you should avoid the low end server CPUs: those are the most leaky ones, consuming more power at idle and low load.
Our conclusion on our new energy measurement methodology is:
1. Low power Xeons save power but do not save energy in a typical Hyper-v consolidation ratio. Power is “capped”, but the total energy consumed for a certain task is (more or less) the same.
2. X-series Xeons offer a much better performance per watt ratio, but at the expense of brief power peaks. They do not necessarily need more energy in the long run than the lower power versions, and offer much better response times if your application is CPU bound.
So if you have to pay the actual energy consumption, you have some amp headroom left before being penalized and performance matters to your users, the faster Xeons are the right choice. The benefit is that you can offer a lower response times to your users, even when the CPU is not running at peak load! The Xeon X5670 is more flexible.
In case you pay a fixed price for a fixed amount of amps and you get heavy fines in your mailbox if you briefly breach your amp limit, buying lower power Xeons is probably the way to go.
Then again, we are not very enthusiastic about power capping at the server level. Many companies have already embraced the idea of a Dynamic Scheduled Virtualized Cluster. VMware's vSphere product is the most mature here: it is pretty easy to build a virtual cluster with dynamic power management (DPM) and scheduling (DRS). We still have to investigate this, but if this virtual cluster works well with solutions such as HP Insight Power Manager or Intel’s own power node manager, the faster Xeon will get interesting once again. The basic idea is that you should power cap your entire cluster (or rack), not one server. You should not care that one server needs a little more power than usual, but the whole cluster should not exceed the amp limits described in your contract with the datacenter. That way you can reconcile low response times with low power bills.
A big thanks to Dries Velle for assisting us in the Sizing Servers Lab.
Facebook
Twitter
RSS
49 Comments
View All Comments
Zstream - Thursday, July 15, 2010 - link
It kills the AMD low power motto :(duploxxx - Thursday, July 15, 2010 - link
lol, all that you can say about this article is something about AMD. Looks like you need an update on server knowledge, Since the Arrival of Nehalem Intel has the best offer when you need the highest performance parts and when using Low power parts which give still the best performance. Since MC arrived things got a bit different mostly due to aggressive price for all mid value but still a favor to intel parts for highend and L power bins. Certainly in the area of virtualization AMD does very wellWhat is shown here should be known to many people that design virtual environments, Virtualization and low power parts don't match if you run applications that need cpu power and response all the time, L series can only be very useful for a huge bunch of "sleeping" vm's.
Interesting would be to compare with AMD, but 9/10 both low power and high power intel parts will be more interesting when you will only run 1 tile, the huge core amount lower ipc advantage will loose against the higher ipc/core of intel in this battle.
Zstream - Thursday, July 15, 2010 - link
Excuse me? I am quite aware of low power consuming chips. The point AMD has made in the past four to five years is that low power and high performance can match Intel's performance and still save you money. I have been to a number of AMD web conferences and siminars were they state the above.MrSpadge - Thursday, July 15, 2010 - link
Not sure if you're being sarcastic here, as it's obvious AMD would tell you this.
But regarding the actual question: you'd be about right if you compared K8 or Phenom I based Opterons with Core 2 based ones. And you'd be very right if you compared them to Phenom II. However, the performance of these Intels is being held back by the FSB and FB-DIMMs and power efficiency is almost crippled by the FB-DIMMs. But Nehalem changed all of that.
MrS
duploxxx - Friday, July 16, 2010 - link
4-5 years.... Nehalem was launched q12009 since then all changed. Before that Xeon parts suffered from FBDimm powerconsumption and FSB bottleneck and that is why AMD was still king on power/performance and was able to keep up with max performance. Nehalem was king, Istanbul was able to close the gap a bit but missed raw ghz and had higher power needs due to ddr2, again MC parts leveraged back this intel advantage and now there is a choice again, but L power still is king to Neh/Gulf.Penti - Saturday, July 17, 2010 - link
It invalidates low power versions of AMDs also. That's he's point I would believe.stimudent - Thursday, July 15, 2010 - link
Not really.If there can't be two sides to the story or a more diverse perspective, then it should not have been published. Next time, wait a little longer for parts to arrive - try harder next time.
MrSpadge - Friday, July 16, 2010 - link
A comparison to AMD would have been nice, but this article is not Intel vs. AMD!It already has 2 side: high power vs. low power Intels. And Johan found something very important and worthy of reporting. No need to blur the point by including other chips.
MrS
Zstream - Thursday, July 15, 2010 - link
I know we have the VMware results but could someone do an analysis on AMD / INTEL chips?For instance I can get a 12 core AMD chip or a 6 core/12 HT chip from Intel. Has anyone done any test with Terminal Servers or Real world usage of a VM (XP Desktop) with core count?
I would think that a physical 12C vs 6C impacts real world performance by a considerable large amount.
tech6 - Thursday, July 15, 2010 - link
Great work Anandtech - it's about time someone took the low power TCO claims to task.