electric relaxation

…as promised. I used tbench, which is available in the Debian package archive:

$ sudo apt-get install dbench


My ‘test’ was to run a loopback tbench run with three clients. Make sure your VM isn’t doing anything intensive, then issue:

$ tbench_srv &
$ tbench 3


This will run a tbench test with three clients connected to the server, for 10 minutes with 2 minutes of warmup time. The comparison between VMI and non-VMI kernels on my machine was quite favorable: I got almost a 2X speedup when running with the VMI-enabled kernel! The numbers were 55MB/s before, and 95MB/s after.

I suspect this is some kind of pathological worst-case for the non-VMI kernel, since most benchmarks aren’t nearly this favorable. But nonetheless, I was happy with the result and so I didn’t question it too much.

More about dbench and tbench, from the manpage:

Netbench is a terrible benchmark, but it’s an “industry standard” and it’s what is used in the press to rate windows fileservers like Samba and WindowsNT. Given the requirements of running netbench (60 and 150 Windows PCs all on switched fast ethernet and a really grunty server, and some way to nurse all those machines along so they will run a very fussy benchmark suite without crashing), these programs were written to open up netbench to the masses.

Both dbench and tbench read a load description file called client.txt that was derived from a network sniffer dump of a real netbench run. client.txt is about 4MB and describes the 90 thousand operations that a netbench client does in a typical netbench run. They parse client.txt and use it to produce the same load without having to buy a huge lab.

dbench produces only the filesystem load. It does all the same IO calls that the smbd server in Samba would produce when confronted with a netbench run. It does no networking calls.

tbench produces only the TCP and process load. It does the same socket calls that smbd would do under a netbench load. It does no filesystem calls. The idea behind tbench is to eliminate smbd from the netbench test, as though the smbd code could be made infinitely fast.

This web site runs on Debian “Lenny”, in a virtual machine, powered by VMware Workstation 6.0 running on my Media Center PC at home. The primary bottleneck in this ghetto setup is definitely Comcast, given that my upstream bandwidth is only about 250-300Kbps. Nevertheless, a faster VM can still improve latency on page loads and given that the whole setup is running on a craptacular P4, I don’t exactly have CPU power to spare.

Enter VMI. If I was creating a new installation, I’d go with Ubuntu Feisty, since the Feisty kernel ships with VMI support enabled. But I didn’t want to go through the hassle of converting my existing machine, especially since apps like WordPress don’t do a great job of separating their data in a way that would make this operation easy.

So I decided to try building a newer kernel, with VMI support enabled, for my Debian installation. This turned out to be fairly painless. I mostly followed the useful instructions I found here. Here’s the step-by-step process:

1. Power off your VM, and enable paravirtualized kernel support in the Virtual Machine Settings menu:

   

2. Get the kernel package build tools you’ll need:
   $ sudo apt-get install kernel-package ncurses-dev
   Note: It’s possible to do all of these steps without running as root, using fakeroot and sudo, but I found it much easier to just su and get it over with.
3. Download the 2.6.22-rc3 kernel package from kernel.org. VMI was actually included in 2.6.21, but the menuconfig options are missing in that release for some reason. Anyway, these instructions should apply to the final 2.6.22 release as well.
4. Extract the tarball into /usr/src:
   $ cd /usr/src && tar jxf /path/to/linux-2.6.22-rc3.tar.bz2
5. Change to /usr/src/linux-2.6.22-rc3 and issue make menuconfig.
6. The quickest and simplest thing to do here is to load your existing configuration, then modify it to enable VMI support. Select Load an Alternate Configuration File and enter the path to your existing kernel configuration, which you can find in /boot. In my case, the correct path was /boot/config-2.6.18-4-686.
7. Now it’s time to actually enable VMI support. You can find the VMI menu option under Processor Type and Features:

   



Aside: Notice in the above screenshot that I enabled the Tickless System (Dynamic Ticks) option. You can read more about dynticks here. Note that dynticks and VMI didn’t always play nice together, an issue which caused some fireworks on LKML. Nonetheless, in 2.6.22 these issues appear to have been resolved. Dynticks probably isn’t much of a win since I’m only running a single VM, but given the popularity of this blog, that VM is likely to be doing a whole lot of nothing, so maybe I’ll save a few pennies on my power bill.

8. You’re now ready to build the kernel package. Just to be safe and explicit, choose the Save to Alternate Configuration File option, then hit enter to accept the default, .config. This will save your new configuration as the active one. Now at the command prompt, you can build the kernel with the following commands:
   
$ make-kpkg clean
$ make-kpkg --revision 1.0.vmi kernel_image

   You can replace 1.0.vmi above with a revision of your choosing. However, your string must have only letters, numbers and the period character. Important: Make sure you don’t skip the make-kpkg clean step or you’ll be hit with obscure and confusing error messages.
9. The kernel compile will take a while, so go grab a cup of coffee. When it’s done, you’ll have a shiny new Debian kernel package sitting in /usr/src. In my case, the build package was:
   /usr/src/linux-image-2.6.22-rc3_1.0.vmi_i386.deb.
   Install the package:
   dpkg -i /usr/src/linux-image-2.6.22-rc3_1.0.vmi_i386.deb
10. Hopefully, the package will install cleanly. In my case, I got an error about initramfs, and the initrd image was not created. I resolved this by manually creating the matching initrd with the handy update-initramfs command:
    $ update-initramfs -k 2.6.22-rc3 -c -v
11. You’re almost there! The last step is to run update-grub to update the list of available kernels to boot. You should see your new kernel enumerated in the list printed out by update-grub.
12. Now cross your fingers, reboot, and select the new kernel. If all goes well, your VM will boot and you’ll be sitting at a login prompt in noticeably less time than with your old kernel. Just to make sure, you should see some VMI messages printed in the kernel message log:
    
$ dmesg | grep VMI
vmi: registering clock event vmi-timer. mult=11715026 shift=22
Booting paravirtualized kernel on vmi
vmi: registering clock source khz=2793080
Time: vmi-timer clocksource has been installed.


Ok, that does it. Not too hard, was it?

Next: some wildly unscientific VMI benchmarking.

I sent this patch to the maintainers of WDaliClock a long time ago but they never responded. Well anyway, here’s a patched version of WDaliClock which does not appear in the window cycle list (a.k.a. the “Alt-Tab” list) while running. The fix is a one-liner: I simply applied WS_EX_TOOLWINDOW to the window style.

Patched WDaliClock Binary (.exe)
Patched WDaliClock Source Code (.zip)

I really hate the weird purple color that Windows Vista uses by default for menubar backgrounds. Most Vistatized apps, like IE7, WMP11 or Explorer, don’t actually show the menubar until you activate it with e.g. a keyboard combination, so the ugliness is not as noticeable. But plenty of applications do show the menubar, and that purple is just plain nasty:

It’s even worse when using Firefox, since Firefox uses this color not just for the menubar, but also for any and all toolbars:

I tried out a few of the Firefox 2.0 themes that are floating around (there aren’t very many), but none of them actually tweak the background color. I also found some open bugs in Mozilla’s Bugzilla related to beautification of Firefox on Vista, but there hasn’t been much action on that front.

Fortunately, I found an outlet for my impatience. This simple addition to userChrome.css was good enough to get rid of the ugliness:

menubar, toolbox, toolbar {
   background-color: #eeeeee !important;
}


I don’t think #eeeeee is actually the perfect color, and if I were more motivated I would track down the exact value used on e.g. XP hosts or something, but at any rate it sure as heck beats the default:

What a PITA. EasyTag in Dapper can’t edit tag information for .m4a (AAC) files, nor can you easily compile a version that can edit tag info, because the version of libmp4v2 in the repositories is too old. Debian has an easytag-aac package, but you can’t install or use it on Dapper because it’s system library dependencies are too new.

Fortunately, I wasted an hour of my life and resolved this by downloading a new version of the MPEG4 IP package, building the libmp4v2 part, installing it, and then rebuilding easytag with –enable-mp4.

Since libmp4v2 is also used by gstreamer for AAC playback, and I wasn’t convinced that it was sufficiently backward compatible, I hacked up the linking step of easytag’s build so that it statically links libmp4v2. The resulting easytag can run on Dapper, and edit .m4a tag information.

So come and get it:

EasyTag with AAC support for Dapper

So I wanted the ability to map a key combination that would accomplish the following:

        if (Rhythmbox is running) then
                if (Rhythmbox is visible) then
                        hide Rhythmbox
                else
                        show Rhythmbox
                endif
        else
                start Rhythmbox
                show Rhythmbox
        endif

In other words, a Rhythmbox toggle. Rhythmbox already has a show/hide check option in the tray icon UI, and the rhythmbox-client remote control program that comes with the source package exposes a hide option, so I figured it couldn’t be that hard.

Turns out the DBus Python bindings make this very straightforward. But I ran into an previously unfiled bug in the Python bindings; namely that they define the values for some random constants incorrectly.

[Update: The bug has been fixed.]

It’s funny how all these IPC messaging systems – DBus, COM, VMOMI/VMODL – always end up looking pretty much the same. There are no new ideas, or so goes the saying.

Anyway, here’s the code:

#!/usr/bin/python
import dbus

# These are defined incorrectly in dbus.dbus_bindings
DBUS_START_REPLY_SUCCESS = 1
DBUS_START_REPLY_ALREADY_RUNNING = 2

# Get the current session bus
bus = dbus.SessionBus()

# Explicitly try to start Rhythmbox.
(success, status) = bus.start_service_by_name('org.gnome.Rhythmbox')

# If we started it, make sure we explicitly show it
force_visible = (status == DBUS_START_REPLY_SUCCESS)

# Open the Rhythmbox shell object and get its properties
rbshellobj = bus.get_object('org.gnome.Rhythmbox', '/org/gnome/Rhythmbox/Shell')
rbprops = dbus.Interface(rbshellobj, 'org.freedesktop.DBus.Properties')

# Toggle the visibility value from its current setting
is_visible = rbprops.Get('org.gnome.Rhythmbox.Shell', 'visibility')
rbprops.Set('org.gnome.Rhythmbox.Shell', 'visibility', force_visible or (not is_visible))

[While I'm nerding the f--- out...]

I really like using playlists to keep an arbitrary subset of my music sync’ed to the iPod; it’s the only sane way to deal with, for example, a 20GB iPod and a 45GB music collection. So conceptually what I want is the following:

1. The ability to keep a subset of my music tagged for iPod use
2. Easy addition and removal of music from the subset in (1).
3. A singles playlist suitable for use with the various shuffle modes, with no more than one entry for each song I’ve deemed “single-worthy”.

As an aside, my definition of a single is essentially a song that I really like – that is, one that I have at least at some point played many times on repeat.

Anyway, while these requirements seem simple, they’re actually quite hard to achieve with standard playlists. For example, using a standard playlist, you can only remove music by actually operating on the list, rather than your complete collection. Moreover, since standard playlists are just lists, there’s nothing stopping you from accidentally adding the same track multiple times – easy to do once the singles list gets large. Now you’ve screwed up the shuffle situation, and it’s really obvious since if you shuffle by artist, you’ll end up playing the same song multiple times.

So what I use instead are smart playlists, keyed off two pieces of metadata. The “Grouping” field in the iTunes tag is a free-form text field not really useful for anything else as far as I can tell, so I hijack it for this purpose. I got this part of the solution from Doug’s Applescripts for iTuneswebsite; I adopted and chopped apart the Add/Remove groups scripts.

So I create two smart playlists, iPod Albums and iPod Singles, each populated with music that has the corresponding tag present in the grouping field. To add and remove the tags, I use the scripts to operate on the current selection in iTunes.

Since my Mac died, I’d been doing the Grouping metadata management manually via the track info editor. This eventually became tedious enough that I rewrote the scripts in VBScript for use in Windows.

iPod Playlist Management Scripts

The file is a tarball rather than a zip because Gmail refuses to let you upload a zipfile with VBscripts in it for “security reasons”. I figured they just didn’t bother scanning tarballs at all, but it looks like they still check them on download. Weird.

I got my T42 laptop to output DVI 1600×1200 via the port replicator/docking station, by porting a large patchset that I randomly found attached to a bug report in the Xorg bugzilla over to the Ubuntu ATI driver sources. I am utterly amazed that I actually managed to accomplish something productive via the magic of open source (leaving aside for a moment the question of how this deficit of functionality arose in the first place). Perhaps as an act of atonement I’ll take a day off from my incessant Linux bashing. Or at least a half-day.

Anyway, in case through some miracle another lost soul out with the same issue stumbles upon this page, here are the relevant goodies:

• Patch against Ubuntu Dapper sources
• Ubuntu Dapper package (rebuilt with patch)
• Rebuilt radeon_drv.so

YMMV. Note that this driver is not compatible with the current radeon kernel modules in Dapper. So you have to prevent radeon.ko from loading. The easiest way I know is to just move it out of the way. I don’t care since DRM/DRI is broken for the RV350 card (a.k.a. the Mobility 9600) anyway.