Increasing performance with desktop apps

michapma · 12-28-2005, 11:42 AM

Hi folks,

I'm experiencing unexpected slowness with my desktop using certain applications (notably Firefox, but also other browsers). I'm running Debian Sarge stable (XFree86 4.3.0) on an older box:

Pentium III (Coppermine) 997 MHz, 256 KB cache
512 MB RAM (don't know what speed)
no info on the motherboard or FSB (any hints on how to find this welcome)
Matrox G400 (lspci -v shows 32MB memory)

Here is a review that also shows specs on the G400 32MB:
http://www.firingsquad.com/hardware/g400/

I can certainly accept hardware limitations. However, the G400 was a top card in 1999, and though that was a while ago, it was meant to perform well at high resolutions and color depths. I'm only asking it to run 2d desktop apps at 1280x1024 and 24-bit color depth. (I've enabled text anti-aliasing.)

The biggest problem I'm having is that Firefox is very slow at redrawing. When I switch tabs or scroll in Firefox, there is considerable lag. This is more or less independent of the DE or WM -- I get practically identical performance in both Gnome and IceWM. The problem is less significant in the Mozilla or Konqueror browsers, but still noticable -- especially that XFree eats a lot of resources.

At idle, XFree86 is only taking 0.7-1% of the CPU's resources. But simple tasks such as switching windows or typing in Firefox (as I'm doing now) bumps it up to around 6-14%. When I run top in a terminal and scroll a Firefox window back and forth repeatedly, XFree86 is usually taking 50-70% of CPU time, and firefox-bin takes 25-30% (pretty much the rest). So scrolling in Firefox consumes about 100% of the processor time. This just has to be wrong.

By comparison, when scrolling (1280px) images in gqview, gqview takes about 50-60% and XFree86 about 35%. Gqview is having to load and rescale the images, so this is understandable (not so sure what XFree's contribution is though). I'm much more concerned about the general slowness/lag when switching between, scrolling, resizing and repositioning windows, and most notably Firefox's performance.

I'm wondering if there isn't something that can be done with configuration. I've installed Matrox's proprietary driver (4.2.0, updated Aug 05). I wonder if X is somehow configured wrong.

Any OpenGL rendering is definitely being done with software:

Code:

$ glxinfo | grep -i opengl
OpenGL vendor string: VA Linux Systems Inc.
OpenGL renderer string: Mesa DRI G400 20020221 AGP 1x x86/MMX/SSE
OpenGL version string: 1.2 Mesa 4.0.4
OpenGL extensions:

Any hints on what I can do would be greatly appreciated. Of course I'll be happy to post relevant bits of XF86Config-4 or other system info as requested.

thompson42 · 12-28-2005, 12:15 PM

Quote:

Any OpenGL rendering is definitely being done with software:

What does this show?% glxinfo | grep direct

If it says "direct rendering: no", then performance improvements may be available by enabling direct rendering. The Direct Rendering Infrastructure supports your graphics card. However, it's a tedious thing to put in place manually, and I don't know if it's available via apt-get.

I used DRI in attempt to get my onboard ProSavage graphics to perform better, but I had poor results. I ended up buying a $60 nVidia card.

michapma · 12-28-2005, 12:22 PM

Code:

$ glxinfo | grep direct
direct rendering: Yes

If push comes to shove, maybe I'll end up looking for a better card. There may be one lying around somewhere I suppose.

Funny how I prefer using this machine with Debian to the 3.6 GHz machine with Windows beside it.

foo_bar_foo · 12-28-2005, 02:54 PM

show output from
cat /proc/mtrr

some solutions
try to compile yourself a new highly optimized for your system firefox
possibly build yourself a new highly optimized and faster kernel for better io
throughput

michapma · 12-29-2005, 11:32 AM

Learn something every day.

http://slackware.osuosl.org/slackwar...2.4.5/mtrr.txt
http://en.wikipedia.org/wiki/MTRR

Code:

$ cat /proc/mtrr
reg00: base=0x00000000 (   0MB), size= 512MB: write-back, count=1
reg01: base=0xd0000000 (3328MB), size= 128MB: write-combining, count=2
reg02: base=0xd8000000 (3456MB), size=  16MB: write-combining, count=2

According to this Googled resource, MTRR support is already compiled into my system's kernel:
http://www.tldp.org/HOWTO/DVD-HOWTO-6.html

This line from /var/log/XFree86.0.log seems to show the memory address and video RAM for my card:

Quote:

(--) PCI:*(1:0:0) Matrox Graphics, Inc. MGA G400 AGP rev 4, Mem @ 0xd8000000/25, 0xda000000/14, 0xdb000000/23

I know this is hexadecimal, but I don't know what "/" signifies. Anyway, I get this:
da000000 - d8000000 = 2000000 (hex),
which is 33554432 in decimal, or exactly 32 MB.

As a shortcut, I'm providing a copy of my /var/log/XFree86.0.log for reference:
http://people.ee.ethz.ch/~chapman/do.../XFree86.0.log

There are some entries (warning and otherwise) that may help out.

The proprietary Matrox driver loading report starts at line 288 and is apparently correct (vendor="Matrox Graphics Inc. - Release v4.2.0"). The chipset is identified correctly at line 305 "Chipset mgag400 found". I have no idea about reading the resource ranges.

I also don't know what setting vga for screen 0 is, although screen 0 is my monitor and I suppose sub module "vgahw" could be a driver for the monitor.

Starting from line 363, the HAL library (I guess) is loaded as module "mga_hal". According to the release notes:

Quote:

The Matrox HAL ("Hardware Abstraction Layer") is a special library
to enable features not supported by the standard XFree86 driver.
It's required for DualHead, TV output, and DVI support with G400-
based graphics hardware, for multi-display support with G200/G450 MMS
products, and for DVI support.

Line 377 seems somewhat alarming:
(==) MGA(0): Using AGP 1x mode
The card should be capable of 2X/4X.

line 383:
(WW) MGA(0): Video BIOS info block not detected!
Don't know what that implies.

From line 395, module "int10" is loaded. I don't know what this is, but there are a lot of lines containing VESA, and that indicates to me a problem, since Vesa is a default driver and not proprietary as I want. Again, I don't know if this is a problem.

lines 486 and 488:
(WW) (1280x1024,Generic Monitor) mode clock 135MHz exceeds DDC maximum 130MHz
(II) MGA(0): Not using default mode "1280x1024" (hsync out of range)
This could be fairly normal, but could also be a hint at a configuration problem. I'm using 1280x1024, although I don't know at what refresh rates.

I hope this or other information from the file can prove useful.

I would of course be interested in recompiling my kernel to be "highly optimized and faster for better io throughput", if I felt I knew what I were doing. I get the impression though that optimizing the kernel requires more knowledge than I've gathered so far. I've seen guides for recompiling the kernel, but nothing much for how to actually optimize it for my system. If you have any links for introductory guides on how to recompile for optimization, they're very welcome. (There's even a guide for recompiling/upgrading kernels for Debian on the Debian forum, but I haven't read through it to find out whether there are also hints for optimization.)

Thanks alot for the help.

foo_bar_foo · 12-30-2005, 01:29 AM

all of that x stuff looks fine

might want to try (nohal if you don't use dual heads)
and be prepared for some strange results especially when trying to adjust ram size
you should use startx and not some graphical login to play with these settings i guess.
this goes in section "Device" where you call mga as driver

Code:

Option      "AGPMode" "4"
Option      "NoHal"   "True"

or agpmode 2
also x detects 16 not 32mb frame buffer ??
not sure if the stuff about sdram is apropriate or not.
try without it and with it alone as well.

might be bugs in driver and this is all it will do but it's worth a try

try

Code:

Option		"MGASDRAM"  "True"
VideoRam	32768

michapma · 01-02-2006, 07:13 AM

The "NoHal" option caused big problems. I had to reboot the machine by switch a few times while experimenting, because not only would the screen go blank (not even tty was supported), the system wouldn't respond to anything. I guess if I hadn't installed the HAL driver this wouldn't happen, but I don't think it's really a problem.

The AGP 4x option made a big difference. The memory in use by the system is much smaller than previously; the memory used to fill up as soon as I would open Firefox and start to use it. Now it is staying at 50%, including cache. Looking at the output of top while scrolling shows X taking about 35% CPU and firefox less than 25%.

I also added the SDRAM lines, and it didn't seem to cause any problems. I'll leave them in unless I encounter issues. I'm not sure how you know X was detecting only 16 MB of framebuffer, where did you see that?

On a separate note, I checked the BIOS settings to make sure AGP 4x was enabled. It is, but I noticed a bunch of other settings that raised questions. I remember from trying to optimize my machine at home for gaming that BIOS settings can be key. Under the Advanced Chipset Features, there are the following settings (blue entries are dependent on other entries and are not selectable):

Code:

DRAM Timing by SPD       Enabled
 DRAM Clock              Host CLK
 SDRAM Cycle Length      3
 Bank Interleave         Disabled
Memory Hole              Disabled
P2C/C2P Concurrency      Enabled
Fast R-W Turn Around     Enabled
CPU IOQ Size             4 level
System BIOS Cacheable    Disabled
Video BIOS CAcheable     Disabled
Video RAM Cacheable      Disabled
AGP Aperture Size        64M
AGP-4X Mode              Enabled
AGP Driving Control      Auto
 AGP Driving Value       DA
AGP Fast Write           Disabled
CPU to PCI Write Buffer  Enabled
PCI Dynamic Bursting     Enabled
PCI Master 0 WS Write    Enabled
PCI Delay Transaction    Enabled
AGP Master 1 WS Write    Disabled
AGP Master 1 WS Read     Disabled
Memory Parity/ECC Check  Disabled

Incidentally, the "Video BIOS Shadow" under Advanced BIOS Features is also enabled.

I changed the AGP aperture size from 128MB to 64MB, because I recall from an article on it that more is not always better, and 64MB is generally a good setting. Some of these settings that are disabled I'm not so sure about. I'm most curious about "Video RAM cacheable", "AGP fast write" and the "AGP Master 1 WS" settings. I'm going to do some searching on these, but if you know offhand how they or other settings might improve performance, please let me know.

Thanks very much for helping out. The apps really are already much more responsive.

foo_bar_foo · 01-02-2006, 04:15 PM

i am cluelss about bios
the line i was looking at for the video RAM detection was

Code:

(--) MGA(0): VideoRAM: 16384 kByte

while it's setting up write combining ranges

glad it's working better
that really is a very advanced/complicated video card for its time.

foo_bar_foo · 01-02-2006, 04:32 PM

hey,
i though of another think you can look at
do the command
lspci -v
there find the vidoe card and look for the word latency
you want latency 248
i know it doesn't make sense but higher latency increases burst size for greater efficiency.
if it's not 248 change it to 248 with a command like this
setpci -v -s 02:0a.0 latency_timer=ff
you change the number 02:0a.0 to the number listed for your vidoe card at the left of the lspci output

michapma · 01-03-2006, 09:03 AM

lspci -v gave

Code:

0000:01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 04) (prog-if 00 [VGA])
        Subsystem: Matrox Graphics, Inc. Millennium G400 16Mb SDRAM
        Flags: bus master, medium devsel, latency 64, IRQ 5
        Memory at e4000000 (32-bit, prefetchable) [size=32M]
        Memory at e6000000 (32-bit, non-prefetchable) [size=16K]
        Memory at e7000000 (32-bit, non-prefetchable) [size=8M]
        Capabilities: [dc] Power Management version 2
        Capabilities: [f0] AGP version 2.0

I noticed the Subsytem listing explicitly mentions 16Mb SDRAM, so I'm going to either comment out the lines declaring MGASDRAM and VideoRam, or else change the VideoRam to 16384 (which would be better)?

I did as suggested

Code:

# setpci -v -s 01:00.0 latency_timer=ff
01:00.0:0d ff

lcpci -v again...

Code:

0000:01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 04) (prog-if 00 [VGA])
        Subsystem: Matrox Graphics, Inc. Millennium G400 16Mb SDRAM
        Flags: bus master, medium devsel, latency 248, IRQ 5
        Memory at e4000000 (32-bit, prefetchable) [size=32M]
        Memory at e6000000 (32-bit, non-prefetchable) [size=16K]
        Memory at e7000000 (32-bit, non-prefetchable) [size=8M]
        Capabilities: [dc] Power Management version 2
        Capabilities: [f0] AGP version 2.0

Brilliant! Let's see what she does.

foo_bar_foo · 01-03-2006, 11:11 PM

i guess i would just comment out those lines cause the driver is detecting correctly on it's own