Compiled and narrated by K.Mandla
https://kmandla.wordpress.com
http://ubuntuforums.org/member.php?u=71172
https://launchpad.net/~k.mandla
Last update: Jan. 19, 2009
The narrative of this guide is licensed under the GNU Free Documentation License, v1.2.
Copyright (c) 2009 K.Mandla.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included on the page entitled “GNU Free Documentation License“.
For the text of the license or to learn more about it, visit this link:
Way back in November 2005, I spent almost US$4000 on a brand-new, top-of-the-line gaming laptop. I wasn’t a professional or even a hard-core gamer, I was just tired of slow performance in Windows, and I wanted something with muscle, to take the edge off.
At the same time, I had a leftover 233Mhz laptop that I wanted to connect via wireless to listen to the BBC World Service. That was all. Nothing special. But Windows made it almost impossible — Windows 98, the legal version for that machine, couldn’t deal with my wireless card. And even stripped-down illegal installations of XP were grumpy and uncooperative.
And then I found Linux. And suddenly I had a quick and speedy 233Mhz machine that could work with a wireless card, and could write letters or resumes, and could open PDF documents, and could handle almost every desktop task without a problem.
A month later, I sold that brand new computer, and scaled down to the same 1Ghz machine I have today. It was obsolete in 2001, but it still does everything I need, and never argues … much. ๐
That’s one of the things Linux is great for: resurrecting old hardware and making it usable again. Even as I’m writing this, I’m using a 550Mhz Celeron — a Celeron, mind you — and it’s polling my e-mail accounts, playing streaming radio (jazz, thank you) and is networked to two other machines through a wireless router. I have a complete and working jp106 keyboard with multikey conversion between character sets, any USB gadget I might desire and 3D-acceleration on a beautiful 24-bit display at native 800×600. Best of all, it starts in less than 30 seconds and all of it runs on less than 192Mb of memory.
If corporations had their way, this machine would be in a landfill, somewhere outside Tokyo.
Linux performs miracles, and Ubuntu makes them easy and painless. The only problem with Ubuntu is that it’s generally directed at much newer machines, and as a result is a little sluggish on very old hardware. It’s not impossible to use, but it does suffer just for being a little more generic than other distributions.
Luckily, it is possible to cut a few corners, hotwire a few configuration files, and maybe even install a program or two that makes a leftover 333Mhz closet-dweller into a fight-night contender again. Linux will surprise you that way.
But there’s one thing this guide can’t do, and it’s sad, but I have to tell you this: No matter how you adjust it, no matter what you tweak or reconfigure or uninstall or recompile, Ubuntu is still one of the slowest Linux distributions out there.
Please, trust me on this one. I’ve been trying for years — YEARS — to make Ubuntu run as fast as my personal second-place finisher, Arch Linux, and I admitted defeat a long time ago. Ubuntu is good, Ubuntu is faster than Windows, but it’s still the couch potato of Linux distros.
If you want a truly fast machine, if you want to bring your overclocked K6-2 even closer to the speed of light, you have to use something besides Ubuntu. There are distros available to you that can convert your 200Mhz 98-pound weakling into a 400-pound gorilla with a bad attitude, and they can do it without blinking an eye. Expect some distros to outperform identical Ubuntu installations on machines running at twice the speed. Sounds outrageous? It is. But I’ve seen it happen.
And so that’s the thought I leave you with: Yes, you can trim down and tweak Ubuntu to make it faster … but only to a point. If you want to break that barrier, you have to step away from Ubuntu, and learn something new. I’ll show you a few tricks that can make Ubuntu faster, but in the end, nothing you or I or anyone can do will make it a gold-medal finisher. That’s just the way it is.
I deliberately omit two things from this guide, and unfortunately they are probably the two things that will help most in speeding up a Linux system: custom kernels and module management.
I don’t talk about custom kernels because compiling a kernel is an advanced task, and one that is specific to your machine. I have no way to guess or even suggest the configuration for your hardware, and so that would effectively leave you alone and out in the cold.
I also don’t discuss module management, and for much of the same reason. Your choices of modules will mirror your hardware profile, and Ubuntu is fairly good at picking the modules you need for day-to-day use. Furthermore, when you start managing modules, you start adding a layer of effort to the system, and in this case I think it slows things down.
Unless you need to recompile your kernel to use a specific piece of hardware, or you need to manage modules to prevent some sort of hardware conflict, those things are best left alone in Ubuntu.
On the other hand, if you are keen on doing those things, I recommend you try a distro that gives you better control over the kernel and modules. You can do those things in Ubuntu, but it’s more work than it would be in other distros.
I have several disclaimers for this guide, since there are implications to following any of the advice you read here. Most of these should be common sense, but it is important to say them “out loud.”
- Back up any important files before you do anything here. Some of these suggestions make major modifications to system files, and it’s always possible that a typo or a bad suggestion will render your system useless. Make sure your resume, your family photos and your … other stuff … are copied to somewhere safe.
- These are not my ideas. I didn’t invent any of these things, I only collected them and put them in one place. If you have problems or they don’t do what you expect, you should backtrack to the original source and ask there. Where possible, I’ve included links to the original, earliest threads or sites that make these suggestions.
- I am not an expert. I am a Linux hobbyist, which is kind of like being a backyard mechanic. I don’t have a computer science degree, I don’t work as a sysadmin and I don’t program in six different languages. Sometimes I’m wrong or I just don’t understand; if you catch me in a blunder, please let me know what the problem is.
- This guide is intended for machines slower than 1Ghz. Machines that postdate Pentium IIIs are unlikely to see improvements, because the speed of the hardware outstrips the benefits of the tweak. Try them anyway, but don’t be disappointed.
- This guide is intended for desktop and laptops, in common day-to-day roles. Using some of these suggestions on servers or embedded machines or special-purpose hardware would be suicidal.
- Your mileage may vary. Some of these tweaks might not do much for you. That’s always a possibility. Please don’t hold a grudge against me because your K6-2 doesn’t suddenly peform like a K6-III.
- Suggestions are welcomed. If you have an idea or know of a tweak that I haven’t included, please let me know about it. Provided it doesn’t steal my credit card number or erase my hard drive, I’ll think about including it in the guide.
- Stay gold. This guide will only take you part of the way toward a full-fledged, light-and-speedy graphical desktop. Remember not to burden your machine with bloated software or bulky desktop environments, because you’ll be undoing all the hard work you did earlier.
A small range of programs are available that might lend a slight speed improvement, depending on your hardware and software setup.
hdparm and sdparm
hdparm appears in a default Ubuntu installation of any shape, and if you are among the lucky, it might allow you to tune your hard drive settings and get a small speed boost.
hdparm (and sdparm) are meticulous and precise programs that will require you to test and tweak repeatedly with your hardware, and for that reason I don’t have any suggestions for you. If you’d like to get started with hdparm, try this page, or the Gentoo wiki.
sdparm is the SCSI device counterpart to hdparm, but is not included in Ubuntu by default.
preload
preload is still one of the simplest ways to get a little more spark out of your machine. The daemon runs in the background, and tries to predict what you want next. Then it grabs it up so the system seems altogether faster.
There’s no need for setup; just install it from the repositories and it’s running.
Be forewarned: This is, technically, another small process that your machine must serve, so on very old machines, it might actually cause a slowdown.
readahead
readahead works a lot like preload, predicting what you’ll want next and making it available before you ask for it. I think highly enough of both readahead and preload that I regularly install them both, regardless of the system I’m running.
readahead is another fire-and-forget program, but you can also macromanage it, if you so desire. Ubuntu Forums administrator jdong explains how to fine-tune the application in this thread.
That procedure, while complicated, can work wonders for a system running Gnome and GDM, but does nothing for a lightweight, sparse system. Interpret that as you will, but also remember that firsthand experience is the only indicator of how well it will suit your system.
The way you set up your system is terribly important, if you want to squeeze any speed out of the end product. A cluttered partition setup or high-maintenance filesystem is going to drag your system down beyond what any tweak can salvage.
Most of these ideas are not tweaks, they’re just reminders that the decisions you make when installing your system will have repercussions later. If you do decide on one of the two filesystems I describe, you’ll have the choice of a few settings that might improve performance.
Test each one and decide what you like. Take your time and discover the best combination.
A default installation of Ubuntu carves out the entire drive space you give it, and slices away a small chunk for swap. The main partition includes the necessary boot files, the system software and your personal files, all on one partition.
If you manage your own partitions, you can expect a small improvement in system performance.
The underlying principle for this arrangement is that a small partition mounts faster than a large one. And a small partition has quicker access to information, because files are arranged in a confined space.
If you’re using a machine with a very small hard drive — let’s say, 5Gb — let Ubuntu build its default array and use that. But if you’re working with a machine with more than 5Gb, it’s not a bad idea to leave part of the drive unused, or just unmounted, and things will start up quicker.
As an example, on a 60Gb hard drive, you can build this.
32Mb boot
256Mb swap
2Gb root
2Gb home
That leaves almost 55Gb unmounted at the start, and while it might seem like a waste, a 1Ghz machine with this partition arrangement loses a full second on startup. Imagine what an even older machine might recoup.
Here’s another idea.
2Gb root
256Mb swap
(remainder mounted manually)
That system boots fast and still has access to the extra space, whenever it’s prompted to use it. The only downside of course, is that you have to tell the system you want to use it. In most cases that’s not a big deal, and if you think about it, network arrangements don’t always mount automatically. Just think of it like a network drive.
One more complication: Data access is technically faster near the drive hub, which is the beginning of the partition array. So put your root partition, and your swap partition if you plan to make use of one, at the front of the array. You should milk a little more speed out of your system that way.
Threads discussing partition schemes are a dime a dozen; here’s just one, two, three, four and five to start with. Feel free to bring up the topic again.
One final note, for people using very old computers: The tendency, when you receive an old machine as a gift or as a charity case, is to immediately swap out the standing hard drive for something bigger and faster. It makes sense: Newer drives are vast improvements over the old ones, and are often much quieter too.
You might run into a problem though, where your new hard drive is suddenly unbootable because the BIOS is ill-prepared to deal with a drive of that size. Early BIOSes were written with size limits — no doubt in part to encourage you to buy a whole new computer, since the old one is running out of space.
Linux will ignore any limit it senses on hard drive size, but you still can’t get the machine to boot without acknowledging the BIOS size cap. If Grub’s configuration files are located in a place beyond what the BIOS can comfortably handle, it will spit out an error, and your system is borked.
The fix is fairly straightforward: Just partition the drive with a tiny sliver — even something as small as 64Mb — as the first partition, and install Grub there. The rest of the drive you’re free to do with as you will. Just make sure Grub can find those files within the limit imposed by the BIOS, and the rest of your antique computing experience will be like butter. ๐
If your machine runs short on memory while it’s working, it looks for a special partition for offloading excess data. That’s called the swap space, and it’s something that can have a strong influence on system performance.
Regardless of your hardware, using swap slows down your system because any time a change is made, it requires disk access. And on an old system, the time it takes to travel to the disk and back can be considerable.
On the other hand, swap space on a machine with little physical memory is what makes the machine usable. If you can keep a clean balance between swap usage and system demands, an old machine with just a little memory is actually quite happy.
As a rule of thumb, I usually set up an amount of swap space equal to the amount of physical memory I have installed in the machine. Adjust that number against the workload you intend, the software you plan to install and the amount of visual flair you expect.
Of course, if you’re running a system with more than, say, 512Mb you can probably eliminate swap altogether, since you’ll probably never use it.
As a side note, it is possible to build an Ubuntu system without swap. But the system will complain. …
If you’re working with a machine with little memory, or just not enough to do the job, give yourself lots of swap. Your system will need it. Yes, it will behave terribly, but you’ll stay in business.
After you install your system you can adjust the swappiness, and control how aggressively Linux uses the swap.
One last note: If you have a system with two hard drives and you expect to use swap space, you should put it on a different drive from your system files. Computers can access two drives at once, and that will always be faster than waiting for one drive to access both the swap and the system partition. It’s worth taking the time to add the extra drive.
If you have more questions about swap, the Ubuntu wiki actually has some interesting advice, including how to set up a swap file.
Filesystems are the arrangement and management of files on your disk. In most Linux systems you have the choice of about six different filesystems, and each filesystem has an array of settings that may (or may not) improve performance on an old system.
The only way to find out what is best is to experiment with your machine. If you feel XFS is the best thing for your system, use it. If you like ext3 with the data_writeback flag, use it. If you like reiserfs on a 100Mhz Pentium … erhm, well, use it.
For my money, ext2 is the best idea for an older system. It doesn’t journal, which is a relief for both the CPU and the I/O channels, since it doesn’t require extra work to maintain a record of filesystem activity. You might disagree, and that’s okay.
Before you follow any advice about filesystems, you should acquaint yourself with your options. Take a look at this site, this article from Debian Administrator, and this comparison on Wikipedia.
As I mentioned, ext2 is the fastest I’ve encountered on sub-1Ghz hardware. It mounts faster and the machine isn’t tied up journalling, so it’s free to handle other issues.
In my experience, the newer, high-end filesystems are best on newer, high-end machines.
Using the standard Ubuntu installer, it’s possible to set the filesystem to ext2 through the menu. I regularly use ext2 for root, home and boot partitions, although I have been known to bounce around in certain situations.
ext2 doesn’t come with an armload of tweaks, probably because it’s been around for a while and isn’t very fancy. To be honest, the best summary of ext2 and its capabilities is on Wikipedia.
ext3 is just ext2 with journalling enabled. The two filesystems are synonymous, compatible and more or less identical.
Ubuntu uses ext3 as the default, and applies a few basic tweaks without your permission — most notable the dir_index and relatime flags.
Since journalling can, sometimes, save you in the case of an accidental power-off, you might prefer this, even with the performance hit. Anecdotes about filesystem reliability are completely pointless, so I won’t bother endorsing one over the other on the grounds of data security.
I don’t use ext3; the difference in performance is tangible to me, and the time it takes to set up ext3 to run like ext2 negates the improvement. And I don’t really care about journalling, so I see no need to go through the hassle.
Because ext3 is the default in Ubuntu and in a lot of other distros, there is a large amount of information available on it. For starters, take a look at this page, from the IBM Web site; this Ubuntu Forums thread; this Gentoo wiki article; and this blog.
In spite of some criticism, I still feel the data=writeback flag is one of the best things going for ext3. It takes a little acrobatics to set up, but when it’s done, it’s going to make your ext3 system run as fast, if not faster, than an ext2 system.
First, let’s edit your default Grub options, so the system knows the flag is coming when it boots. Edit the /boot/grub/menu.lst file with this command.
sudo nano -w /boot/grub/menu.lst
On both the defoptions line and the altoptions line, add this:
rootflags=data=writeback
You shouldn’t need to edit those lines in any other way. When you’re done, they should look something like this.
# defoptions=quiet splash rootflags=data=writeback
# altoptions=(recovery mode) single rootflags=data=writeback
Now we need to update Grub.
sudo update-grub
This step can take a little while. Be patient.
Next, edit /etc/fstab so the running system can see the flag in place.
sudo nano -w /etc/fstab
Find the appropriate partition and add this snippet to the options column.
data=writeback
When done properly, your line will look something like this.
/dev/sda1 / ext3 relatime,errors=remount-ro,data=writeback 0 1
Save and exit. Up until now, it’s only been signals to different parts of the system, that the flag was going to be set. Now we actually set the flags with this line.
sudo tune2fs -o journal_data_writeback /dev/sda1
Be sure you apply the flag to the right partition and drive. ๐ฏ
When it’s done, double-check that the flag is in place, before you reboot.
sudo tune2fs -l /dev/sda1
You should see “journal_data_writeback” or something like it in the list somewhere. If you find it and you’re ready, reboot your system. The startup should be quicker, programs should load a little faster and the entire system should feel a tiny bit more “peppy.”
Like relatime and noatime, nobh is a flag for ext3 that might improve disk performance, and maybe even overall speed. As with every tweak, the results will depend on the hardware and the system.
Add the flag to your /etc/fstab file entry for the appropriate drive, like this.
/dev/sda1 / ext3 relatime,errors=remount-ro,nobh 0 1
If you add other flags too, just separate them with a comma (no extra spaces). On remount or reboot, the option will take effect.
Since Ubuntu 8.04, the default filesystem for Ubuntu carries the relatime flag in ext3. As I understand it, this setting prevents accessing the hard drive to update atime information, unless there’s been a specific change.
This is an improvement in kernel development and not specifically in Ubuntu, which means if you want more information on the hows and whys of relatime, you should start with this discussion on kerneltrap.
relatime should be an improvement over settings in Ubuntu 7.10 and earlier; all the same I personally use the noatime setting, which ignores atime completely. I have no use for the atime feature (that I’m aware of), and I suspect outside of a server, few other people would either.
noatime is available to both ext2 and ext3 filesystems, and can be set either in the installation process, or by adjusting the /etc/fstab file. Simply add the “noatime” flag to the drive options, separating it from others with a comma but no space. For example. …
/dev/sda1 / ext3 relatime,errors=remount-ro,noatime 0 1
noatime implies nodiratime, so if you have set one, you get them both. The opposite of that is not true — if you set nodiratime, noatime is not implied.
noatime yields some very impressive boot time improvements for ext2 filesystems; a 1Ghz machine with a 7200rpm drive lost a full second from its start time with the noatime flag applied.
ext2 and ext3 filesystem users can reoptimize their directory trees, and on some systems it can yield a considerable improvement in start times. Unfortunately, it’s one of the more high-maintenance tweaks, since it requires you to boot into a live environment, and then reboot into your installed system.
Boot any live CD (the distro doesn’t matter), and find your way to a terminal. Enter this command, changing the drive name assignment to the drive and partition you want.
sudo e2fsck -fD /dev/sda1
Remember that drive assignments can change between Linux environments, and so you should check to make sure you’re using the right one.
The process can take some time, depending on how complex the directory tree is, and how fast your system is.
When complete, reboot into your normal system, and you should get a minor spike in start and load times. Reapply this tweak if you install a lot of software, or rearrange a lot of directories on your system — or just after a month or two of normal use.
For a very short explanation of the tweak, read this post. More information is available in the man pages for e2fsck, or in parts of this discussion on the Gentoo forums.
Some things that will speed up your system aren’t really tweaks, just ideas to remember or software triggers you can apply. Some of these are common sense, while others are learned by experience or depend upon your hardware. Use whatever you feel is best.
Most people wise enough to run without a desktop environment still rely on an external program — such as feh, or perhaps PCManFM — to set the desktop wallpaper.
On a machine with minimal resources you might consider the omnipresent xsetroot command, which appears along with any default installation of the xorg package — the guts of nearly any graphical environment in Ubuntu. xsetroot can paint the “wallpaper” to a flat color, like this.
xsetroot -solid blue
Any HTML color name will work there, or you can manually pick a shade with six-digit codes, prefixed by a hash mark and enclosed in quotes.
xsetroot -solid "#3465a4"
If you include this command in your .xinitrc file, you’ll have a decent — if somewhat plain — background on every start. And you won’t need an external package, or the resources to run it.
Any time an entire fresh system is called for, I heartily recommend blanking the drive completely. It is time-consuming, but a clean drive is the best thing for a new installation.
I have, in the past, overwritten old systems and reused partitions, but the results were unreliable. Occasionally a few of them wouldn’t even boot. And on a very old system that requires hours to install, you don’t want to take the time to do it over because of something preventable.
The best application for blanking a hard drive is Darik’s Boot and Nuke. It’s Linux-based, it’s flexible and customizable, and it’s free.
Killdisk is another option, if you find a machine that is somehow incapable of using DBAN.
Linux can only do so much for a machine, if the core hardware settings are working against it. Aside from anything you do to keep your old system perky, you should be aware of any BIOS settings that might be hampering it.
Some older systems have hardware options — most notably, laptop power management settings — that might throttle the processor, or affect filesystem performance. Also be aware of system checks or memory scans that are run at startup. If you can disable those, your gross boot time will be much more satisfying.
Every machine and every BIOS is different, which means you’ll have to check your own system and see what’s available, and what helps. Aside from that, I don’t have much advice to offer.
In Ubuntu 8.04 and earlier, the default color depth for a graphical system was always set to 24 bits per pixel.
Ordinarily — which is to say, ordinarily on machines that postdate 1999 or so — that’s fine. Graphics cards have more than enough memory nowadays to handle 24 bits at almost any resolution.
But on older machines, you may find that a 24-bit color depth is sluggish — or even impossible, resulting in dead black screens, no video output, or just a fallback console.
In a situation like that, adjust the color depth to 16 bits per pixel, by adding this line to an /etc/X11/xorg.conf file, in the Screen section.
DefaultDepth 16
That should give you a graphical desktop on a machine with little video memory, or an underpowered graphical subsystem. It’s also worth noting that a 16-bit desktop is usually indistinguishable from a 24-bit one, so you could use the same trick to perk up a system that technically can handle 24-bit, but seems a little groggy.
And reduced video demand can mean better performance elsewhere in your system too. ๐
Think about this tip before you try it. There are a couple of factors at work here, and if you are willing to skimp a little and think creatively, you’ll come up with an impressive and fantastic system that you will completely adore. Probably.
On some very old machines, a graphical desktop is nigh-impossible — especially if the video system can’t handle the basic requirements, or if it pushes the workload back to the processor.
You do have the option to ratchet down your system and just suffer, but consider this: What if you run the machine completely X-less? What if your entire system, running at 66Mhz or what have you, is based on console or framebuffer applications?
Contrary to popular belief, there is a mind-boggling array of console applications that do the same job as their GUI counterparts, and do the job just as well — they just don’t require all the resources of a graphical environment to do it.
It’s not a popular option, but it is an option. With a willingness to learn and a willingness to try new things, a very old machine becomes very useful.
Here’s the problem though: The default “console” resolution on an Ubuntu system is probably a bit oversized. If your monitor is only 640×480 that might be okay. But on a larger display, or a display with a higher native resolution, you should take a moment to make sure you’re getting all the space you’re due.
This is done at the kernel boot line, and is just one small option.
vga=XXX
Change XXX to the array you want, as described in this chart.
# FRAMEBUFFER RESOLUTION SETTINGS # +-------------------------------------------------+ # | 640x480 800x600 1024x768 1280x1024 # ----+-------------------------------------------- # 256 | 0x301=769 0x303=771 0x305=773 0x307=775 # 32K | 0x310=784 0x313=787 0x316=790 0x319=793 # 64K | 0x311=785 0x314=788 0x317=791 0x31A=794 # 16M | 0x312=786 0x315=789 0x318=792 0x31B=795 # +-------------------------------------------------+
If you pick an option that works, you’ll be rewarded with a framebuffer console at a finer resolution — which means more characters per line, which means a “larger” console screen. If for some reason you pick one that doesn’t work, you’ll be given an error message, and a chance to try it again.
When you’ve got one you like, and one that works, you can add it to your kernel boot line permanently, by adjusting the /boot/grub/menu.lst file.
sudo nano -w /boot/grub/menu.lst
Add your vga code to the defoptions line (I don’t recommend adding it to altoptions). Save the file and update grub so it knows to use that option every time.
sudo update-grub
Remember if something goes wrong, you can always change that option when you boot the machine. So if you accidentally pick a nonworking number you can at least get into a working state and fix it.
But of course, there’s always a catch. Switching resolutions causes a brief pause in the boot sequence, sometimes as long as a second or two. This happens before the system begins to boot, when the initial startup instructions are loaded.
So here’s the dilemma: If you use the terminal regularly, on a very old machine, you probably don’t care if it takes an extra second to start up, since it’s a long start process anyway. Set the framebuffer you want.
If you’re on a mid-speed machine, like 600Mhz or so, that two-second-delay is going to be like a grain of sand in your mouth — always irritating you, and you can’t get it out of the back of your mind. In that situation, and since you probably don’t need console terminal screens as much, you should probably skip this step. The delay on an otherwise speedy machine isn’t worth it.
And of course, on a high-end machine, that switch is going to be just a blip — so you won’t mind if it takes another fraction of a second to start. You might as well enjoy the occasional resolution improvement, and meditate during that delay.
Ultimately, your obsession with startup speed is what determines your course, coupled with the speed of your hardware. Personally I’ll only take the time to adjust a framebuffer resolution on a machine that needs console access a lot. Otherwise, I can survive with a terminal emulator inside X.
X-less systems are becoming more popular as people realize how functional they are. LaRoza, another Ubuntu Forums moderator, is rather famous for an iBook that runs (ran?) X-less. And ลukasz Maciak, author of Terminally Incoherent, has described his experiences without a graphical environment. And there are occasionally others.
If you want help getting started on a ungraphical system, try these bash tips and tricks, and this introduction to life at the command line.
Starting a graphical desktop immediately at login is a great way to speed things up, in a general sense. You don’t have to wait for the time it takes you to tell the system to do it.
In Ubuntu, the all-powerful bash profile in your home directory is what you need to do this automatically. Edit it with this command.
nano -w .profile
Add these three lines at the end.
if [ -z "$DISPLAY" ] && [ $(tty) == /dev/tty1 ]; then
startx
fi
Save and exit, then logout. When you log back in, the desktop should be triggered automatically. In this way, you can make the console tty login into a kind of session manager, controlling the login and triggering the desktop in one motion.
This also works for other programs you want to start at login, or at different terminal screens. Simply change the tty value or the startx command to whatever you like.
A good counterpart to this tip is the autologin tweak; combining them both means a system that logs in automatically, then starts the desktop automatically … smooth.
The original tip is discussed here, but the idea is anything but new.
Your repository list, and the array of software it describes, is essentially a large database, and managing that database of software titles and dependencies can be very intimidating.
So on a system that’s slow by nature, it makes sense to reduce that workload as much as possible. The best and most obvious way to do that is to comment out the source repositories, which are not necessary for most day-to-day use.
To do that, edit your /etc/apt/sources.list file, and add hash marks in front of anything that doesn’t require your immediate attention. You can also omit non-free software lists in this way.
And don’t be shy about micromanaging your software repositories. If you only need one repository for one package, enable it, install the package and disable the repository again. No shame in that.
One last suggestion: Watch for software that’s downloadable and installable from outside sources. It may be in your interest to download one small package and install it, rather than wait for a repo to be added, wait for the system to manage it, wait for the download, wait for dependencies to be tracked, wait for. … You get the idea.
Ubuntu looks at your hardware profile at every startup and tries to adjust itself accordingly. That’s courteous, but it also means that anything attached is going to need scanning and configuring, and on an old system, that’s going to slow the overall startup.
Take a second and unplug any USB devices like flash drives or optical mice, and you’ll trim your boot time a little bit. On a slow machine, the time it takes to scan a USB port, recognize a 2Gb drive, insert the usb-storage module, add the drive to the array … anyway, it can be considerable.
And remember that older machines are more likely to have USB1.1 ports than the more recent USB2.0 ports. An old machine is going to be slow on the draw if it’s going to start up each time and mount something via 1.1. …
If you have a machine with an old Nvidia or ATI video card, I recommend using the proprietary drivers over the “free” xorg drivers, provided your conscience will abide it.
You’ll get better hardware support — particularly with Nvidia cards, although ATI performance has skyrocketed in the past year or so, since the release of the driver code — and better a desktop experience with the company drivers.
It is worth mentioning though, that sometimes the proprietary drivers actually slow things down. As an example, the 96xx-series driver that runs my 8-year-old Geforce4 440 Go causes a one- to one-and-a-half second lag when it goes from the console start sequence to the graphical desktop.
By contrast, the free driver that is installed by default does not trigger a lag. So if I don’t need the advanced graphics that come with the proprietary driver, I can enjoy a faster startup with the free drivers. Depending on my mood and my demands, I use one or the other.
Tweaks are system setting changes or adjustments to system files that generally make your computer perform faster than the default. There’s never any guarantee that these tweaks will actually improve things, but they’re always worth trying.
Autologins aren’t really speed tweaks, since they don’t actually speed anything up. But they will make your system feel faster, since you’re not taking the time to authenticate before starting the graphical environment.
Autologins in Ubuntu require you to compile a small, three-line program and install it in a system directory. First,
sudo aptitude install build-essential
That will install the tools you need to compile a program. Next, open a text file called “autologin.c”, and paste this text into it.
int main() {
execlp( "login", "login", "-f", "insert_login_name", 0);
}
Be sure to change the login name, or it won’t work. ๐ Now compile it, and send it to the /usr/local/sbin/ directory.
sudo gcc -o /usr/local/sbin/autologin autologin.c
Now we need to tell Ubuntu to run that program, whenever it reaches the tty1 login screen. Technically that’s part of the Ubuntu system startup sequence, so we’ll be editing /etc/event.d/tty1 to make it happen.
sudo nano -w /etc/event.d/tty1
Find this line
exec /sbin/getty 38400 tty1
and change it to
exec /sbin/getty -n -l /usr/local/sbin/autologin 38400 tty1
Save, exit, reboot. On startup you should skip straight through to the login prompt, and end at the terminal line. If you see error messages or the terminal does nothing, switch to another terminal with CTRL+ALT+F2, and double-check your typing.
A good counterpart for this tweak is the start desktop at login tip.
For more information, check out the original thread on the Ubuntu Forums, or this article from Linux Gazette.
Concurrency settings seem to help low-end machines and high-end machines, but not so much in the middle. The tradeoff on boot speed is a rather dirty start sequence, particularly if you remove the “quiet” flag from your kernel boot line.
The concurrency variable is set inside /etc/init.d/rc. Edit that with
sudo nano -w /etc/init.d/rc
A few lines down you should find the CONCURRENCY line; change it to “shell,” like this.
CONCURRENCY=shell
Reboot and you should see a quicker, if sloppier, boot. The original discussion for Ubuntu systems was here; Debian Administration does a better job explaining it here.
IPv6 is the new Internet address protocol; it’s not as widespread as some people would like, so disabling the probe for IPv6 addresses can sometimes solve a weak “hiccup.” Some people can sense that pause, and others don’t mind it at all.
Disable it by opening a file called bad_list inside your /etc/modprobe.d folder.
sudo nano -w /etc/modprobe.d/bad_list
Now add this line to it.
alias net-pf-10 off
Save, exit, reboot. If you could discern the pause when Web pages load, it should be gone now. With newer versions of Ubuntu you may be able to use this, as a simpler method. Edit the /etc/modprobe.d/blacklist file, and add this at the bottom.
blacklist ipv6
Save the file and reboot, and again, you should be able to discern a difference. It’s worth noting that there are lots of different ways of doing this; start with this thread for other possible solutions.
Ubuntu knows what to start up and what to shut down by following the contents of a series of folders — /etc/rc0.d, /etc/rc1.d, and so forth. As you might have guessed, removing or just disabling some of those triggers can greatly improve your system start time, particularly on machines that lack the corresponding software or hardware to run them.
That’s the idea, anyway. Keep in mind that this is one of those unusually dangerous tweaks that can really mangle a system if you’re not careful.
Take a look at the contents of rc0.d, and so forth, and rcS.d too. Personally I delete anything that mimics software I have uninstalled, or hardware I don’t use. Renaming a file is probably safer; that way if you find you’ve made a mistake, it’s fixable. Experiment with the hardware you have, and see what you can omit.
Boot times will drop drastically if you do this right. And processing performance gets a little boost too, since you’re omitting additional work for the processor.
Managing those scripts and services is a common trick for improving start times in Linux; if you want to learn more, take a look at this blog, this collection of bootcharts or this rather lengthy but well-detailed explanation. This forum thread discusses the original idea, and mentions some services that are safe to remove.
This always strikes me as a rather droll suggestion, but I can’t argue with the fact that it works. By default, Ubuntu spawns six tty screens, each one accessible by pressing CTRL+ALT plus the corresponding function key.
If you reduce the number of tty screens, you can slice off your boot time, and lighten your system profile too. It’s an easy thing to do; this command
sudo rm /etc/event.d/tty[3-6]
leaves you with only two terminal windows — tty1 and tty2. Adjust the range to leave more or less. Each tty costs about 500Kb, and skims a tiny fraction off the processor time it takes to blink the cursor on four unused, unseed screens.
It should go without saying that a console-based machine probably uses those screens, and so this isn’t such a great idea.
Tweaking or disabling unwanted software is a good idea, but it’s better to remove it altogether. You’ll be solving two problems at once with this: First, things are moved out of the way, so technically disk access should be cleaner (and smaller, if that’s an issue). But more importantly, those programs aren’t available, triggered or managed at all, which means on an old machine you have a lot less junk to worry about.
There’s no rule on what should go or what should stay. You can keep small-scale utilities or packages that are essential to your hardware (like modem interface software), but depending on the system and its role, there’s a lot that can be culled out. I take out everything as a matter of habit, leaving only things like sudo, the kernel and maybe a power package or two.
You can pull out core packages from things like ubuntu-standard and ubuntu-minimal, because if your system needs it in the future, it will install it as a dependency. You’re (probably) not going to harm anything by removing packages you don’t want or need, because if the system does want or need them, it’ll get it for itself.
The effect on boot times is magical, and you can expect your system to be a little snappier too.
Reprofiling the boot sequence is something that doesn’t necessarily work in every Linux distro. It’s an old trick for Ubuntu, and you should see an improvement in boot times at the cost of a couple of restarts.
Start your system and when you see the Grub boot menu message, press ESC for the full menu. Then pick the boot line you usually use (which is probably the topmost one), and then press “e” to edit that line.
At the end, add a space and then the word “profile”. When you’re done, press enter and then press “b” to boot.
This boot will probably take longer than most to finish. The system is arranging the files and assessing the work that it needs to do, to start up a little faster. Be patient.
When it’s done and your startup is complete, restart again, but don’t change the boot line at all. This time you should see a small improvement in the time it takes to get everything running.
It’s a good idea to reapply this tweak after a little time, or after you’ve made drastic changes to your system.
This tweak goes back a long way in the Ubuntu-Debian shared history; the discussion in the Ubuntu Forums is here.
The sysctl.conf file is a gold mine for speed settings on your system — there are literally dozens that can help in there.
But all those settings interact at low levels, and so sometimes it’s a bit cumbersome to change and test them all. You can spend days adjusting and troubleshooting, then find something that works better, or counteracts it all. Of course, the reward when you get things right is immense.
The best part about sysctl.conf tweaks is that you can (usually) apply them without a restart. No need for a live CD or a reboot, and they are reapplied at every startup.
As a small caveat, most of the ideas here work only under specific circumstances, like a slow system with tight memory working too hard. If nothing happens when you apply these tweaks … well, I warned you that might be the case.
You can adjust your network settings for broadband access with this list. Open /etc/sysctl.conf and paste these lines at the end.
net.core.rmem_default = 524288 net.core.rmem_max = 524288 net.core.wmem_default = 524288 net.core.wmem_max = 524288 net.ipv4.tcp_wmem = 4096 87380 524288 net.ipv4.tcp_rmem = 4096 87380 524288 net.ipv4.tcp_mem = 524288 524288 524288 net.ipv4.tcp_rfc1337 = 1 net.ipv4.ip_no_pmtu_disc = 0 net.ipv4.tcp_sack = 1 net.ipv4.tcp_fack = 1 net.ipv4.tcp_window_scaling = 1 net.ipv4.tcp_timestamps = 1 net.ipv4.tcp_ecn = 0 net.ipv4.route.flush = 1
Those settings are tilted toward a standard DSL-type connection with speeds around 512Kbps. If you have an even faster connection, you’ll want to adjust those further.
net.core.rmem_max=16777216 net.core.wmem_max=16777216 net.ipv4.tcp_rmem=4096 87380 16777216 net.ipv4.tcp_wmem=4096 65536 16777216 net.ipv4.tcp_no_metrics_save=1
Apply them with this command:
sudo sysctl -p
In the end, you’ll have to experiment to get the best results. The original thread on the Ubuntu Forums that suggests these settings is here, but the Gentoo wiki is a better source for learning how to set them properly.
The kernel will automatically adjust the number of processes it’s allowed to run, depending on your system resources. If you prefer, you can set those limits yourself.
Technically this won’t affect your system’s speed. It will, however, prevent the system from taking on too many processes at one time, and slowing itself down in the process.
Check your current settings with this command.
sysctl kernel | grep threads
Look for kernel.threads-max. You can adjust that by adding this line to sysctl.conf.
kernel.threads-max = 512
The top setting is 65536, and is probably only useful for high-end, modern machines. The low end is … however low you decide to set it, but I strongly recommend you don’t go lower than around 128 or 92, because if your system can’t open enough threads to at least start your machine … well, you’re left with a dead installation. Dead, but fixable, that is.
For an unusually long-winded but very informative explanation, try these pages. They’re old and date back a couple of years, but the principles are the same.
Swappiness describes how and when your system will use the swap partition. This is an important setting on old machines, since they typically rely on swap space to compensate for low physical memory. And relying on swap space means disk access, which means I/O lag, which means sluggish system performance, and so forth. …
The default swappiness value in Ubuntu is 60. If you decide to adjust that number, consider these points.
- On a fast machine with plenty of memory, set swappiness to zero. You won’t ever need swap space, so tell the system to stay away from it.
- On a slower machine with plenty of memory, cut swappiness to zero. If it has enough space to do its job without relying on swap, you’ve reached the apex of its practical speediness.
- On a fast machine with low memory, bump up the swappiness, probably beyond the default of 60. The logic this time is that a fast machine with relatively newer hardware can suffer a slight dip in performance by relying on the swap space. So if you have a Pentium 4 with only 256Mb of memory in it, swap will slow you down a teeny bit, but not hamstring you.
- And finally, on a slow machine with little memory, turn swappiness all the way up to 100. Your machine is slow anyway, and it’s going to use swap anyway, so you should just suffer the speed drain. In fact, turning the swappiness too low would put physical memory at a premium, and cause even more problems.
All of these suggestions imply that the amount of memory you have is sufficient for the task you want to accomplish. Let me say that another way, so we’re clear: If you have enough memory to do the things you want to do with the computer, then your memory isn’t low. It’s fine.
You can run a perfectly usable system on as little as 64Mb, so long as you use lightweight software and efficient applications. And if that system never peaks at more than 48Mb or so, then by all means turn the swappiness down to nothing. You have enough memory to do the job.
On the other hand, if you run Gnome on 32Mb of PC66, you’ll need an enormous swap partition and sky-high swappiness. And hours of your life to wait and wait and wait.
Swappiness is set by adding this line to /etc/sysctl.conf.
vm.swappiness=0
One hundred is the highest number you can use. Save, close and apply with
sudo sysctl -p
There’s a decent discussion of the principle here, or you can look at the Ubuntu wiki for ideas and settings specific to Ubuntu. For a generalized debate on swapping and paging, try Wikipedia. Finally, this article in the Gentoo wiki is a fantastic introduction to how Linux manages memory.
vm.vfs_cache_pressure is similar to vm.swappiness, but a little more obscure. The cache pressure controls how aggressively the kernel swaps out its cache, but only for filesystems. Meaning if memory becomes tight, this setting could influence responsiveness when managing disk files.
This is the key for filesystem cache pressure.
vm.vfs_cache_pressure = 50
The range is 1 to 100, with a lower setting telling the kernel to free block cache over filesystem cache. If memory runs short, this could help a “lunging” sensation as the system tries to update file information.
There’s a far superior explanation of the tweak on this page, and you should probably read it before changing anything.
Motho ke motho ka botho 
Pingback: Stupid mistake, drastic solution « Motho ke motho ka botho
Pingback: The height of arrogance « Motho ke motho ka botho
Pingback: GFDL 1.3 adopted « Motho ke motho ka botho
Pingback: A near-death experience « Motho ke motho ka botho
Pingback: Its beauty is in its potential « Motho ke motho ka botho
Pingback: Ubuntu 10.04 filesystems and boot times « Motho ke motho ka botho
Pingback: fbterm: Birth of the cool for the console « Motho ke motho ka botho
Pingback: HowTo: Live Life in a Text-Based World
Pingback: hdparm: Out of respect for times past | Inconsolation
Pingback: rcconf: Enjoying the nostalgia | Inconsolation
Pingback: sysv-rc-conf: Going, going, gone | Inconsolation