Frustrated with my un-snappy Gentoo

[cstump]

Hello,

I've been using Gentoo for about 5 months now on my Dell Inspiron 8200. I must say I am impressed with portage and I like the thought of having compiled every package myself. I also like the control I have over the system and the elegant solutions Gentoo provides for managing the system. However, Gentoo is too slow.

My install was from stage 1 and I basically did everything "by the book." Compiler optimizations were set at 2 and I took careful time setting up my USE flags and hdparm settings. However, the fact is that Gentoo is just not "snappy" on my machine. Windows XP runs smoother and Red Hat 9, which I was running before my Gentoo install, was also snappier. When I use Debian on my desktop at work I just feel cheated with my Gentoo installation.

I understand that comparisons between desktops and laptops only go so far. That desktop hard drives typically have much better caching and disk read speeds which makes a difference in "snappiness." However, I don't understand why an old version of Red Hat and WinXP seem to run "quicker." I thought compiling everything from source would optimize my packages and thus make them run faster!

Symptoms include:

When I press my desktop icon to open a terminal, it takes like 2+ seconds for the terminal to open up.
All other applications lag similarly, but more so since they are often "bigger" than a terminal (i.e. firefox, thunderbird).
Whenever I open an app, the first second or so it is displayed it is filled with the graphic of my chosen theme. After a second or so it
launches into the full application.

Please, can someone help me figure out how to get rid of this lag? I want to keep using Gentoo, but its getting on my nerves and I'm about ready to rip Gentoo off and install Debian. Someone please help me stay a Gentoo user!!

P.S. My system is rarely out-of-date and I keep it that way with "emerge -uD world." Also, I am running GNOME.

[psychomunky]

There could be multiple causes and multiple solutions. Here is what I suggest off the top of my head.

1. Run top to see if there is something gobbling the CPU.
2. Make sure that you don't have some CPU frequency scaling thing installed that isn't working properly (and keeping your CPU scaled down too far). I haven't played with this, but check your kernel configuration.
3. If you have 128MB RAM and under make sure you have some swap space enabled...Red Hat would done this automagically...
4. Try prelinking...instructions here: http://www.gentoo.org/doc/en/prelink-howto.xml

[cstump]

Thanks for the reply!

[Flammie]

[cstump]

[psychomunky]

Just to state the obvious, are you sure you are using the "optimal" driver and setting for your video card?? Even in wondows, I've seen the wrong driver or setting for video slow things down faster than a rabbit on speed.

[cstump]

[BlackEdder]

You also double checked that dma is indeed turned on?

[cstump]

[georwell]

What does hdparm -Tt /dev/hda ( or insert your primary hd here) give you?

[cstump]

Here are a few consecutive runs of 'hdparm -tT':

[root@kirby stump]$ hdparm -tT /dev/hda4

/dev/hda4:
Timing cached reads: 1360 MB in 2.00 seconds = 679.42 MB/sec
Timing buffered disk reads: 44 MB in 3.02 seconds = 14.55 MB/sec
[root@kirby stump]$ hdparm -tT /dev/hda4

/dev/hda4:
Timing cached reads: 1320 MB in 2.00 seconds = 659.44 MB/sec
Timing buffered disk reads: 50 MB in 3.13 seconds = 16.00 MB/sec
[root@kirby stump]$ hdparm -tT /dev/hda4

/dev/hda4:
Timing cached reads: 1356 MB in 2.00 seconds = 676.41 MB/sec
Timing buffered disk reads: 48 MB in 3.03 seconds = 15.86 MB/sec

Here are my disk settings as seen by hdparm:

[root@kirby stump]$ hdparm /dev/hda4

/dev/hda4:
multcount = 16 (on)
IO_support = 0 (default 16-bit)
unmaskirq = 0 (off)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 256 (on)
geometry = 58140/16/63, sectors = 12839662080, start = 33527655

How do those settings and test results look?

[cstump]

OK, I did the prelinking and all seemed to prelink well with the exception of the expected (nvidia, java, etc.). Prelinking does prove to be useful, but its effect on my lagging system is minimal at best. Even with the prelink I was able to take a screenshot of an xterm starting up (I use a white with black text terminal, but when the terminal "lags up" it is all black for a second before it turns white. I could screenshot the black terminal!).

I also double checked my /etc/hosts and 127.0.0.1 is listed properly.

Any other thoughts/ideas??

[nat]

Have you tried other windowmanagers? Happens this problem only with gnome?

Have you checked you have preemive support turned on in your kernel?

Do you have Compsite turned on in xorg? Render?

I would also double check that you reallly are using your nvidia driver correctly. (glxinfo, /var/log/Xorg.0.log)

Take a look at the swap usage. If there is an buggy application that eating up all you memory you computer would need to swap.

Also check that linux really detect all the RAM you should have. There was a guy here who had 512Mb ram, he thought, but linux only detected 128MiB.

Other things you could try is booting without acpi/apm and see if that gives any difference.

You could also run things like ethereal to check if gnome is trying to lookup a nonexisting host that gives the delay. This will verify that /etc/hosts file is really working. (you should have your hostname added in your /etc/hosts in addition to "localhost")

[AndyHamm]

Hi CStump et all,

I know exactly what you mean, allthough I have no answers for you.

I have recently had the oportunity to set up Windows XP SP2, Redhat 9, Suse 9.1 and Gentoo 2004 all on the identical hardware and I found the exact syptom that you are describing to be true.

I was using EPIA motherboards with 800MHz processors and 512MB of RAM with a 40GB 7200 rpm HDD on all of the systems and this is how they rated at perceived speed after a basic install and updating everything on all systems to the latest level:

Windows XP SP W/Office Basic 2003 - The fastest by far. The system boots and is ready to use in under 30 seconds (this is only an 800MHz VIA processor), and the applications launch fast (Outlook 2003 is up and checking mail in less than 1.5 seconds with a pop connection). Web browser launches instantaniously and browses the web with ease.

Red Hat 9 - Fast enough, but pales in comparison to the XP machine. A little over a minute to the desktop, and all GUI programs take at least a second to do anything. It takes 6 seconds to launch Thunderbird and start checking mail, and firefox is noticably slower browsing the web.

Suse & Gentoo - Slow. More than 2 minutes to the desktop, and there is a terrible lag when launching GUI applications (Gnome in Gentoo and KDE in Suse). 12-14 seconds for Thunderbird to start checking mail, and firefox is slow to launch, and slugs when browsing.

Please note that I am Primarily a Windows user, but I refraned from tweaking XP beyond its normal configuration. I have been working with Linux for about 5 or 6 years, but I primarily use it as a Server without a GUI, so tweaking X Windows is not my thing either. I tried to be as fair as possible in my comparison, and I did not look into resolving the issues with Gentoo or Suse beyond the obvious.

The purpose of my test was to evaluate desktops and the cost of supporting them, so anything that did not perform well 'out of the box' was not considered as an option. It might have been possible to tweak Suse or Gentoo to meet the performance of Redhat, but since they performed so poorly out of the gate, this was not done.

Thanks,

Andy

[Gilbo]

cstump,
It looks to me like you definitely don't have DMA enabled. Your STR is clearly capped at 16MB/s which is exactly where PIO-mode transfers top out. This is diagnostic with any operating system that DMA is not enabled.

For example, my laptop drive gives 35.80MB/s, 36.12MB/s, then 35.50MB/s, and that was a quick test from the console in Gnome with a bunch of stuff running.

Enabling DMA should dramatically improve load times, which is typically what most people percieve as snappiness, thereby solving your problem.

[cstump]

[georwell]

Turn preempt on and give it a go and don't forget you can enable DMA in your kernel, not with hdparm when you using 2.6

[psychomunky]

There was a bug a few kernels ago in which it would chew up all of the memory and then all of the swap space. It then made my machine (Athlon 2600+ 1GB DDR RAM, 1GB Swap) grind to symptoms you are describing. This kernel was either 2.6.8 or 2.6.9...I have been using the 2.6.10 kernels for as long as they have been out and have had no problems.

Have a look at /proc/meminfo and see if your swap is maxxed out.

Composite and Render are still experimental extensions at the moment, so it does not surprise me that they slowed things down more.

[Cintra]

[quote="cstump"]

[Gilbo]

You definitely have DMA-mode issues. Those transfer rates are absolutely diagnostic. They're clearly capped at 16MB/s, which is not some sort of wierd coincidence. No remotely modern hard disk drive is going to bench at that speed. Especially not any of the disks an Inspiron 8200 can be configured with. Not without DMA issues anyway.

This is just a hunch, but are you by chance running Gentoo off a hard disk drive in a hotswap bay? Sometimes the hotswap bays in laptops don't have a full, modern ATA channel, designed as they are for optical drives, so this might be the source of your issues. DMA Mode 2 limitations are common on these bays, and so is the reality of being forced into PIO 5. If Gentoo is on the main disk of the laptop, well, obviously you also need to check your kernel config.

Incidentally, if you were in DMA mode 2 the STR should be ~32MB/s. If DMA is enabled you're getting Mode 0 transfer rates. Personally I think you're in PIO 5 considering your snappiness problems. Even DMA 0 shouldn't be that bad except with larger applications and files. Lastly, I wouldn't trust hdparm -i, I would trust -t since it measures the reality of what is coming off your disks.

[cstump]

Thanks for the help everyone!

From the Hitachi link that Cintra posted it says my drive should have the following performance:

Data buffer (MB)2 = 2
Rotational speed (rpm) = 4,200
Latency
(average ms) = 7.1
Max. media transfer rate (Mbits/sec) = 245
Max. interface transfer rate (MB/sec) = 100MB/sec Ultra DMA mode-5
Seek time (ms)
Average (typical) = 12
Track to track (typical) = 2.5
Full stroke
(typical) = 23

But as we saw udma mode 5 doesn't even show up as an option with hdparm -i. Should I still try to enable it with the '-X69' hdparm switch?
Also, as for 32-bit I/O, I've tried doing 'hdparm -c1' and '-c3' but never works (I don't have my box with me right now, so I can't give the specific error message [if any]).

Would you agree that Gentoo is definitely not using the full capabilities of my hard drive? Its beginning to look that way. However, from the googling I've done it seems people with the same drive get '-tT' results the same as mine (Linux users with DMA enabled).

[BlackEdder]

I'd guess you have the generic dma driver compiled and not the chip specific one.

[cstump]

OK, I recompiled my kernel with CONFIG_IDE_GENERIC turned off and CONFIG_PREEMPT turned on. I was also able to get my hard drive running with udma5 and 32 bit I/O. The end result: no change whatsoever. No change in '-tT' test results, no change in "snappiness."

From what I can tell, my hard drive is fine and is using its full capabilities (according to the manufacturer specs). Yes, its slow, but its only a 4200 rpm disk.
Also, my kernel is using the PIIx chip configuration, not the generic one.

I booted up Knoppix and ran 'hdparm -tT /dev/hda4' under there to see if its kernel configuration/hdparm settings would show any difference, but there was no difference. Knoppix seemed "quicker" than my installed Gentoo (at least when the CD wasn't being read).

[Cintra]

Well done ref udma5, etc
At least you know now its set up correctly, and you should be able to swap the 4200rpm with something faster for a reasonable price?
regards
_________________
"I am not bound to please thee with my answers" W.S.

[Gilbo]

I honestly don't think the disk problem is solved. That drive has an STR of ~30MB/s. 4200RPM drives aren't as slow as you think --at least with respect to STR-- due to modern day platter densities. You're not getting 30MB/s off of it.

1. Now, I notice that you keep doing hdparm -t /dev/hda4 (note the four). This might be why your STR is lower than expected. If you could do a: 'hdparm -t /dev/hda' or 'hdparm -t /dev/hda1' it would be more useful. I didn't initially notice that you were benching the fourth partition on the disk. This is important because, depending on how far deep into the inside of the platter your fourth partition is, it is possible that the STR of the disk in that area could be as low as 16MB/s and that you indeed don't have DMA problems. On the other hand, if you don't get ~30MB/s when you bench the outside of the disk there is something still wrong.

I'm sorry to stick to this point, but disk performance issues are exactly the type of problems that cause 'snappiness' issues. There's no other reason Gentoo should be any less snappy than the other OSes & distros you've tried. Not in regard to snap anyway, which is generally a function of disk performance --or caching technique (which does not vary between Linux distros). Most importantly, I believe in eliminating possibilites when trouble-shooting and I just realized that, without a proper bench of the outer edges of your platters we can't eliminate the possibility that hdtach -i is lying to you, which given the available evidence I am presently entirely willing to consider is a valid possibility.

2. If your disk is fine, the snappiness problem may be related to the location of your installation on the disk itself. Like I said above, depending on how close your fourth partition is to the inside of the disk, you could be getting very lousy performance. The closer it is, the worse performance gets. If you're comparing your gentoo install with installs on earlier partitions there is no doubt it's going to be less 'snappy.' Tasks where people notice snap are almost always disk-limited. If your Gentoo install is right on the inner cylinders and XP is on the outer cylinders then obviously the XP installation's snap is going to utterly destroy that of the Gentoo install. It's not an OS issue; it's nothing more than simple disk mechanics.

It's not simply an STR issue on the inner cylinders either, by the way (especially since STR is generally relatively unimportant for most real-world workloads --single or multiuser). Seeks are slower --at least in localized workloads-- because the tracks are shorter and a given dataset takes up many, many more cylinders than it does on the outer edges of the platter. This causes more head switches, more track switches, and lengthens any seek to anywhere in the dataset (which in this case is your OS, your programs, and your data). These seeks are the real penalty of the inner cylinders, not the lower STR. Combine this with the unforgiving rotational latency of a 4200 RPM drive, which will make murder every extra seek you have to make (rotational latency hits you on every seek, no matter how short) and you have an installation that could be at a huge disadvantage relative to those on the outer platters.

Now that I think about it, the location of your installation has probably been the issue all along. You have doomed Gentoo to the unsnappy, innermost cylinders of hard drive performance hell...