Measure twice, cut once

Or, A Tale Of Why Not To Fiddle.

I mentioned in a recent entry that I’d reinstalled my laptop, and also mentioned a few of the things I changed after the reinstall.

One thing I didn’t mention was changing the hdparm settings. By default, the system had DMA enabled, but not ‘unmask irq’, ’32-bit IO support’ or ‘multiple sector I/O’. I edited /etc/hdparm.conf to turn these on and set MultiSector IO to 16. I’ve been using these settings for a while – before reinstalling this laptop, and I’d copied them in turn from an older machine where I’d done measurements on each option to find the best setup.

I also mentioned tweaking some of the xorg.conf settings. In particular, AGPMode and AGPSize. Eric Anholt commented that probably neither of these is a good thing to do – that AGPMode might provide some speed improvement in 3D rendering, but usually not much, and can also destabilise some systems when turned too high. I had thought that AGPSize sets the maximum amount of System RAM the X server can allocate for AGP Memory to talk to the graphics card, and that this was dynamically allocated when needed. Eric tells me, however, that the entire AGPSize RAM is reserved at server startup.

About 3MB is used for the buffers to communicate with the card, and the rest is kept as texture memory. Since the card in this laptop already has 64MB onboard, it’s unlikely (with the 3D apps that I run) that it will overflow, which means that providing an extra 56MB of RAM for this purpose is pointless, and a waste of good RAM. I tried a bunch of 3D apps that I regularly use (Togra, q3a, Tron) and couldn’t discern any performance difference (naked eye only – no fps tests). In the end, I took both settings back out and let X.org use its defaults again.

The hdparm changes and the xorg.conf settings were the only system things I’d changed from the default install, and I knew that hibernation had worked once before changing them, but didn’t work later. I figured maybe one of the settings might be the culprit, so I also put the hdparm settings back to the defaults – and hibernation worked again!

After some test cycles, I found that setting MultiSector IO on breaks the hibernate for some reason – turning it back off instantly makes hibernate work flawlessly. Interestingly, some googling for this problem seems to indicate that at some point in the past at least one ThinkPad model needed multi-sector IO turned ON in order to hibernate.

While I was at it, I figured I should actually run some tests and see if the other 2 changes (-c1 and -u1) actually made some difference. I tested using bonnie, and found that -c1 seemed to provide a modest increase in disk throughput. -u1 seems to decrease io throughput slightly, but (going by the hdparm manpage) allows better system responsiveness during heavy IO by allowing other interrupts to be processed during a disk interrupt. Enabling -u on some systems can be really bad (read: filesystem corruption), which is why it is off by default. I decided to leave both these settings turned on.

The moral of the story of course is not to blindly copy settings or change them without actually measuring and having a good reason to – the same rules we use when performing any optimisations. Alternatively, the moral is to be a X/kernel hacker and know what’s best already 🙂

For Ronald

It happens that I was (re)installing Ubuntu Dapper on my laptop this afternoon too, like Ronald was on his new Mac.
The laptop has been dist-upgraded since I first installed warty on it, and on the development repositories for most of the way. It had accumulated a bit of cruft because of all the hacks I had to do when things broke during the dev cycles, and I’d never been able to get either hibernation or suspend to work at all.
I copied /home, /etc and /var off to another machine and did a complete reinstall, which worked flawlessly.

Here’s some notes from the post-install. There aren’t many, because by and large things worked flawlessly for me:

  • X had the wrong resolution by default. I had to edit /etc/X11/xorg.conf and change it from 1024×768 to 1400×1050.
  • The 3D stuff was set up automatically, using the open source DRI drivers. For better DRI performance (xorg doesn’t get them right on its own), I added these lines to the xorg.conf:
    • Option “AGPMode” “4”
    • Option “AGPSize” “64”
  • Multimedia.
    • plugins – the usual story – too many formats are encumbered for one reason or another and can’t be included in the default install, so playing anything from Apple Trailers wouldn’t work. Following the instructions in the Ubuntu wiki, I added the universe and multiverse repositories to my apt configuration in /etc/apt/sources.list and installed the packages for restricted formats:
      • gstreamer0.10-ffmpeg gstreamer0.10-pitfdll gstreamer0.10-plugins-bad gstreamer0.10-plugins-bad-multiverse gstreamer0.10-plugins-ugly gstreamer0.10-plugins-ugly-multiverse
    • After that, I could play trailers on the Apple trailers site, and Rhythmbox could play the few m4a files I have access to.
    • I only partially agree with Ronald about the ‘cryptic fd://0 errors’ when trying to play things in totem’s mozilla playing.The title of the box was poorly labelled ‘Could not play fd://0’ (this should be fixable in totem to show the URL instead), but the text of the dialog box clearly stated something along the lines of ‘You do not have a decoder installed to handle this file’ and put me on the right track. However, it doesn’t say what format or plugins to look for, which sucks. There’s been some discussions in the past about building a mechanism for telling the user exactly which plugin/package they should look for, but noone has ever built it.
    • software – totem & rhythmbox are the main multimedia apps I use. Both were installed, but the totem-gstreamer-firefox-plugin wasn’t for some reason. Simple enough to install that.
    • ALSA set itself up nicely with DMIX, so no worries about sharing the sound card between applications. Unfortunately, that tends to cause shuddery video playback in GStreamer and (to a lesser extent) xine for reasons that are best explained in another post.
  • Hibernation:
    • Encouragingly, worked the first time I tried it – immediately after installing and logging in, before doing any configuration or anything.
    • Sadly, failed in the old way an hour later after I’d installed stuff, copied some pieces of my home directory back across, and had a few apps running it failed in the same way as before the reinstall: by getting as far through the hibernate as ‘turn the screen off’ and then sitting there flashing the hard-disk-access light for the next 10 minutes until I switch it off via the power button.
    • I really wish I knew how to fix it – the hard disk in this machine is so slow it takes a good 4-5 minutes to boot up, so I hate turning it off, and carrying it around still turned on isn’t much better.

Pamplona

We bought ourselves some bus tickets to Pamplona this morning.

We’ll be heading down late Friday night, partying all day and then coming back to Barcelona at 1am Sunday morning – should be a pretty busy day, yay!

Guadec roundup

Had a ball of a time at Guadec last week. It was nice and close to Barcelona, which made a nice change – traditionally it’s been held in the opposite hemisphere from me and I haven’t been able to get there.

Got to meet a bucket-load of interesting people that have previously just been hackergotchis on various planets, or nicks on IRC channels.

Socially, it was an absolute blast.

Technologically, wonderful: loads of great hacks being shown off, and heaps of in-depth technical talks.

Business-wise, it was nice to feel love from the community about the things we’re trying to do with multimedia at Fluendo, and great to see everyone wearing our hats 🙂

The Elisa guys did some very nice demos, and for anyone that missed it, all the source code for Elisa is available in Subversion. Check out the project page for more details.

Edward gave a nice lightning talk showing off some of the things he’s been doing in Pitivi. It came off nicely, but I think made it hard for the audience to see just how cool it was – appending video files in multiple source formats and resolutions to a timeline and then scrubbing through them in realtime like it was nothing really shows how much polish he’s added to GStreamer and Gnonlin since last year. I know the Jokosher guys certainly appreciate it, since it’s made things considerably easier for them.

Andy and Wim gave a talk on some new things in GStreamer 0.10, including a neat ~20 lines-of-python demo of distributed synchronised playback using GStreamer’s network clock implementation.

It was also nice to meet a bunch of new (to me) people that are doing fabulous things with GStreamer 0.10: MDK (from Diva), the Jokosher gang, Nokia N770 people, Opened-Hand, Iain Holmes (from Marlin), MacSlow, Burger, Zeenix, and the Elisa guys – even though they work for Fluendo too, this was the first time I actually got to meet Phil and Loic. And of course, Bastien and Tim – always good guys to hang out with.

We (the GStreamer team) have worked really hard to make GStreamer 0.10 as good as it is, and it’s nice to see people reaping the benefit of our collective labour.

I found Jim Getty’s talk on the OLPC project quite exciting – a project that really has a chance to make a big difference to the world. We took possession of one of the dev boards, and I’m looking forward to seeing what we can do to help them in the multimedia area.

We had a good audio BOF on Friday afternoon, talking about Pulseaudio and how it can be more than a better-ESD for the Gnome desktop. Monty from xiph.org talked about writing a FUSD based wrapper for OSS, and possibly even ALSA devices. This would replace the existing system of LD_PRELOAD hacking using padsp and esddsp, and make pulseaudio a serious candidate for The Linux Desktop Audio Solution. I’m really keen to see whether we can make it fly, since the Linux Audio swamp has needed draining since forever.

I need to write up a summary of some of the things I’ve been hacking on lately, but I might leave that for another night. I’m also looking forward to putting in some GStreamer related talk proposals for LCA next year.

Recent GStreamer releases (Attention: Packagers)

I found a small bug in the GStreamer build system, introduced at the start of April, which exposes a bug in the registry cache.

The end result, sadly, is that applications based on GStreamer end up opening a bunch of plugins (sometimes ALL of them) every time they start.

Neatly, the problem only on happens in packaged builds where a –with-package-name or –with-package-origin is being passed to configure, so there was never any chance we’d see it in CVS.

Packagers of various distros that have built packages for GStreamer in the last 6 weeks should take a look at:

http://bugzilla.gnome.org/show_bug.cgi?id=341479