I enjoy running, and I typically train with a heart rate monitor to help me stay in a certain zone during my workouts.  When I was out on a run the other day and started to settle into my zone, instead of my mind drifting off to a peaceful place (like it should), for some reason it started drawing parallels about the human heart and Turbo Boost Technology.  I decided to play along as I was my own captive audience.

Let’s start with the heart, which as a pump has evolved over a long time to be pretty darn reliable and adapt quickly based on the needs of its owner.  It’s nominally rated at about 70-100 beats per minute (BPM), which is all it needs to do to support most activities during a normal day.  If you take care of it and operate it within spec, it should provide many years of reliable service in that range. 

However, we know the heart is capable is much higher rates, and most every day I operate it well above the rated 70-100 BPM during my runs.  As long as I take in enough air, don’t overheat, or don’t cramp up, my heart can maintain these higher rates without much problem.  In fact, if I feel REALLY good on a particular day, I can probably go above my max heart rate, but it’s not recommended and a lot of bad things can happen (a typically accepted max BPM calculation is 220 BPM – your age).

How does this relate to Turbo Boost Technology?

Xeon® 5500 processors are spec’d at a rated frequency (for example, 2.93 GHz), and the processor and platform are designed to operate for an indefinite period of time at that frequency.  With Turbo Boost, the processor is now able to run higher than rated frequency whenever you need a boost in performance, provided it meets the following conditions:  (1) the operating system requests the extra performance (I want to go out running), and (2) the processor has power, current, or temperature headroom (I’m getting enough air, and not overheating or cramping up).  As long as those conditions are met, the processor will run at those higher frequencies to maximize performance whenever it’s needed, either for short periods, long periods, or somewhere in-between.  When your performance demands drop, the processor frequency drops down to normal.

How high can you Turbo?

Similar to your maximum heart rate, we need to set Turbo Boost frequency limits in the Xeon® 5500 processors.  For example, the highest Turbo frequency the 2.93 GHz processor can support is 3.33 GHz, which is a 400 MHz jump.  While there still could be platform headroom even at the highest Turbo Boost frequency (I’m still feeling good at my max heart rate), we need to set these limits to ensure the processors will function reliably for a good long time.

So let your servers get some exercise with Turbo Boost – they’ll thank you for it.

Let’s face it; it’s getting harder to measure server density in rack units, and measuring by compute threads in a rack isn’t getting any easier with the core/thread counts increasing year over year.  I still remember from 12 years ago when Intel was acquiring companies who were really good at piecing together single core multi-processor systems and those systems were literally hanging from engine hoists (for demo purposes) because they were so large… I believe they had eight Intel Pentium Pro processors and 128MB of RAM. In comparison - today’s netbooks have more 4 times that amount of memory, in a base configuration.

Modern server micro-architectures have such a large increase in transistors alone, that it’s hard to equate the exponential growth in the complexity of the systems. While power must still be consumed, the same amount of power can be distributed across several cores and platforms now - which is more power efficient, but it also adds more complexity as the number of nodes increase. But just because you have more nodes, doesn’t mean that you can’t manage their efficiency.

David Ott (from the Intel Software Services Group) presents many of the provisioning/power/manageability problems at hand in the video below (5m16s), and explains how Intel is providing the 'touch points' to manage server platforms:

With the upcoming Intel Xeon 5500 Series Processors, not only do you have a high-performing platform; and in Intel fashion they’re also more power-efficient.  With the capabilities to self-throttle power usage via managed P-states per node or be managed via policies by group, time, etc.  Managing for servers isn’t new, but the way that Intel is doing it is a huge leap ahead in manageability at the node level.

So I ask:

• What manageability tools are you using for your enterprise servers today?
• Is Intel Node Manager on your (or your OEM's) roadmap to gather information on a ‘per server’ basis?
• Would more discrete information enable you to run your datacenter more efficiently?
• What manageability items do you struggle within your own datacenter, and what would you like to see in future platforms?

If Power Manageability is new to you, I highly suggest you check out Intel Dynamic Power Datacenter Manger, and if you're running a Linux based server - please check out http://www.lesswatts.org to ensure you have the latest ACPI compliant kernel.

And as a fun exit, here’s a video that we shot in one of our labs – further strengthening the need for virtualization

(and more importantly – the need for virtualized networks!)

So are you among the approximately 40% of data center managers that are projected to run out of power or cooling capacity in the next 12-24¹ months and need new options to deal with ever increasing demand for compute capacity? In my discussions with IT professionals, it’s clear that a “business as usual” approach to the design and operation of the data center is no longer sufficient.

In the coming weeks, you will see a number of bloggers write about using Intel Xeon Processor 5500 (Nehalem) servers to refresh the data center – a concept first discussed on this site back in late 2007 - to more efficiently use limited power, cooling and floor space resources in the data center. Today, I want to touch on another means of addressing these issues at hand - using instrumentation as a source of data and controls to better monitor and manage the data center.

Individual pieces of the data & control picture have steadily come into the mainstream via instrumentation of individual server components. Think processors that allow power & frequency to be modulated. Power Supplies that report system level power consumption. Memory that reports its temperature. Fans that can scale RPMs and power to the actual air flow requirements. Really cool capabilities, but these somewhat fragmented sources of data and control don’t provide the capability to manage at the rack or data center level. The challenge at hand is to take all of these individual points of component instrumentation and develop system and data center level capabilities – what I call extended instrumentation – to provide unique and innovative tools that data center managers need.

One of the more exciting extended instrumentation capabilities that has evolved is power capping. Power limits or caps defined and communicated by console management software are enforced by system level functionality, enabling the ability to limit system power in a dynamic fashion. Applications of the use of power capping range from increasing performance density to temporarily shedding compute load to ride through power or thermal events in the datacenter to enabling power based dynamic resource balancing. Power Capping gives IT managers a tool to squeeze additional compute performance out of their existing data center – making more efficient use of their limited and valuable power, cooling and floor space resources to lower costs, improve availability and extend the life of the current data center.

Are you evaluating this capability? Are you using it already? I’m interested in discussing your thoughts on instrumentation and power capping.

1. http://www.infoworld.com/article/08/03/26/Datacenters-heading-for-cash-crunch_1.html