In our last article, I showed that the current power management does not seem to work well with the Windows Scheduler. We got tons of interesting suggestions and superb feedback. Also several excellent academic papers from two universities in Germany which confirm our findings and offer a lot of new insights. More about that later.The thing that is really haunting me once again is that our follow up article is long overdue. And it is urgent, because some people feel that the benchmark we used undermines all our findings. We disagree as we chose the Fritz benchmark not because it was realworld, but because it let us control the amount of CPU load and threads so easily. But the fact remains of course that the benchmark is hardly relevant for any server. Pleading guilty as charged.
So how about SQL Server 2008  Enterprise x64 on Windows 2008 x64? That should interest a lot more IT professionals.We used our "" SQL Server test, you can read about our testing methods here. That is the great thing about the blog, you do not have to spend pages on benchmark configuration details :-). Hardware configuration details: a single Opteron 2435 2.6 GHz running in the server we described here. This test  is as real life as it gets: we test with 25, 50, 100 and so on users which fire off queries with an average rate of one per second. Our vApus stresstest makes sure that all those queries are not sent at the same time but within a certain time delta, just like real users. So this is much better than putting the CPU under 100% load and measuring maximum throughput. Remember in our first article, we stated that the real challenge of a server was to offer a certain number of users a decent responsetime, and this preferably at the lowest cost. And the lowest cost includes the lowest power consumption of course.  
While I keep some of the data for the article, I like to draw your attention to a few very particular findings when comparing the "balanced" and "performance" power plan of Windows 2008. Remember the balanced performance plan is the one that should be the best one: in theory it adapts the frequency and voltage of your CPU to the demanded performance with only a small performance hit. And when we looked at the throughput or queries per second figures, this was absolutely accurate. But throughtput is just throughput. Response time is the one we care about.
Let us take a look at the graph below. The response time and power usage of the server when set to performance (maximum clock all the time) is equal to one. The balanced power and response time are thus relative to the numbers we saw in performance.  Response time is represented by the columns and the first Y-axis (on the left), Power consumption is represented by the line and by the second Y-axis (on your right).
 The interesting  thing is that reducing the frequency and voltage never delivers more than 10% of power savings. One reason is that we are testing with only six-core CPU. The power savings would be obviously better when you look at a dual or even quad CPU system. Still, as the number of core per CPU increases, systems with less CPUs become more popular. If you have been paying attention to what AMD and Intel are planning in the next month(s), you'll notice that they are adapting to that trend. You'll see even more evidence next month.
What is really remarkable is that our SQL Server 2008 server took twice as much time to respond when the CPU is using DVFS (Dynamic Voltage Frequency Scaling) than when not. It clearly shows that in many cases, heavy queries were scheduled on cores which were running at a low frequency (0.8 - 1.4 GHz). 
I am not completely sure whether or not CPU load measurements are completely accurate when you use DVFS (Powernow!), but the CPU load numbers tell the same story.
The CPU load on the "balanced" server is clearly much higher. Only when the CPU load was approaching 90%, was the "balanced" server capable of delivering the same kind of performance as when running in "performance" mode. But then of course the power savings are insignificant. So while power management makes no difference for the number of users you can serve, the response time they experience might be quite different. Considering that most servers run at CPU loads much lower than 90%, that is an interesting thing to note.
Comments Locked


View All Comments

  • JohanAnandtech - Thursday, February 18, 2010 - link

    I have been talking to the people who designed the PCU of the Nehalem CPUs in Portland. Came to some excellent insights there, more later :-).
  • Theunis - Thursday, February 18, 2010 - link

    So when will the Linux 64bit tests commence? And wouldn't it make sense to change governors based on peak/low period? aka on-demand vs performance governors.

    And gcc with tests, compiled applications with gcc -march=native -mmmx -msse -msse2 -msse3 -mssse3 -msse4.1

    and all the other types optimization
  • Anato - Thursday, February 18, 2010 - link

    Isn't it governors task to manage frequency not by some script? If governor responses quick enough penalty of frequency scaling will be low. And linux can keep processes on same core, so no bumping around.

    Please test with distro's standard compillated packages or close to them, no fancy optimizations.
  • JohanAnandtech - Thursday, February 18, 2010 - link

    Linux testing is the reason why I was postponing the article. I am going to finish up the Windows work and then start linux testing again. Otherwise the article is going to take too long.

    What do you mean by the gcc test? Why the inclusion of the SSE optimizations?
  • Theunis - Friday, February 19, 2010 - link

    Can't wait to see the Linux review. The reason for asking about cpu optimizations is because it would be interesting to see how optimizations influences power usage and of course does it actually increase performance too. So you can use another scale power/performance/optimizations. I believe the the cpu's true power/performance would show when used with optimizations, combined with the scheduler. I guess we Gentoo server users would like to know :)
  • MrSpadge - Friday, February 19, 2010 - link

    The benefit of cpu / instruction set optimizations greatly depends on the actual program, how it's written, how smart the compiler is and ultimately on the algorithm itself.
  • Lord 666 - Wednesday, February 17, 2010 - link

    While you might be waiting for the next round of Intel chips, it would be interesting and more of a service to readers to do the same review with a 5560.
  • Goty - Thursday, February 18, 2010 - link

    Is there any particular advantage you think a Nehalem-based chip would have over an Opteron in this sort of comparison (i.e. one that does not depend on raw performance)?
  • MrSpadge - Friday, February 19, 2010 - link

    It can power cores down completely when not needed and doesn't have to rely on clock & voltage switching alone to reduce idle power.
  • mino - Monday, February 22, 2010 - link

    Clock gating will happen now matter the P-state.
    It is irrelevant to this test.

    This test was about evaluating the behavior of different P-state management plans.
    Nehalem is similar to Opteron in this P-state management effect.
    Also, P-states are usually less used in Nehalem servers so compared to Opterons the difference would be harder to measure.

Log in

Don't have an account? Sign up now