I’d previously posted a patch for echo suppression for Qt Extended on the OpenMoko Neo, but it was completely bogus! 🙂

So I went back to the drawing board and changed it to use the AT%N0187 command to enable both noise reduction and echo suppression in one hit as I worry that the original method of using a command for each would result in the previous command being undone. I also added them to a couple of other places where
they looked like they’d be important such as on initialisation and on wake from suspend.

I’m using a slightly earlier version of the attached patch (only removed two comments and inserted some blank lines) on my Neo at the moment and it seems to be working fine – on a test call from a train I was told there was no echo (with the volume at max and mic gain right up) but that I “sounded like I was in a bathroom”, i.e. there was a bit of reverb. 🙂

I’m not convinced that it’s completely foolproof as I don’t know if it’ll remain enabled if I get two incoming calls without a suspend in between.

But it’s still a lot better than what I’ve been having to put up with since I got this going!

I’ve attached both the echo patch to this post and the compiled version of the Neo plugin that is running on my phone. To use it you will need to scp it onto your Neo and then:

root@om-gta02:~# cd /opt/Trolltech/Qtopia/plugins/phonevendors/
root@om-gta02:~# mv libneovendor.so libneovendor.so.orig
root@om-gta02:~# mv /home/root/libneovendor.so .

Once you’ve done that reboot the phone and you should be using the new version!

Attachments

• 0001-added-echo-suppression-fixes-for-the-openmoko-neo-ph.patch
• libneovendor.so

Having previously posted some nice XFS Bonnie++ numbers on the work Dell E4200 I use I thought I’d redo these after having migrated to a RAID-1 configuration of the experimental btrfs filesystem. As SSD’s are not necessarily as reliable as spinning disk yet for data integrity I wanted a system that could spot this and correct for it, so I created two equal size partitions on the SSD and created the filesystem with mkfs.btrfs -d raid1 /dev/sda10 /dev/sda11 before mounting it with the ssd mount option.

Version 1.03c       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
sys26            2G           27458  23 21782  19           108478  39  3079  21

                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16  7542  99 +++++ +++  5818  99  7232  99 +++++ +++  5638 100
sys26,2G,,,27458,23,21782,19,,,108478,39,3078.8,21,16,7542,99,+++++,+++,5818,99,
7232,99,+++++,+++,5638,100

real    3m30.808s
user    0m0.404s
sys     0m55.599s

Whilst the raw numbers are nowhere near as good you have to remember that this is doing checksumming of all the data and mirroring it across the two partitions I created for it and, if it finds a problem with the data, will try and recover using the data on the other partition. It’s also still in development!

Executive summary: ext4 rocks, check the numbers at the end!

With 2.6.28 arriving over Xmas I took the opportunity to upgrade my home desktop and laptop to it (the laptop had been running a number of RC releases quite happily). Everything was happy so I thought I’d try migrating my /home partition to ext4, but before I started I decided to run a quick Bonnie++ comparison between XFS and the new stable ext4 from the console before the rsync. The (very) rough numbers were:

I didn’t note down the rest. So not a lot of difference there (or so I thought, but more on that in a bit). Using rsync to copy all my data over didn’t take too long and a quick shuffle of UUID’s in /etc/fstab and I rebooted and was happily using my shiny new ext4 logical volume. Everything was working fine but it wasn’t until I was poking in the logs a day or two later that I noticed this:

EXT4-fs warning (device dm-13): ext4_fill_super: extents feature not enabled on this filesystem, use tune2fs.

That’s unusual because since 2.6.23 that was meant to be enabled by default. A quick play with tune2fs under both Ubuntu Hardy and Intrepid showed that they didn’t support that option so I ended up grabbing
e2fsprogs from SourceForge and building it myself. With that done I could use its mkfs.ext4 command to build a fully functional ext4 filesystem and get the far better message:

EXT4-fs: file extents enabled

Another long rsync later and I was up and running with ext4 with all the features I wanted.

Of course this meant that my initial ext4 numbers were without extents, so I’ve just done another run (though this time with X and a full KDE 4 session going) and was blown away by the results:

Version 1.03b       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
quad            16G           68123  17 30013   6           64239   8 363.1   1
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++
quad,16G,,,68123,17,30013,6,,,64239,8,363.1,1,16,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++

real    18m18.005s
user    0m1.280s
sys     1m46.434s

That’s a full 2 minutes faster (and then some) and the I/O is just enormous!

So here’s that first table again, but with an extra column for ext4 with extents:

This looks fun.. 😉