UbuntuSolutions

Since Jaunty was released, most computers with Intel GPU have suffered from dismall video performances. It's not only about videos, it's also about browsing the web with Firefox, scrolling through pages is slow, sometimes blocks, and compiz effects suffer from occasional flashes.

This fix is for the AAO D150 which is equipped with Intel 945GM.

# lspci  | grep 945
00:00.0 Host bridge: Intel Corporation Mobile 945GME Express Memory Controller Hub (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GME Express Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)

I tried several things. I started experimenting with the instructions at Jaunty Intel Graphics Performances Guide (safe solution) but it didn't help, if anything it got worse.

Then I reverted to the regular driver (aptitude was of great help here, I used "aptitude remove xserver-xorg-video-intel" and it kindly offered me to downgrade to the regular jaunty version instead of completely removing the package).

I found that page that explains how to revert to version 2.4 of the driver.  The instructions in the article work just fine and after restarting X, the video performances are back to normal. In short:

Add to /etc/apt-sources.list:

deb http://ppa.launchpad.net/siretart/ppa/ubuntu jaunty main

Add the server key:

sudo apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 0xce90d8983e731f79

Install the 2.4 package:

sudo aptitude install xserver-xorg-video-intel-2.4

Restart X and you're done.

Using an SD card to run Ubuntu

The Acer Aspire One 110 is notorious for its small and sluggish SSD disk (SSDPAMM0008G1EA). Firefox is so slow it seems web pages will never finish loading and you'd better not be in a hurry when starting the package manager or setiing up Ubuntu updates. I wanted to find a solution that wouldn't involve tearing the motherboard apart and I found one. It cost me about $40 and a couple of hours of work.

The idea is to use a fast SD card as the primary drive of the laptop by installing Ubuntu on it, the SSD becomes an extra storage device. As you will see below, the SD card shows more balanced performances than the SSD and significantly faster write speeds.

I chose to buy the Transcend 16 GB SDHC Class 6 memory card. Note that it is sold with an USB adapter that comes very handy when installing the OS on the AAO.

Setup

There is just one problem with the setup: the bios on the Acer Aspire One is unable to boot from the SD card. That means that you can't just setup Ubuntu on it and restart. The workaround is to let the laptop boot from the SSD: the bios reads the MBR and starts grub on the SSD. The initrd kernel image is also on the SSD and that kernel is capable of mounting the SD card. Only after this is done can the regular boot process resume and the actual kernel get loaded from the SD card.

I followed the very good installation instructions I found on osnews.com. They are very detailed, I followed them point by point and I didn't run into any issue. Here is a slightly modified list of steps that goes straight to the point:

• Install Ubuntu on the SSD if it's not already there. In my case it was there so I could skip that step. I found the version of linux present on the SSD doesn't really matter, it will just be used for its /boot directory and grub.
• Boot from a USB drive where you can Install Ubuntu from. I used the 9.04 alternate CD. I had plugged it in the USB slot on the right of the AAO and I had the SD card in the USB adapter  on the left of the AAO. It might be possible to just stick the SD card directly on the left SD slot on the left, I think the 9.04 install USB key would be able to find it but I haven't tried and you will need the adapter on step 4 anyway.
• Proceed with the actual installation to the SD card from the USB drive.
• Reboot from the newly installed SD card (inside the USB adapter: there's no way around this for this step). Mount the old SSD on /ssd

mount -t ext2 /dev/sda1 /ssd

• Now you must reconfigure how initrd.img files are generated. The goal here is to include support for the SD card reader in the initrd. Without it, you won't be able to access the card from grub. Edit /etc/initramfs-tools/modules on the SSD card and add those 4 lines:

mmc_core
mmc_block
sdhci
sdhci-pci 

• Regenerate the latest initrd kernel image and copy it inside of the SSD /boot directory.

update-initramfs -u 
cp /boot/initrd.img-2.6.28-12-generic /ssd/boot

• Edit /ssd/boot/grub/menu.lst on the SSD drive. There you will create a grub menu entry that points at a kernel on the SD card. Replace the UUID below with yours.

title           Ubuntu 9.04, kernel 2.6.28-12-generic-SDCard
uuid            5ce02d2f-1fee-4cc5-8c7d-bde5f19b26b8
kernel          /boot/vmlinuz-2.6.28-12-generic root=UUID=5ce02d2f-1fee-4cc5-8c7d-bde5f19b26b8 ro elevator=noop quiet splash
initrd          /boot/initrd.img-2.6.28-12-generic
quiet

Note that the UUID on the "kernel" line is the UUID of the SD card. So in the /boot directory of the SD card, there must be a vmlinuz file that matches the initrd file from the SSD card.

That's it, you can reboot one last time, select  "Ubuntu 9.04, kernel 2.6.28-12-generic-SDCard" from the grub menu and if the gods are with you, you will load the OS from the SD card. At this point you will enjoy an Ubuntu setup that will feel twice as fast as the old one with 3 times more storage space.

Beware: anytime you get a new kernel, by default it's only installed on the SD card but you need it on the SSD drive. So don't forget to copy the new initrd.img to /ssd/boot and to update /ssd/boot/grub/menu.lst whenever needed or you won't be able to use the new kernel.

Disk performance measures

Now that is just a feeling at this point. Here is how to back it with concrete numbers. I found the dd test page very helpful for this experiment. One can easily measure the disk  read speed with hdparm but that ells you nothing about the write speed.

$ hdparm -tT /dev/mmcblk0p1

/dev/mmcblk0p1:
 Timing cached reads:   1144 MB in  2.00 seconds = 572.07 MB/sec
 Timing buffered disk reads:   40 MB in  3.16 seconds =  12.67 MB/sec

So the best way to get both read and write speed is the following:

To measure the sequential write speed, write a large file to disk while measuring the time it takes. Note that the sync command is essential to guarantee all the data gets written instead of staying in some cache. Do not trust the throughput reported by dd, instead divide the size of the file by the duration reported by "time". For example, here is the test on the SD card (it generates a 160 MB file):

$ time sh -c "dd if=/dev/zero of=ddfile count=20000 bs=8k && sync"

20000+0 records in
20000+0 records out
163840000 bytes (164 MB) copied, 13.4757 s, 12.2 MB/s

real    0m18.885s
user    0m0.020s
sys     0m0.640s

To measure the read speed, read the same large file from disk:

$ time dd if=ddfile of=/dev/null bs=8k                
20000+0 records in
20000+0 records out
163840000 bytes (164 MB) copied, 9.96247 s, 16.4 MB/s

real    0m9.974s
user    0m0.016s
sys     0m0.588s

I ran that test on the SD card, on the SSD and on another Acer Aspire One  (AOA 150) with a regular hard disk.

As you can see although the SD read speed is just 60% of the SSD read speed, the write speed is almost 4 times higher on the SD card and for normal usage of a laptop that write speed increase changes everything. It worked so well, I decided to use Gnome on this machine and it appears to go twice as fast as Xfce was going on the SSD. Not that the Acer Apire One got magically turned into a Ferrari but with that SD card, it became a pretty decent Toyota!

I ran into a major issue after upgrading an old Acer Aspire One netbook running Xubuntu to Jaunty. It makes Xfce unusable especially if you have to login/logout or reboot frequently. Fortunately, there is a workaround.

Symptoms

• The xfce desktiop takes minutes to initialize after the login windows. As I login and logout a few more times, the delay increases and goes over an hour.
• Similar symptom when running the update-manager. Starting it up takes minutes/hours, the download and installation of new packages is equally slow and finishing up updates (when update-manager reloads it database) feels like it will never end.
• While I'm waiting the HD light stays solid green. Running pidstat while update-manager is working shows a high number of xfdesktop processes, very high IO activity, crazy context switching and reduced available memory.

Causes

• The Aspire One disk is extyremely slow, any swapping will make the machine slow to a crawl. That's an aggravating factor.
• But what seem to cause the issue is that I have configures Xfce to "Save sessions" on exit. Apparently that causes the same processes (including xfdesktop) to be opened 2x, 4x and more every time an xfce session is started. After a bunch of restarts, the number of started applications is just too high and the AAO can't keep up.

Workaround

In  Xcfe "System Settings"/"Session and Startup", uncheck  "Automatically save sessions on logout". And in the logout confirmation window, be sure to uncheck the "Save sessions" checkbox.

A bug has been filed in launchpad precisely on that problem and it suggests a workaround: Multiple instances of xfdesktop started simultaneously

rm -rf ~/.cache/sessions
rm -rf ~/.config/xfce4/desktop

Then logout and login again. The problem should go away.

I started installing Jaunty on my computers 2 weeks ago. The first one to get the honor was a new Acer Aspire One. For this one as for the other ones, the install went flawlessly:

• the installer shrunk the windows partition automatically
• wireless was working after install (except on the all Aspire One with the Atheros interface. Not resolved yet because of lack of time but it appears a solution exists: https://bugs.launchpad.net/ubuntu/+bug/350352)
• graphics with 3D compiz effects were all working now using the 180.44 driver that got installed seamlessly.

After the initial  install, I had some troubles...

Troubles with Ext 4

No trouble with ext4 on the new AA1, the conversion worked, nothing to complain about.

It was a very different story on a Dell laptop of mine. The conversion to ext4 succeeded there too, the machine rebooted fine after the conversion, but then I read a post about the need to append  "rootfstype=ext4" to the kernel line in /boot/grub/menu.lst. I decided to go for it. Big mistake.

Now, that was a really stupid idea. I can't say for sure that's what broke it but in any case, the machine would not reboot after that, it would only go to grub console.

I tried reinstalling grub several times:

• boot with a live CD (I used a Jaunty live USB pen that I had)
• go to the grub prompt by simply typing "grub"
• root (hd0, 5)
• setup (hd0)

That rewrites the MBR with a brand new grub (supposedly supporting ext4 since it's 9.04). That didn't help. It wouldn't go past the grub console on startup. No error message is shown. The console sees the partitions, it even sees the files on the partition I want to boot from but it would not boot from it. Trying to 'cat' a file from grub shows only garbage.

I also tried to repair the partition table just in case (using systemrescuecd and Test-Disk). Nothing would help.

Fortunately, when booting from a live CD, I was able to mount the partition where I had my home directory so I could back it all up. I finally resolved to reinstall the system entirely with a full disk repartitioning and reformatting and I restored the home directory from the backup. That all went fine. I had lost a crazy amount of time on that issue though. So my recommendation is to not add that "rootfstype=ext4" to menu.lst. At best it will change nothing, at worst it's going to kill your installation.

Boot time

I measured the boot time before and after the upgrade and reinstallation on that Dell laptop. The startup time is measured between grub and the gdm login page:

• Intrepid: 52s
• Jaunty after upgrade still using ext3 on the main partition: 46s
• Jaunty after upgrade after the ext4 conversion: 46s
• Jaunty after full reinstall from scratch (using ext3): 36s

So, that's not quite what the hype tells us it is, it's merely an 11% boot time improvement from Intrepid to Jaunty and ext4 does not make any difference.

ATI, fglrx and xorg 1.6

Jaunty comes with xorg 1.6 and ATI has not released a unix driver yet that supports it. As a result, 9.04 does use the open source driver called just "ati" on machines using ATI video cards. I was a little reluctant to upgrade on an old desktop with an ATI card because of that. I'm not a Quake player but I didn't want to lose the compiz effects.

But it the end, this open source driver works wonders, the 3D effects appeared just as smooth as on intrepid and the CPU usage actually appeared lower while playing videos. I don't think I will swittch back to the ATI fglrx proprietary driver!

Recently, I bought myself a nice little Acer Aspire One laptop. I swiftly got rid of the dull Fedora variant installed on it and replaced it with Ubuntu 8.04 and then 8.10. I had my share of troubles with the wireless card on the machine, especially with 8.10 and WPA2 networks, must as of now, it all works.

The AAO doesn't have a lot of system resources. 512MB memory and just 8GB of disk. This disk is actually an SSD drive, but it's the slow kind, really really slow especially when writing. As a result the laptop regularly comes to a standstill for a few seconds, with the disk light on solid, before reemerging. Annoying.

Here's what hdparm has to say about the disk:

me@aao # hdparm -i /dev/sda1
/dev/sda1:
Model=SSDPAMM0008G1EA                         , FwRev=Ver2.I0H, SerialNo=CVCP8236821U5
Config={ HardSect NotMFM Fixed DTR>10Mbs }
RawCHS=15636/16/63, TrkSize=32256, SectSize=512, ECCbytes=4
BuffType=DualPort, BuffSize=1kB, MaxMultSect=1, MultSect=?0?
CurCHS=15636/16/63, CurSects=15761088, LBA=yes, LBAsects=15761088
IORDY=yes, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes:  pio0 pio1 pio2 pio3 pio4
DMA modes:  mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 *udma4
AdvancedPM=no
Drive conforms to: Unspecified:  ATA/ATAPI-4,5

Firefox is the application where it happens the most often. Firefox loads a page, it appears to be done, but it then freezes for a few seconds with that damn disk light on.

Why is that? Let's see. First let's make sure that it's Firefox using the disk. The great "pidstat" tool, part of the sysstat package is your friend. Start it up with the -d option to let it monitor disk activity and reports every X seconds which application is reading or writing to disk:

pidstat -d 5

There are always a few applications doing some IO at any point in time. Firefox, pdflush keep showing up in the list, but it's normally less than 4KB in or out per sec and that's fine.

Now load some web pages and keep an eye on the output of pidstat.

16:26:25          PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
16:26:30         6026      0.80      6.40      2.40  firefox

16:26:30          PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
16:26:35          181      0.00      2.40      0.00  pdflush
16:26:35         6026      5.60     41.60      0.80  firefox

16:26:35          PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
16:26:40          181      0.00      5.60      0.00  pdflush
16:26:40         6026     51.20      8.80      0.00  firefox

16:26:40          PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
16:26:45          181      0.80      1.60      0.00  pdflush
16:26:45         4540      0.00      2.40      0.00  syslogd
16:26:45         5441      0.00      0.80      0.00  wpa_supplicant
16:26:45         6026      3.20    107.20      1.60  firefox

Here you go, the page finishes loading and firefox starts writing to disk making the system unresponsive for a few seconds. It doesn't happen on every page and I noticed the high reading rates are not as bad as the lower write rates. 30KS/s write for 3 seconds is enough to make you feel the pain.

Now, let's find out what Firefox is writing. For that task, strace is what you need. First find the firefox pid. Once you have it, attacch to firefox using strace. strace will pring all the system calls the application makes including IO. What I want to know is what file is opened after a page finishes loading and how much data is written to it. Since there is a crazy amount of noise around the interesting data, I have to filter out of strace all the system calls I don't care about.

strace -p 6026 2>&1 | egrep -v "gettimeofday|poll|EAGAIN|itimer|sigaction|recvmsg|socket|bind|sendto|futex|select"

I try to start that command right when a page finishes loading and the disk light turns solid green and turn it off right after it goes black again.

What I see during those few seconds are a lot of writes to a couple of file descriptors (29 and 44):

write(44, "\r\r\374\0\t\t\244\0\16\302\16,\r\217\fy\v\304\v$\nu\n"..., 4096) = 4096
write(29, "\n\0\0\0\235\3o\0\0040\4E\4Z\4o\4\204\4\231\4\256\4\303"..., 4096) = 4096

Now to find what those file descriptors are:

me@aao # lsof -p 6026 | egrep " 29| 44"
firefox 6026 me   29uw  REG        8,1  1892352 467957 /home/me/.mozilla/firefox/kuz6twft.default/places.sqlite
firefox 6026 me   44u   REG        8,1    94904 467854 /home/me/.mozilla/firefox/kuz6twft.default/places.sqlite-journal

Firefox is writing to 2 sqlite database files. The places database is described at Mozilla Dev Center.
Places is the database where all of your history and bookmarks go. The history can grow very big thus getting the database to several MB or even several tens of MB. It seems every link you ever download, of any kind, text, js, images, everything goes in. That's a lot if inserts and as the database grows, each insert takes more time.

You can't turn off using that database AFAIK, nor limit the number of entries that goes in it. There are other databases that Firefox writes into and that also slow things down: the anti-phishing one and the cookies one. You can, although I don't recommend it, turn off the anti-phishing one: go to about:config, search for safebrowsing.enabled to change it to false.

That leaves you with few options to improve the situation. Here are the options sorted by order of effectiveness:

• change history expiration setting: Go to about:config and reduce browser.history_expire_days
• compact the database from times to times. When Firefox is off:

  sqlite3 "path to database" 'VACUUM;'

• move the mozilla files including the databases to a memory partition. Create a tmpfs partition at /home/yourself/.mozilla. Make a copy of the directory you have on disk at the moment. Create a script to start firefox. This script will start by copying the on disk .mozilla to the on memory .mozilla. Then it starts firefox. When firefox shuts down, the script copies the daata from meemory to disk.

Note that I haven't tried that last option as I'm afraid it would need too much memory on a computer where this resource is already scarce.

But the first option that requires reducing "reduce browser.history_expire_days" is simple and works quite well. I set it to 7, that drastically reduces the size of the sqlite database and delays displaying web pages are now rarely above 2 seconds.