[clug] Ubuntu at the low end

[Boyd Wilding]

Good write-up!

I live literally right next to Charity computers if you want me to ask them
anything. I'm on holidays this week so I have the opportunity to wander in
during the day.



On Mon, Jul 7, 2008 at 2:43 PM, Jason Stokes <glasper9 at yahoo.com.au> wrote:

> I've been playing with Ubuntu 8.04 for the past couple of weeks on a
> very old PC -- a PII-400-MMX with 256 MB of PC100 RAM, and a TNT II
> video card.  I had previously installed 7.04 on it last year (the old
> "stick it on an old PC and try it out" school of Linux adoption), took a
> look at it, and promptly forgotten about it.  Installing 8.04 reminded
> me /why/ I had forgotten about it: because Ubuntu, out of the box, is
> slow as a dog on it, at least as far as running Gnome on the desktop
> goes.  Scrolling is slow.  Page rendering is appalling, and
> tab-switching is painful. Load times are shocking.
>
> The scandal is that with just a little optimization, I've found Ubuntu's
> desktop performance on this machine can be vastly improved.  It's still
> a little sluggish on some things, and load times are still an issue with
> some apps, but it's definitely useable.  In fact, the effects are so
> noticible that it suggests that it is possible to make dramatic software
> optimizations in the Gnome/Xorg code base, if only the developer will
> existed.   More on this below.
>
> Some subjective impressions on what performance tweaks worked:
>
> * 256 MB of ram just isn't enough for Gnome, no matter how much you
> tweak.  The system would swap constantly.  I added an extra 256 MB
> stick, I had lying around and the system is now very comfortable. I
> would split the difference, and say that the minimum RAM you need is 384
> MB.
> * Choice of gtk theme has a /big/ influence on responsiveness.  The
> default Ubuntu theme (human) is extremely slow.  The fastest theme I've
> tried is ThinIce, which turns Gnome apps from sluggish to actually quite
> responsive.  Surprisingly to me, changing the theme to thinice yielded
> the biggest singular performance improvement.
> * Disregarding the philosophical issues, if you care about performance,
> definitely try a binary-only xorg module.   I'm using the "legacy
> nvidia" driver and it's responsible for a noticible improvement in
> drawing speed.
> *  Slow load time is hard to fix.  Hdparm on /dev/sda doesn't yield
> anything very helpful:
>
> /dev/sda:
>  IO_support    =  0 (default)
> 16-bit)
>  HDIO_GET_UNMASKINTR failed: Inappropriate ioctl for device
>  HDIO_GET_DMA failed: Inappropriate ioctl for device
>  HDIO_GET_KEEPSETTINGS failed: Inappropriate ioctl for device
>  readonly      =  0 (off)
>  readahead     = 256 (on)
>  geometry      = 1247/255/63, sectors = 20044080, start = 0
>
> I'm pretty sure that the kernel is actually using the optimal transfer
> settings for the drive, given that the BIOS seems pretty solid.  I think
> it's just an old, slow hard drive and it's being called upon to load
> some pretty bloated applications.
>
> Some guides recommend installing "preload", a kernel daemon that
> monitors frequently used applications and prefetches them into the
> kernel disk cache.  Based on my experience, preload definitely seems to
> work, but the performance improvements are modest and incremental rather
> than dramatic.
> * You really learn who your friends are running a PC this slow.  Firefox
> 3 release is noticeably faster than the beta.  Anjuta using the
> GtkSourceView editing plugin is really snappish, whereas Anjuta using
> the Scintilla editing plugin is unuseable.  And of course even users on
> much more modern PCs complain about how bloated an app like Nautilus is.
>
> In other words, the quality of the coding in the application /matters/.
> The difference between efficient and inefficient coding is extremely
> noticible on hardware this low end.  Based on my experience, I would say
> that if the Gnome team made a concerted effort to improve the efficiency
> of their code-base across the board, performance on the low-end would
> improve dramatically.  This would have flow-on effects even for those
> not using 10 year old PCs.  Indeed, I believe that one way to get
> movement on the Gnome performance issues would be to force the Gnome
> developers to use 400 Mhz PCs for their daily work.  I would bet that
> they would quicky find a way to optimize their way around the
> performance bottlenecks.
>
> Performance optimization is particularly important because I believe the
> low-end is an important niche for Linux.  There's the "old PC" install
> base.  There's developing countries, for whom any PC is a luxury.
> There's the growing "small cheap machines" market, which Ubuntu
> currently struggles on (for example, the gentleman at the last CLUG
> whose Ubuntu install on his Asus PC took several minutes to boot up.)
>
> There's an organization called "charity computers which has branches in
> Canberra and Brisbane: http://www.charitycomputers.com.  Charity
> Computers provides old PCs cheaply to the unemployed, hard-off etc.
> They pre-load versions of Windows on these PCs, and give them out to the
> unemployed, hard-off, etc -- in fact, by admission completely illegally,
> since the cost of the license fees from Microsoft would eclipse the cost
> of the PC.  I don't know how they've dealt with the mandatory
> registration requirements of XP and Vista.
>
> I've often wanted to suggest to them that they switch to Linux for those
> PCs, but as it is the performance issues are real enough.  I want people
> to be impressed when they put Linux on an old PC, not disappointed by
> slow performance.  There are also very real useability issues I've
> noticed in Ubuntu, but that's an issue for another day.
>
> Jason
>
> --
> linux mailing list
> linux at lists.samba.org
> https://lists.samba.org/mailman/listinfo/linux
>