Free as in speech

Kernel of the day: 2.6.22 + hrt6 patchset + mactel-linux SVN patches dated today

On the ALSA side, the config for the Sigmatel codec has been fixed (mactel-linux patch, backport from 2.6.23), so I don’t have to patch that myself anymore. Hope it’ll last, this time.

I still need to remove the POWERBOOK_ISO_KEYBOARD quirk for the Geyser IV ISO keyboard, though.

The appleir driver is gone now, so the remote control is no longer associated with an event device, and LIRC should be used instead. This means the remote control won’t work in pommed anymore, so either I’m adding a LIRC interface to pommed or I’m dropping the remote control support.

As some of you may know, I’ve been working with Linbox for the past 3 years, on and off, part time and full time, depending on the time of the year.

I won’t be working with Linbox anymore after Mandriva, which has bought Linbox back in June, decided Linbox wouldn’t go ahead in the Enterprise VoIP business.

I have been, for the past 2 years, the architect of Linbox’ VoIP solution.

This unfortunate and ill-advised decision of stopping the development of a successful product at its beginning will effectively leave the current customers out in the cold, as technical support will probably be erratic at best.

Looking back in the mirror, I’ve done a lot of things, small and big, during these 3 years:

• [2004] Developed a web-managed multi-service turn-key solution for SMBs, of which the web interface served as a prototype for the Linbox Management Console (a web-based server management framework);
• [2004] Developed the product deployment system based on FAI; still in use today, obviously updated since then;
• [2004] Wrote an AD to LDAP account (including password) sync script (customer with a special need); that resulted in me hacking OpenLDAP to port the lanman password hash support to gcrypt (Debian #245341);
• [2004] Started the hosting business;
• [2005] Started the development of the Linbox IP Telephony Solution (LIPS), based on AMPortal (now called FreePBX); ended up forking AMPortal to fix the gazillion bugs and bring it to a more usable state;
• [2005] Hacked up OpenXchange to add a click’n'dial feature to the addressbook; eventually we decided to dump OpenXchange, mainly for being an underdocumented pile of crap full of security holes (nice SQL injections, eh) and, over all, a false free software (no upgrade path, no doc, some components not released, GPL patches added to the non-free version without agreement, among other things);
• [2006] Prototyped the cluster version of the VoIP solution; this cluster version meant the solution could scale up to support thousands of users on multiple sites with redundancy and failover;
• [2006] Wrote a migration tool to migrate mails away from a FirstClass groupware to anything IMAPv4-compliant, straight out of the on-disk FirstClass storage database;
• [2007] Integrated the VoIP solution into the Linbox Management Console; after 2 years of consolidating the AMPortal web interface, I’ve finally got rid of that horrible thing;
• [2007] Integrated the cluster support infrastructure into the solution;
• [2007] Added proper faxing (over PSTN) support, at last.

And, more importantly:

• [2007] Deployed client sites without any interruption in telephone service.

I’m especially proud of that; the solution was ready for that moment, and my deployment plan proved to be the right one and flexible enough to account for everything that wasn’t ready in time (missing network infrastructure, things that had been forgotten on the client side, things that didn’t go as planned and last minute changes to accommodate users’ needs). The customers were very happy and enthusiastic with regard to their new VoIP infrastructure - so much that there was more to come.

And more to come means more business for a company that definitely needs it, and is now turning that business down.

So it’s all over now, and overall I’ve had a good time working there with the technical team. They’re all very talented, and we were 3 DDs working there - that figure is now down to 1 (yes, one, as in 3 - 2 = 1).

I’ve been able to produce a really great free (as in speech) Enterprise VoIP solution that I liked quite a lot. I had great plans for the LIPS, but couldn’t carry out much of that until it was integrated into the Linbox Management Console. In the last weeks, I’ve had confirmation that my plans were right and I was going the right way.

That’s history now, and I’m looking at what I’ll be doing next.

It’s good because I can look for a job that either involves VoIP or not; it’s good to change after a while. It sucks because looking for a job sucks.

Matthew: Thanks for the followup and the summary of the MacBook status wrt power consumption.

I’m running a 2.6.22 kernel with the hrt patchset and a set of patches including your patch to appletouch. Your patch works great and the trackpad’s behaviour is a bit better with it.

I know pretty well what the problems are on my machine, but your summary will probably be useful to a lot of people. I know some of the issues can be fixed or worked around and others cannot.

Also note that I can get something like 3h45 out of my battery under OS X with my standard workload, which is pretty good. If OS X can do that, there’s no reason Linux can’t, however bad Apple’s choices are wrt hardware.

And to make it clear once again, my previous post didn’t criticize the C-states or anything else, but the fact that I see PowerTOP being used more as a blame shifting tool than as a debugging/profiling tool. Though I maintain that UHCI suffers from a bad design, OHCI is a much, much better spec.

A couple of weeks ago, Intel has released the PowerTOP utility for Linux, a tool similar to the well known top(1) utility that can help you understand why your laptop battery runtime is as low as 1 hour. You need a tickless kernel (2.6.21 at least on i386, 2.6.22 + hrt patchset on amd64) for that to work, and timer statistics must be enabled.

This is an extremely bright marketing coup from Intel, for essentially two reasons:

• with PowerTOP, they’re now telling “hey look, the CPU is in C3 xx,x% of the time, it’s saving power!!!” and have some real hard data to back that up;
• with PowerTOP, they can also tell “hey look, the CPU cannot reach the C3 state for long enough periods because foobar is waking it up too often! That’s not the CPU’s fault!”, again with some real hard data to back that up.

In that, PowerTOP is an incredible PR spinning tool that can shift the blame away from the Intel CPU in your machine to about everything else in your machine - including software!

They’ve done extensive and intensive internal testing, which turned up some bugs and misbehaviours here and there, which is truly great.

They’re also announcing incredibly low “CPU wakeups per second” values, so low that there is no way you can reach such low values on any kind of real world setup. These numbers must be seen in the context of lab testing on otherwise idle machines.

On the “CPU wakeups per second” front, you’ll most probably see that the #1 offender is your UHCI USB controller. A UHCI USB controller produces a thousand interrupts per second, effectively waking up the CPU a thousand times per second even when nothing happens.

So, now it’s all the USB controller’s fault! Ah, wait, UHCI is an Intel spec! (UHCI is a joint effort by Intel and others, Intel being the lead) Fortunately, to be able to put the USB host controller to sleep, you need to put all the USB devices attached to it to sleep too. Here comes the (in)famous CONFIG_USB_SUSPEND kernel option introduced six or so months ago, the one that makes (made, I’ve worked around it in SANE last week-end) your scanner produce only “black scans” and prevents your printer from working properly. So now it’s all the USB devices’ fault.

Brilliant, isn’t it ?

To be honest and complete, once again, CONFIG_USB_SUSPEND exposed a lot of hardware bugs. The USB spec is probably one of the most violated spec these days (together with ACPI I’d say, though it looks like this one is improving lately).

Please don’t get me wrong: PowerTOP is a very useful tool that has its uses, the tickless kernel is of course a very important feature, and CONFIG_USB_SUSPEND would be the icing on the cake if USB devices weren’t so ignorant of the spec.

But the Intel marketing crap behind that really needs to stop. Produce better chips which consume less power, period. My PowerBook G4 could run 4h30 on battery (a machine designed 7 years ago). My Core2 Duo MacBook Pro, with a slightly bigger battery, can only run 1h40 with the same software and workload, with cpufreq enabled etc, etc. Granted, the ATI video card is a big sucker here too.

(I wrote this entry to share my thoughts on the matter, as a reaction to the many mails I’m getting about PowerTOP and the MacBooks, so as to have a reference to point people to, instead of rewriting the same things again and again.)