Our new product, the Intel Xeon Processor 5500 series, has ushered in what we at Intel call a new generation of intelligent server processors. Before I wrote this blog I had to look up the definition of intelligence (American Heritage Dictionary):

In•tel•li•gence n 1.a. The capacity to acquire and apply knowledge. b. The faculty of thought and reason.

In this context, I’d like to discuss two topics. (1) An Intelligent Product (2) An Intelligent Choice

An Intelligent Product: (the capacity to acquire and apply knowledge)

Key technology enhancements to the Xeon 5500 include a suite of new features and capabilities that enable servers utilizing these new processor to serve a wide range of server usages (from basic business to high performance computing) (from single threaded applications to well threaded applications) (from non virtualized to highly virtualized environments) and makes these servers adaptable to the environment you want to deploy it into.

ð       Intel Hyper-Threading Technology is back boosting performance for well threaded applications

ð       Intel Intelligent Power Technology adjusts server power consumption real time to workload

o       Automated Low Power States reduces CPU, Memory and I/O power without impacting performance

o        Integrated Power Gates dynamically turn cpu cores that are not in use to reduce idle power near 10W

ð       Intel Turbo-Boost Technology speeds up your processor when application demands peak

ð       Intel QuickPath Technology provides industry leading server bandwidth (up to 3.5x prior Xeon)

The benefits for IT and Business?

ð       A server platform that can adapt to your application environment allowing you to deploy it in one environment today with the knowledge you can repurpose it tomorrow, if needed

ð       A server platform that can adapt you changing workload demands over the course of a day, saving power when demands are low and better performance when you need it most

Read the Intel Xeon processor 5500 series platform brief to learn about these technologies

Visit this video about the new product and the technologies listed above

An Intelligent Choice: (the faculty of thought and reason)

Economic times are tough and we’re all struggling with spending choices (or not spending) at both a personal and corporate level. However, business spends about 2/3 of their IT budget maintaining existing servers (source IDC). IDC further estimates that 40% of the servers installed today are 4yr+ single core servers with another 40% being 3 year old dual-core. These servers are consuming a lot of valuable resources. With a heavy % of IT budget spent on operating costs, the challenge is that if you cut spending, you are cutting innovation. This limits business competitiveness.

What is the option? …. Server Refresh. Compared to installed single core Xeon servers, these new Xeon processors enable up to 9x performance per server, a 9:1 server consolidation opportunity (with flat performance), lowering operating costs by an estimated 90% and delivering an estimated up to 8 month payback on investment. That means that an investment in a new server today can pay for itself in less than a year, helping you to self fund more innovation or helping to boost the bottom line of your organization. If your environment is dual-core based, the opportunity is about a 3:1 consolidation opportunity.

               Download this pdf to understand the 8 month estimate

View a video demonstration highlighting the 9:1 consolidation and 3:1 consolidation

In summary the Xeon 5500 series is an intelligent product in it’s capability to adapt to both it’s application and user environment and an intelligent choice for IT investment delivering an estimated up to 8 month payback – much better than you can do in the stock market, bank or many other projects.

I think that this is the right product at the right time.  What do you think? ... I'd like to hear your reactions.

Chris

Here’s the 7th follow-up post in my 10 Habits of Great Server Performance Tuners series. This one focuses on the seventh habit: Document and Archive.

I hope the reason why you need to document and retain data for any performance project is understood, so I won’t go into it. Nor will I recommend particular documentation solutions – just find a database or filing solution you like that gets the job done. What I will do is list what needs to be documented.

Normally, performance tuning consists of iterating through experiments. So, for each experiment, it is important to document:

• What changes were made – hopefully you weren’t trying too many things at once!
• The purpose – why you tried this particular thing (including who requested it, if appropriate
• General information – date & location of testing, person conducting the test
• Hardware configuration:
• • Platform hardware and version, BIOS version, relevant BIOS option settings
  • CPU model used, number of physical processors, number of cores per processor, frequency, cache size information, whether Hyper-Threading was used (cpu-z can help document all this)
  • Memory configuration – number of DIMMs and capacity per DIMM, model number of DIMMs used
  • I/O interfaces – model number of all add-in cards, slot number for all add-in cards, driver version for all devices (on Windows*, msinfo can help with this, on Linux*, lspci)
  • Any other relevant hardware information, such as NIC settings, external storage configuration, external clients used, etc if it affects your workload
• Software configuration:
• • Operating System used, version, and service pack/update information (use msinfo on Windows systems, uname on Linux systems)
  • Version information for all applications relevant to your workload
  • Compiler version and flags used to build your application (if you are doing software optimization)
  • Any other relevant software information, such as third-party libraries, O/S power utilization settings, pagefile size, etc if it affects your workload
• Workload configuration:
• • Anything relevant to how your experiment/application was run, for example, your application’s startup flags, your virtualization configuration, benchmark information, etc
• Results and data - naturally you would store all the above information along with the results and data that accompany your experiment

This blog entry is also the appropriate place to for me to mention the role of automation in your tuning efforts. If you are going to be doing a significant number of experiments, invest the energy needed to set up an automation infrastructure – a way to run your tests and collect the appropriate data without human attention. I included links to automated ways to gather the above data where appropriate.

Keep watching The Server Room for information on the other 3 habits in the coming months.

At Oracle OpenWorld in the Dell booth on September 22nd – 24th, we educated a large number of IT managers and Oracle Database Administrators about how best to harness the power of the new Xeon 7400 processor for their Oracle Middleware and Database environments. Check out this video and learn about the Xeon 7400 based Dell PowerEdge R900, the features / benefits of this new platform, the virtualization performance advantages, and the energy efficiency benefits of Intel’s 45nm manufacturing process.

If there is one thing that has stayed consistent in the computing industry over time, it's that performance doesn't stand still. As our computing platform processing, I/O, and memory speeds continue to accelerate, it is important to remember a little thing called latency.

Often in the Ethernet world throughput is the 1^st and last performance metric of choice. 1 Gigabit and 10 Gigabit are the numbers that inspire thoughts of increased performance, and improved computing power. However, it's important to note that, in many applications, the transaction latency over the wire is really the key to unlocking high performance at the system level. One of the primary reasons that some organizations have turned to Infiniband and other I/O technologies for HPC and clustering in the past has to do with their desire to achieve very low latencies, not necessarily increased throughput. If you look at a historical standard Gigabit Ethernet connection, you may see latencies that are around 125μs. This may have been ok in the past, but as improvements at the application level as well in the system hardware and CPU take hold, legacy Ethernet won't be good enough for HPC and clustering environments.

The interesting, and often overlooked fact with Ethernet is that the latency characteristics are improving as the industry moves from 1 Gigabit to 10 Gigabit. The faster throughput on the wire comes along with lower latency to some extent, but in addition, there have been several improvements in interrupt handling that drastically improve overall latencies when comparing legacy 1Gigabit to 10Gigabit. With a basic 1^st generation Intel® 10Gigabit CX4 card you can now see latencies approach 25μs without any special tuning.

What's even better is that Intel's 10 Gigabit networking silicon also has further enhancements for improving latency by introducing some new specialized Low Latency Interrupt (LLI) filters in the silicon. These filters provide the hardware with a quicker reaction time to network packets that meet certain customizable criteria. The filters can be tuned to have a rapid response to certain packet and traffic types. With these kinds of LLI filters in place, latencies can be reduced further by another ~50% to ~14μs.

Going forward with 10 Gigabit there are new technologies and designs that can help push latency even lower to the sub-10μs threshold to keep Ethernet very competitive as a fabric not only from a cost and throughput perspective, but also from the perspective of latency.

And while lower latency is certainly important, the last piece that was really missing from the Ethernet performance puzzle was not just low latency, but deterministically low latency. The key is that the worst case packet latencies for many applications are relevant and very important. By application thread affinitization, the individual data thread can be piped directly between a network queue and a CPU core. By more evenly distributing the networking workload between CPU cores in a predictable fashion, you get a deterministic kind of latency that does not stray far from the average assuming CPU cores do not get oversubscribed. Average latency of ~14μs is good, but the fact that you can get this with reasonable determinism is a key for many applications and usages.

Now, lower, deterministic latency is not just a theoretical benefit for certain niche applications. Decreasing latency and improving overall latency characteristics while increasing throughput directly benefits the transaction rates that can be achieved with real world applications. As an example of the improved performance is the latest Reuter Market Data Systems (RMDS) benchmarks done by STACResearch on the 4-way Intel® Xeon E7450 (Dunnington) using the Intel® 82598EB 10 Gigabit AT Dual Port networking adapter. The testing showed the Highest Point-to-Point Server throughput to date on a single server in testing done by STAC. And total updates per second reached over 15 million. Financial Service industry administrators: I can see you drooling...

Latency and throughput numbers are great to talk about, but at the end of the day, real world application performance on real systems is the key. While there will always be a small subset of the high end server market that needs the absolute lowest latencies provided by Infiniband; 10 Gigabit Ethernet is gaining ground while maintaining its place as the default fabric of choice for multiple applications and traffic types. I believe the best is yet to come as newer, faster, and more responsive technologies continue to roll out.

Ben Hacker

"Live From" Oracle Open World and the Intel Innovation Zone...first impression...this is a big event. The Moscone Center here in San Francisco is rocking and Intel has some really interesting and cool demos inside the Innovation Zone. Check out this one where Intel is announcing a new Solid State Drive and demos it at the show:

Check back for more demos and show updates...

Here's the 6th follow-up post in my 10 Habits of Great Server Performance Tuners series. This one focuses on the sixth habit: Try 1 Thing at a Time.

Like habit 2, Start at the Top, this habit looks easy to understand and to keep. But, due to the constant desire for productivity, I and most others I know in the performance community have broken it many times. Some times I even get away with it. But trying to keep this habit is important, because when I don't get away with it, breaking this rule results in even more work than I was trying to save.

The concept behind this habit is simple - when you are optimizing your platform or your code, make only one change at a time. This allows you to measure the effect of each change, and only accumulate the positive changes (however small) into your workload. I have seen instances, for example, where 2 small changes applied at the same time to a workload cancelled each other out: one caused a small in performance and the other a small increase. If these changes weren't tested individually, we would have missed out on that performance gain.

Another thing that can happen in a complex workload is that two changes that seem independent can interact with each other. Like many developers know from fixing bugs, changing one thing may affect something else. Keeping all your changes separate can help you identify these interactions more easily.

You may be wondering when it is acceptable to break this habit. I think of performance methodology, and this rule in particular, as similar to the scientific method we learned in school. It's always good to follow it - doing so will help you quantify your successes and failures, stay organized, and defend your conclusions - but, you can still make a big breakthrough without it. In some cases, like when you are making small local changes to source code in completely different modules, or when you are changing two things you are certain won't interact, the habit can be broken. But the advice I give, especially to those involved in long-term optimization projects, is to follow it.

What has your experience been? Please share your "changing multiple things at one time" stories.

Keep watching The Server Room for information on the other 4 habits in the coming weeks.

I am currently sitting in PDX (Portland, Oregon) waiting for my flight to Dallas, then on to Sao Paulo, Brazil, then on to Porto Seguro, Brazil.

This is where our PR team is running an event called Intel Editor's Day (IED). This is the 3rd such event this year and I have had the pleasure of presenting Server Benchmarking at each event. The first in Mexico, the second in Costa Rica a few weeks ago. IED offers regional journalists a chance to get product information and demonstrations from Intel so they can be ready to report what they see, review, and evaluate when looking at these products in the market.

It's a team effort with these events. I am 'the server guy', yet I am carrying a few MID's and even an Atom demo card for my brethren (and sisteren?). I even have a wafer with me... something of the 45nm type. ;o)

The reason I am going is to talk with the 30+ journalists about distinguishing between client and server benchmarks. If you (the reader) don't know that there is a difference, there definitely is and you should let me know so we can offer some information for you to read about it.

My goal at IED is show a few benchmarks, talk about a few more (SPEC, TPC, etc.), and ultimately learn about how they might run these benchmarks. Education is the goal, but it goes both ways.

I'll add more when I get a chance... I have to grab a bite before getting on the plane.