Search results matching tags 'BladeSystem' and 'HPC'

I received a new HPC Multi-core server today – How to measure the power usage

d-field — Wed, 12 Nov 2008 00:38:00 GMT

Given that it is important to measure power usage and correlate it to application performance, how do you measure the power?

We use 2 different methods - one for rack-mounted servers and another for blade servers. The rack-mounted servers do not provide power meters, so we bought a power meter. We plug the server into the power meter, so we are measuring the total power used. Then, with a simple PC interface, we allow the application user on the server to obtain continuous power data which is easy to correlate with the applications.

This is easy for the users, but it requires planning and logistics and some work by our system managers, to connect the meter to the right server at the right time.

We often want to measure the power of a cluster running one HPC application in parallel, and it is usually sufficient to measure the power of any one server in the cluster running the application.

It is easier to measure power on an HP blade enclosure, since the enclosure contains power measurement capability and provides this data in a usable way. The available data includes the total enclosure power and also the power used by each blade server and each fan in the enclosure. We integrated this information with the Platform Computing LSF job scheduler. Now, users of our blade servers submit their jobs via LSF and automatically receive their power usage data as part of the job.

Next week, I expect to post a message from the SC08 conference.

I received a new HPC Multi-core server today - Initial performance testing

d-field — Wed, 01 Oct 2008 23:15:00 GMT

After the operating system boots on a new server model, it's time to start performance testing. I'm hoping to get some comments on this, since there are many different ways to proceed.

Personally, I am not a fan of industry standard benchmarks, but I think they are the best starting point for new product testing. For an HPC server, I want to check the basics, to ensure that the system meets its design goals - memory BW, memory/cache latency, 64-bit floating point math, and filesystem IO are the first measurements. We use STREAM, lmbench, LINPACK, and IOZONE standard benchmarks.

We compare the measurements to older models and to the goals of the new product. Since our group didn't design the product, we don't know if there are interesting but undocumented features which enhance or limit performance. I have a name for the process of performance testing of a new product - discovery engineering. We study the external behavior of a system and try to understand the design features which affect HPC performance.

Each of these standard benchmarks provides information about the server. In numerous cases, this information has solved performance mysteries in real codes. It is hard to solve a performance problem with a large, complex application. The standard benchmarks are a simpler starting point for problem-solving.

But we don't rely on industry standard benchmarks. By design, each one tests a subset of a server's performance characteristics. I've had little success predicting the performance of HPC ISV applications based on the standard benchmark results, since real applications require a balance of all the performance features in the system.

After using the standard benchmarks to assure ourselves that the system is running correctly, we can move on - measure performance on real ISV applications, and experimenting with multi-core processor configurations!

I received a new HPC Multi-core server today!

d-field — Tue, 23 Sep 2008 19:16:00 GMT

About this blog series - This is the 1^st posting of a series which describes the experiences of engineers who test the performance of HPC servers and server clusters at HP.

My name is Dave Field. I lead an engineering group at HP - we measure the performance of new HP servers. In addition to the common industry-standard benchmarks, we concentrate on the performance of real HPC ISV applications. In the 20+ years we have done this work, we have seen many server architectures. These days, HPC clusters of servers using multi-core processors occupy most of our energy.

We evaluate the performance of new server products, so receiving a new server model is a common occurrence. This has been an especially rich year for new products - this is the 14^th new HP server we've tested this year, with at least one more to go before the year is over. HP servers for HPC span the range of industry-standard processors - Intel Xeon and Itanium2 and AMD Opteron. (In HP terminology, the processor is the physical component which plugs into the system board. A processor contains one or more cores, or CPUs.) And for each processor type, there are specific models with different architectural features.

Since we test pre-production, or prototype, computers, it's not quite true that I received a server - we usually receive new product kits. Testing new products can be very interesting, but to get to the interesting part, there are inevitably a number of problems to solve. We need to turn the kit into a working computer, then ensure that the performance meets the product specs, before we can do meaningful performance evaluation. These initial steps are lessons in patience and expectation-setting, during which I always meet some new people who will help in problem-solving.

The new server kit usually contains the server enclosure, system board, and processors. To turn the kit into a computer, we need to obtain three layers of stuff - supporting hardware (the right DIMMs, network interfaces, and disks), firmware, and operating system.

Firmware is in flux during the pre-production period, and each version of pre-production firmware changes the server's performance. Usually the processors are pre-production versions, tied to specific firmware revs. Most of the performance data collected on these early versions will be discarded. But if we don't get some measurements now, we can't influence the product. Sometimes we identify performance issues which can be fixed before production release - so this is a very satisfying part of the job.

These days, the current versions of the major Linux distributions work out-of-the-box on new server models.

When the operating system boots, we can begin to measure performance!