[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: speed problems on laptop [SOLVED]

On Sat, Jan 29, 2005 at 09:42:40PM -0500, I wrote:
> I'd like some help diagnosing speed problems on my laptop.
> Symptoms:
> - When editing a file in Vim in a gnome-terminal, it takes longer to
>   move the cursor from line to line at the top of the screen than at
>   the bottom.  Generally scrolling the window takes longer than
>   before.  An xterm is faster than a gnome-terminal, but still seems
>   slower than before.
> - According to Windows Task Manager, Windows under VMWare uses 30% cpu
>   more-or-less constantly (which it may or may not have done before;
>   not sure), and more often than not 100%.  *Moving the mouse in a
>   circle* uses 60-70% cpu.  Most cpu usage in Task Manager is "kernel"
>   usage.
> - Switching to "full screen mode" under VMWare makes Windows run
>   faster.
> - Generally X performance seems slower.
> - Generally X seems to take a lot of CPU, as reported in 'top'.
> - Slooooow kernel compile.  I'm running one now; so far it's taken 50
>   minutes.  By contrast, my 1.4 GHz desktop (with, admittedly, twice
>   as much ram) compiles a 2.6.6 in ~8 minutes.


Hardware problem.  Cooling fan failure.  CPU running at ~5% normal
speed[1].  Somewhere along the way I either broke, uninstalled, or
disabled cpufreqd, and let the laptop handle the fans itself.  One of
the fans got stuck, and the bios (or whatever) didn't turn on the
other until much later, and ran the CPU a lot slower in the bargain.

I unstuck the cooling fan and installed i8kmon; no problems so far.

Windows under VMWare now takes little cpu when idle.  gnome-terminal
is more-or-less snappy again; X in general, too.  Kernel compiles in
16 min.

> Hypotheses:
> - Hardware problems?  IRQ contention?
> - Someone did something stupid in some basic routine in a core library
>   (e.g. memset) that makes it run a lot slower than it used to,
>   causing a systemic slowdown, including in VMWare.
> - My laptop is, for reasons of its own, down-stepping its cpu usage,
>   via acpi, cpufreq, or similar.

So it was a systemic problem, and "something" had, in fact, slowed
down the cpu quite a lot, but it wasn't (surprise!) a library issue.

Thanks anyway!

-- Larry Clapp

[1] Kernel compile in "slow" mode: > 4 hours.  In normal mode: ~16

Reply to: