Itanium target for migration tests fast

HP 3000 K-12 app provider test-drives HP box

By Duane Percox

The QSS migration plan has always included IA-64 as a target, using both HP-UX and Linux as supported operating systems for the application server. Recently we announced support for 64-bit SQL Server, running on Itanium, as a supported database server. We were excited to get the opportunity to install one of HP’s rx2600 systems with dual Itanium 900Mhz (McKinley) CPUs to test out these operating environments running on Itanium. This is the field report from our first tests of HP’s new architecture.

Our system was not state of the art — you now can buy Itanium systems with the new 1.5GHz (Madison) chip. But it was good enough to help us get an understanding of the new chip and how it ends up being packaged into a server-class system. In fact, the rollout of Itanium feels a lot like the days back of the 1980s while PA-RISC was being rolled out. Early versions of any chip are nice, but nothing to get excited about. Eventually you get performance that makes you very excited. Except, of course, that our favorite operating system, MPE, doesn’t happen to run on the new chip, this time around.

All of our migration work to date had focused on Linux running on IA-32 servers, and HP-UX running on PA-RISC. So we were eager to un-box the new server, test out compatibility, and get a basic performance and useability evaluation.

Our goals are to test Linux, HP-UX and Windows 2003/SQL Server (64-bit) on this system, but it came pre-installed with Red Hat’s Linux Advanced Server (64 bit for Itanium), so that is what we have been evaluating.

The engineering on this server is very nice. Physically it’s the same size as the HP 3000 A400 systems we have, but it uses a completely different design. It has a hot-plug drive bay (on the front left) for three drives which can be connected to two internal SCSI ultra-320 channels in varying configurations. It has DVD-ROM, integrated 10/100/1000 networking, separately laid-out dual hot-plug fans for disk/memory/CPU, hot-plug power supply, and a quick-entry SCSI card cage for four add-in SCSI cards.

It is plumbed for dual power supplies, but that is an option and not standard with the basic system. There are adapters for VGA, mouse, keyboard and a standard console (I imagine for HP-UX).

The system has 12 memory slots arranged in a 3x4 configuration when the system is configured as a server, with memory installed in four identically-sized sticks called a quad. Our system came with 4Gb of memory using eight half-gigabyte memory sticks, otherwise known as 2 x 2Gb quads. You can get 24Gb into this server using HP memory — or third-party memory, which is substantially cheaper. However, to get 24Gb you need 2Gb memory sticks which are expensive, even from the third-party suppliers at this time.

You may have read about the Itanium being a heat-producing chip. One look at the massive copper heat sinks and directed-fan cooling confirms everything you have read!

Binaries, libraries

Hardware is nice, but I’m a software guy so it doesn’t matter how good the engineering is. If it can’t run our software then it’s not much use. After installation and setup, which was pretty painless, we fired up the beast to see how well Linux on Itanium was working.

All the Linux binaries loaded on the machine appeared to be native IA-64 compiled, and there were IA-32 equivalent libraries installed, so we could run IA-32 code with the required libraries. When running IA-32 code on IA-64 you are using the built-in emulation mode of the chip, which can emulate the x86 instruction set.

During our early testing we constantly kept confusing IA-32/IA-64 and which code/mode we were running in. Finally, we just succumbed to old habits and adopted a simple and familiar MPE nomenclature. When running IA-32 code on IA-64 you were running in CM or CM code. And when running IA-64 code on IA-64 you were running in NM or NM code.

Language performance

The feel of the system was very nice, with performance of basic system tasks that you would expect. We ran some comparisons of scripting languages like Python and TCL between IA-64 and IA-32 with varying results. It seemed to us that Python/64 was faster than Python/32, but TCL/64 and TCL/32 were about the same performance.

We use Fujitsu NetCOBOL to compile our migrated COBOL code, so testing that code running on IA-64 was of great interest to us. NetCOBOL is a 32-bit compiler which generates IA-32 code, and Fujitsu has no current plans for making it generate IA-64 native code for Linux. We have the compiler running on an IA-32 development system where our compiled code is developed/located.

We installed the NetCOBOL run-time system on IA-64 without any problems and moved over our compiled COBOL programs from the IA-32 system. We were able to run every COBOL program without any problems, and found it to be essentially seamless and painless to run CM binaries on the IA-64 box. Painless, except for the performance. CM code ran slower than the same code on a Pentium III 1GHz system. But its performance was still faster than the fastest HP e3000 system we had tested, or which has been installed by our customers.

Next issue: Database test results, and how the application’s CM code fared.

Duane Percox is a member of the SIG-Itanium Executive Committee and a founder of QSS, an HP 3000 K-12 application provider.