Most people think of the processor as the most important choice in specifying any kind of personal-computer system. Our first lesson in building Linux boxes is this: for Linux, the processor type is nearly a red herring. It's far more important to specify a capable system bus and disk I/O subsystem.

One important reason for this is precisely because PC systems are marketed in a way that presents processor speed as a primary figure of merit. The result is that the development of processor technology naturally has gotten pushed harder than anything else, and off-the-shelf PCs have processors that are quite overpowered relative to the speed of everything else in the system. Your typical PC these days has spare CPU-seconds it will never use, because the screen and disk and modem and other peripherals can't be driven fast enough to tax it.

If you're already running Linux, you may find it enlightening to keep top(1) running for a while as you use your machine. Notice how seldom the CPU idle percentage drops below 90%!

It's true that after people upgrade their motherboards they often do report a throughput increase. But this is often more due to other changes that go with the processor upgrade, such as improved cache memory or an increase in the system bus's clocking speed (enabling data to get in and out of the processor faster).

The unbalanced, processor-heavy architecture of PCs is hard to notice under DOS and Windows 3.1, because neither OS hits the disk very much. But any OS that uses virtual memory, and keeps lots of on-disk logs and other transaction state, is a different matter -- it will load the disk more heavily and suffer worse from the imbalance.

Linux is in this category (and, I'd guess, Windows NT and OS/2 are too). Assuming you're buying for Linux a fixed budget, it makes sense to trade away some excess processor clocks to get a faster bus and disk subsystem.

The truth is that any true 32-bit processor now on the market is more than fast enough for your disks under a typical Linux-like load, even if it's a lowly 386/25! Your screen, if you're running X, can be a bit more demanding -- but even a 486/50 will let you drag Xterm windows around like paper. And that's way slower than the cheapest new desktop machine you'll be able to find by the time this article hits paper.

So buy a fast bus. And (especially) buy fast disks.

How does this translate into a recipe? Like this:

Buying PCI will get you maximum bus throughput, and makes sense from several other angles as well. The doggy old ISA bus is clearly headed for extinction at this point, and you don't hear much about its other competitors (EISA, VESA local-bus video, or MCA) anymore. With PCI now being used in Macintoshes and Alphas as well as all high-end Intel boxes, it's clearly here to stay, and a good way to protect your investment in I/O cards from rapid obsolescence.

The case for SCSI is a little less obvious but still compelling. For starters, SCSI is still at least 10%-15% faster than EIDE running flat out. Furthermore, EIDE is still something of a jerry-rig. Like Windows, it's layered over an ancestral design (ST-512) that's antiquated and prone to failure under stress. SCSI, on the other hand, was designed from the beginning to scale up well to high-speed, high-throughput systems. Because it's perceived as a "professional" choice, SCSI peripherals are generally better engineered than EIDE equivalents. You'll pay a few dollars more, but for Linux the cost is well repaid in increased throughput and reliability.

For the fastest disks you can find, pay close attention to seek and latency time. The former is an upper bound on the time required to seek to any track; the latter is the maximum time required for any sector on a track to come under the heads, and is a function of the disk's rotation speed.

Of these, seek time is more important and is the one manufacturers usually quote. When you're running Linux, a one millisecond faster seek time can make a really substantial difference in system throughput. Back when PC processors were slow enough for the comparison to be possible (and I was running System V Unix), it was easily worth as much as a 30MHz increment in processor speed. Today the corresponding figure would be higher!