Just how fast is that A-Class, anyway?
February 21, 2014
By Brian Edminster
Earlier this week, there was a report of an A-Class HP 3000 going wanting on eBay. It was being offered for $2,000 with no takers. The system at hand was an A400-100-110, the genuine bottom of the A-Class line.
While I'd argue that a $2,000 A400 with a transferable MPE/iX licence is a steal, there seems to be a lack of appreciation for the wide variance in speeds in what is considered a A-Class' system.
I believe the system that was being offered as a bare bones A400, as indicated by its system number "A400-100-110." The first character (A) is the class; the next three numbers (400) are the family; the next three are the number of CPUs (100, meaning one); and the last three are the HP rated speed in MHz of the PA-RISC CPU chip. (In this case, it's a PA-8500) This system on eBay also happened to be missing a tape for creating/booting from a CSLT, so if your boot drive failed -- or you needed to make configuration changes that required booting from tape -- you would be out of luck without buying a little more hardware.
This particular A400 system, according to the AICS Relative Performance chart mentioned in the article, runs at a 17. That's about 1.7 times faster (CPU-wise) than the original 917/918 systems. In IO-intensive applications, I have found it felt closer to 2 times faster. I have also worked on an A400-100-150, which CPU speed-wise is a 37. (That system also happens to allow installation of 2GB RAM vs. the 1GB limit on an A400-100-110).
So in short, we can have a greater than 2:1 performance potential between two servers that are both ostensibly A400 A-Class systems. And that's not even taking into account the advantages of multiple CPUs for performance in complex multi-user environments.
Performance benefits aside, multiple CPU systems have been, in my experience, more resilient to CPU failures. This is by virtue of having multiple CPUs. I've had multi-CPU systems where a single CPU failed, and if I had not noticed a minor difference in batch throughput, my online users wouldn't even have noticed. I simply scheduled a service call for the next day -- after warning my users of a previously unplanned service outage, and making sure the backups ran for the night.
It took longer for the hardware to self-test and MPE/iX to reboot than it took the service engineer to replace the bad CPU. Total un-planned down-time was about an hour. Not bad.
It was not quite hot-swap easy, like many modern RAID disk arrays. But that HP 3000 was plenty resilient enough to "Take a licking, and keep on ticking" -- as they once said of Timex watches.
Brian Edminster is the curator of the MPE Open Source repository and website www.MPE-opensource.org, as well as founder of an independent consultantancy.