It often happens that a macho computer with enough muscle performs below expectation. The reason could be a "weak-link-in-the-chain" (pathetic hardware) which reduces the system's overall performance). This happens when the system is configured sub-optimally. Fine tuning a PC for optimum performance is among the finest ways to spend time. For the academically oriented, it is an invaluable learning mechanism. The concept, applies to any operating system, but we will discuss Linux here. With smart selection and configuration of software, a "slower" system can outperform a poorly configured "faster" one, and the difference can often be bewildering.

Disclaimer

This subject is quite open-ended. This article tries to be "miscellaneous" in nature—and is in no way exhaustive. Since the CD-ROM has Linux and many readers will be it on their PCs for the first time, we've tried to be reasonably non-technical. The contents should be best regarded as "suggestions".

Putting some thought into partitioning

Linux (or any other Unix, for that matter) should ideally not be put on a single partition—at least the root partition should be different from the rest of the system. Suppose you have a single hard disk, and you want to put Win 95 (or Win NT) and Linux on it, then a desirable way to partition the disk is not the one in which we simply create one partition for each OS.

Here is a nice scheme, which is just one of the possible ways to arrange things (moreover, note that I don't specify the sizes for any of the partitions—figure that out to suit yourself):

Why go for so much trouble? Well, here are some of the advantages:

• The root partition (/) need not be very large. This way it would be less prone to corruption due to system crashes. A complete backup of a small root partition can be tucked away on some other partition (or on removable media). If your system crashes, you certainly would prefer restoring a small root partition to installing the whole thing from scratch (chances of corruption are greater for a very large partition is mounted read-write at the time of crash).

• We shall mount /usr read-only, so whenever there is a system crash, /usr (which usually occupies the most space) won't be subjected to a file system consistency check—this will save us the long boring wait to see the hard disk grind while fsck does its job. Also, /usr can be mounted from a read-only media (CD-ROM), and in a networked setting, one may wish to export /usr to other machines. Finally, mounting /usr read-only does not hinder installation of new software, because you can always toggle the read-only flag at will on a running system.

• /var is on a different partition. Most of the logs go to /var, so do the spools (mail, printer, etc), and other administrative data. We would really like to separate /var from /usr, hence it is on a separate partition.

• /tmp should be on a fast device, if possible. Even though the ext2 file system is quite resistant to fragmentation, keeping /tmp on a separate partition further reduces fragmentation of the other filesystems like /usr, because most of the time it is in /tmp that data is shortest lived.

• Whatever holds for /tmp holds even more for swap. Swap should be on a fast device, and so on ... (it is better to have a swap partition than a swap file).

All this is quite relevant for serious or commercial Linux users.

Boot-time optimization

Is it not a treat to see a Unix system boot (am I masochistic)? It is also unwise not to take a look at all the boot-time scripts (usually in /etc/rc.d on System V'ish systems, including most flavors of Linux), and altering them so that needless work is not performed.

On a Linux system, a look at the directory /etc/rc.d reveals that there are a LOT of "visible" things which are done at boot-time—many of which are configurable. We aren't going into the details of each file in /etc/rc.d here, but it would be worthwhile for you to go through them, and comment out things which are not really needed by YOU. Unless you have a printer attached, no need to run the printer daemon, unless your machine needs SMTP, don't run sendmail, unless you have a CD-ROM drive and run stuff off it while booting or just afterwards, don't mount a CD-ROM at boot-time... the list continues. A "stripped down" booting will be faster (considerably so in some cases), and the system saves itself some resources in the bargain.

Customize your kernel

It is (in general) a very bad idea to keep using the stock kernel copied to your disk when you installed a Linux distribution. It probably contains lots of stuff you don't need. One of the prime tasks to do after getting your Linux up and running, is to compile a custom kernel. Here are some basic guidelines:

• Get hold of the latest stable kernel which will work with your set of libraries and compiler. If you are one of those who like to live on the "bleeding edge" (yes! a step forward from the proverbial "cutting edge"), there's no choice but to get the VERY LATEST kernel (stable or not). This boils down to downloading new kernel patches quite frequently. At the time of this writing, the newest kernel is version 2.1.47.

• To configure your kernel for compilation, do a 'make menuconfig' or a 'make xconfig' (won't work on "older" kernels), which would generate a GUI for kernel configuration. The GUI makes the task more comprehensible, faster, and easier in general. Try to DISABLE (yes!) as many memory eating options as you can (after you're convinced that you won't be needing them, of course)—we want to free as much memory as possible. For example, if you don't use a device connected to the parallel port, then don't compile parallel port support into the kernel.
  
  In fact, one can use loadable modules for just about everything that is not required very often, like at boot-time—the sound driver, for example. Having a lean kernel is nice when one can dynamically load support for various things as and when required. In fact, automatic loading and unloading of modules is possible using 'kerneld' (by "automatic", I mean that kerneld figures out which module(s) to load, and unloads them after they have not been in use for a certain period).

The bottom line—Make a list of stuff you must have in your kernel, and configure it accordingly. Compile the rest as loadable modules (however, some stuff just can't be compiled as modules, so verify!).

Taxing the text mode

How do you like the idea of mostly working outside of X, unless of course the current task NEEDS X? Don't misunderstand me. It is not merely to project one's image as a "TRUE" hacker (in tune with the folklore) that one would like to condemn GUI—it's a PC after all, with lesser (usually) RAM and other resources than a high-end workstation, and the overhead of "hi-tech" GUI can be awesome. Moreover, there are many people who are not able to run X, due to incompatible hardware, etc. Let's try to look at some of the things specific to the "text" mode.

• Unless you have lots of time at your disposal, compile with X NOT running—compilation would take much longer if X is up. Even if it is an X application that you're compiling, it is better to compile it first, and then start the X server to test it out. (Try compiling the Linux kernel both ways—from within X, and when X is not running. Nothing like first hand experience!)

• If you get bored by looking at the same font all the time, try out different fonts, there are lots of them in /usr/lib/kbd/consolefonts. Either use the 'fontconfig' utility, or just 'setfont fontfile'. It is also possible to create fonts of your own for such use, but the details involved don't fit into the present context.

• To change the background or foreground colors of a text screen, use 'setterm -foreground XXXX -background YYYY -store' replacing XXXX and YYYY by appropriate color names. 'setterm' is a useful utility that offers much more than just colors.

• To change to a higher (or lower) number of rows on a text mode screen, use 'resizecons -lines N' where N is a valid number of ROWS (25, 28, 30, 34, 36, 40, 44, 50, 60). It is also possible to change the number of columns (resizecons COLS ROWS). If you want to try out different "modes" that your card can offer. And if you use LILO, try putting "vga=ask" in /etc/lilo.conf (recall you've to re-run LILO after doing this). This would present a menu of the available modes at boot-time, and you can take your pick then. If you don't use LILO, use whatever method you have for passing "vga=ask" to the kernel.

• The nicest way of harnessing the full text capabilities of your graphics adapter is to get the utility SVGATextMode, which allows one to use even nonstandard ROWS x COLUMNS etc, among other things. Hardware permitting, incredible stuff like 165 rows and 100 columns etc is possible!

• Everybody knows that the way to switch consoles under Linux is ALT-F1, ALT-F2... etc. While running X, the way to get back to a character console is 'Ctrl-Alt-F1', 'Ctrl-Alt-F2', ... Also, X by default runs on tty7, so 'Alt-F7' will return to X from a character tty.

• I find it easier to use 'Alt-m' and 'Alt-n' to go to the previous and the next ttys (yes, just as in NCSA telnet —once you get used to it, you sort of dislike using the Alt-F1 stuff). It is simple to arrange for that to happen (and in general other key bindings).

• Here's how:

1. Get a dump of the current keymap by running 'dumpkeys > keymap.CUSTOM'
2. Look for "keycode 49 = n" in this file. In the next line, add "alt keycode 49 =Incr_Console" (without the quotes, of course).
3. Look for 'keycode 50 = m' (should be the next line), add "alt keycode 50 = Decr_Console".
4. Now the relevant art should look like:

   keycode 49 = n
   alt keycode 49 = Incr_Console
   keycode 50 = m
   alt keycode 50 = Decr_Console

(It is not '49' and '50' that are crucial, but the keys to which we are binding—'m' and 'n' in this case).

Save this file, and do a 'loadkeys filename', where filename is this file's path. Voila, now Alt-m and Alt-n do the desired! You may want to keep this file in /etc, and add a line which loads this keymap (loadkeys /etc/keymap.CUSTOM) in one of the startup files (/etc/rc.d/rc.local would be a nice place).

• Have you ever felt like capturing a screen in the text mode (Well, this may have some security implications too - fodder for novice crackers?) To do so, we need the 'vcs' devices. Make sure that /dev/vcsN (N = 0 to some number) exist—/dev/vcsN and /dev/vcsaN are there for every virtual terminal, and are used to generate screen-dumps of the terminal (vcsN is text only, while vcsaN includes the attributes). So, if you want to capture the contents of tty2, all you've got to do is "cat /dev/tty2 > /tmp/output.tty2", etc.

In fact, one can modify the keymap (as we did for console switching above), so that a certain combination of keys causes a screen dump (not hard at all—figure out!). Oh yes, this was a "technical" way to go about it. If you have the utility 'setterm', and the vcs devices exist, then 'setterm -dump N' will dump the N'th virtual console.

All hacking and no games make's us dull

Surely you've played DOOM or QUAKE on Linux. And well, apart from these, there are lots of smaller games too—running in X, VGA or both. DOOM of course can run inside X, as well as out of it. Being able to run DOOM smoothly in X (with sound and all) is proof of your machine's power. Try something like "xdoom -4" on your Linux PC—does it crawl or crash?

By the way, have you noted that although the sound effects in DOOM are okay, there is no music (usually)! This is because when Linux DOOM was released, there was no music support in Idsoft's 'sndserver'! But one MUST have everything—so get 'musserver' , a "sister program" of 'sndserver' that provides full music support for DOOM. Have fun!

Netscape woes

Netscape Navigator is really popular, and you simply can't afford NOT using it. But it's a memory hog (Communicator even more so)—except when you are fortunate enough to own a power demon. It may not be possible to do other work while running Netscape. Also, sometimes Netscape refuses to run complaining about symbols like "_builtin_vec_new" (or other hieroglyphics). This usually indicates that you have a libc without the symbol(s). The solution is to upgrade your libc (downgrading also helps!). Netscape crashing while loading Java applets on Linux is all too common—so don't worry too much.

The X

The X Window system is an integral part of any Unix workstation worth its name. And Linux can run X as well as the rest. However, the "Limited resources on a PC" syndrome affects X pretty seriously because of heavy demand on system resources. A lack which can seriously affect performance. Refer to the table of recommended hardware in our article GUI Development Under Linux (PCQ, July 1997). Getting new hardware is seldom a feasible option, so let's try to fine-tune X instead.

However, I will not refrain from saying that an un-accelerated graphics adapter is the death knell for X. So please, irrespective of the CPU, get a good graphics card. A Cirrus Logic card is a not-too-pricey option.

Upgrade XFree86

The X distribution which most flavors of Linux use is XFree86. As we mentioned in July 1997, page 30), the XFree86 server is not as fast as the commercial ones, but there's good news! XFree86-3.3 (the recent release) is almost as good as anything else for most purposes—or so I've found it to be.

It would thus improve X performance by switching to XFree86-3.3. The upgrade "suite" (the X binaries, the server, the libraries, the headers and the docs—but NOT the fonts) would be about 10 MB. Visit http://www.xfree86.org/ for more information.

Recompile X Server, if required

If you use the SVGA server (or the VGA16 or the mono server) from the XFree86 distribution, then it would be a good idea to recompile your server. By default it includes support for a number of cards, and since you obviously know what YOUR card is, one way to conserve precious memory is to disable support for all other cards except yours, and recompile using that configuration. Further, remove those X Server extensions that you won't use. All this may make things visibly faster.

Avoid using desktops with too many bells-and-whistles

Sun workstation users are familiar with the OpenWindows desktop, HP-UX users have HP-VUE, and so on (of course, now-a-days, CDE, the Common Desktop Environment, is a "standard" and available on the newer workstations from major vendors, like Sun's UltraSparcs), but what about Linux? CDE won't become common on Linux tomorrow.

The ideal selection is simple: none! Yes, following the same "not-too-many-resources" argument, it makes sense not to put any more burden on the Linux box. After all, if one wishes to carry this desktop thing too far, then one might use Win 95 after all! Avoid using complicated images as backgrounds or icons (this will eat up lots of server resources). Similarly, avoid things like opaque window drag. And yes, don't use a higher color depth unless you MUST—it'll really slow down things.

What does a better CPU buy you?

Intuitively, a "better" CPU should make the system "faster". But how fast is fast? Unfortunately, questions like these bog you down. Needless to say, it is incredibly difficult to devise a performance index that is consolidated, true and totally unbiased (in any sense). How much you'd benefit from a faster CPU depends not only upon the kind of work that you do, but also upon the other hardware. One thing which benefits immensely from a CPU and (or) a RAM upgrade is software compilation. Here's a comparison based on personal experience (each kernel was configured to offer more or less the same functionality, irrespective of version. Of course, these figures should be viewed only in a "comparative" light, they may not

Bottom line—If you run Linux, and compile software often, then it surely makes sense to get more memory and more CPU's, faster ones. If you have a "slower" machine like a 486, then you can comfortably run Linux on it without feeling a thing, UNTIL you have to compile something big. (By the way, I was considering a "home" machine—if it is a network server of any sort, then resource requirements differ drastically).

Gopal Y Upadhyaya

Grabber Softwares