Interrupted!

I’d been here before, a long time ago, with the world’s fastest 1.2GHz Athlon PC – another home machine that I “turned over” and didn’t play with that much, being unhappy with its performance, until one day curiosity got the better of me. I dug a little deeper into its shoddy streaming video performance and found that, with the right combination of cards in the right slots and the serial and parallel ports on the motherboard disabled in the BIOS, this machine went from running like a plain JCB to running like the JCB Dieselmax world-record holder. The fact was that the motherboard didn’t have enough interrupts to handle all the bits it was being dealt.

I’d imagined that all such nonsense was well and truly over with by the time Dell produced the 470 (and PNY the Nvidia card I bought), but no, the machine wouldn’t run until I found a separate Intel PRO/1000MT card and put it into the only other spare PCI slot, disabling the onboard card and as many other unused ports and parts as I could live without via the BIOS. I know what the hardware geeks are going to say: “Tsk, tsk, what do you expect if you buy a cut-down, bargain-basement, non-standard PC?”

Proper chipsets don’t have that problem, so, to a degree, I think the geeks would be quite right. That’s why I keep a pile (now five high) of old “real” pre-merger HP Netservers for my own network. It doesn’t matter what I stick into their expansion cages – they’ll still steam along at full chat – and I like their 2U form factor, which is thin enough to go in my rack but fat enough to live with in my non-air-conditioned basement. In emergencies, I’ve run 60 users off a well-configured LP2000R, which has dual 1GHz Pentium IIIs, so by extrapolation one might expect that a dual 3.2GHz Xeon machine would be strong enough for one humble web-surfing, word-processing user. True, but only so long as those Xeons are fitted on a motherboard that doesn’t continually trip over its own pants.

No sooner had I banged my head against this interrupt problem at home than it came up twice more in my business. One of my clients ended up in the unenviable position of having to kick off his disaster-recovery plan, which involved making use of a warm-spare server. This was as close a match as we could find to his live running server, which was, coincidentally (don’t get the idea that I have any prejudice against them), a Dell 1750. The 1750 is an ultra-thin 1U-high data centre model and, even though his setup isn’t anything like a data centre, this main machine had been doing a remarkably good job of handling everything he could throw at it. This meant employing some add-on cards; namely, a SCSI controller for the tape drive and an expensive ISDN card to run the fax and VoIP-to-PSTN gateway (I know there are now other ways to achieve this, but there weren’t when he set it all up). When activating the warm spare server, the procedure was to take these cards out of the main 1750 (a dual 2.4GHz) and drop them into the offline machine (a dual 2.8GHz), then set off a partition image-restore process.

This all sounded good in theory, but in practice the warm spare started up more slowly than a Windows Smartphone, and this wasn’t due to the OS load process but the BIOS startup, especially when it reached the RAID controller’s information messages. It turned out on examination that once again the motherboard had all its interrupts allocated to parallel, serial, USB and RAID chips, so that adding those PCI cards to the cage slaughtered its performance. The BIOS seemed to have a perverse preference for leaving the obsolete parallel and serial interrupts unshared, while declaring the higher-numbered interrupts dedicated to all these later technologies to be shareable. This is a perfectly legitimate approach, of course, if the chipset gets the allocation process right. Eventually, we realised that by leaving one card out and disabling the serial interface, we could produce the proper level of performance. Then we looked at the smaller, older machine running the VoIP PABX and found it had much the same problem over co-existence between a 3Com LAN card and its onboard sound chip. Last time I checked, servers don’t need much in the way of high-fidelity sound reproduction…