Mac OS X and Battery Life

In a recent article, The Disaster-Free Upgrade to Mac OS X, I mentioned my disappointment in the power management capabilities of Mac OS X 10.0.1. Things seem to have improved a bit with releases 10.0.2 and 10.0.3, but there still seems to be room for improvement.

I received a note from Peter Fraterdeus, who is a longtime Mac user, developer, and Linux webmaster, saying that he had some insights into the battery drain problem on laptops running early versions of Mac OS X. Peter ran some tests and was willing to share his discoveries with the O'Reilly audience. So, take it away Peter ...

Keep it Cool

In Derrick's recent article about how to upgrade your system to Mac OS X, one of his "bow-wows" about OS X was: "My battery drains faster! I hate that! My previously 4-hour PowerBook battery now only lasts about two and a half hours."

I'd like to share here a few pointers and tips to help PowerBook users understand some of the concerns specific to the portables running OS X.

Of course, you should make a point of checking Apple's Mac OS X site regularly, or allow your Software Update panel to install the latest updates (as of this writing, we're at 10.0.3).

I expect that Derrick will have less of a problem after the first two updates are installed. The battery life was hit very badly by instability in NetInfo. Although it seemed to be fine when you'd first boot up, after switching to a different Location (Network Preference or under the Apple Menu), it would spend all available processor cycles trying to reconnect to a missing server, creating a power-hungry process and a far-hotter processor. [1].

However, even through NetInfo is now less greedy, it's still not unusual to have the processor running with the pedal to the metal, not only draining the battery and overheating the CPU, but also contributing to the perception that the system is less responsive than it should be. (Desktop machines will, of course, be affected by this too!)

I've put the little CPU Monitor floating window up in the top right of my screen. This lets me note right away if a process is sucking more than its share of power. It doesn't tell me which process is doing the sucking, however. For this, we'll use some of our wizard tools and look under the hood for the culprits!

The Extended Display shows the relative use by System vs. User processes. In this case, you can see that the User processes are absorbing the entire remaining horsepower of the CPU.

As I was reading one of my (excessive) Mac OS mailing lists late at night, I noticed a repeating disk access about happening about once a second. There are a couple of methods to track down what's causing this. It's not likely that a recurring access is a normal situation, and certainly not if your Apple notebook is not plugged in.

This kind of thing will cause your battery to evaporate like brandy in a hot saucepan! By watching the current processes in the Terminal using top -u, you can see exactly which process is firing up (the -u option sorts the list by processor usage. Try man top for more details).

In this case, I can see the LaunchCFMA process is popping up at the same time the disk is being accessed. However, this LaunchCFMApp is a system process that is used by other applications to start a Carbon application that uses the Code Fragment Manager API.

The command ps auwww (pshawww?) shows the current snapshot of the process list. The extra ws force the entire path of the process to show instead of being truncated at the window width.

Here's something ...

I noted that there was a Timbuktu Extension that seemed to keep changing its process number every time the disk access happened. There was also a Timbuktu Extension which retained its process ID. The one that's consistent is the parent process, and it was continually trying to launch the child process, which failed (for whatever reason). Thus, the incrementing process ID, as the parent tried over and over to launch, the system assigned a new PID, slightly higher than the last one used.

Using another wizard trick, I'll let the grep command find any mention of Timbuktu in the output from the ps command, like this (the vertical bar -- | -- allows me to "pipe" the output of the ps directly to grep... line spaces added for clarity) :

[localhost:/Users/peterf] root# ps axuwww | grep 'Timbuktu'

root 2814 64.8 0.5 3484 1320 ?? R 0:01.06
/System/Library/Frameworks/Carbon.framework/Versions/A/Support/LaunchCFMApp
/Users/peterf/Applications/Timbuktu Pro X/Timbuktu Pro
X.app/Contents/SharedSupport/Timbuktu Extension

root 321 0.0 0.0 1248 64 ?? Ss 0:02.57
/Users/peterf/Applications/Timbuktu Pro X/Timbuktu Pro
X.app/Contents/SharedSupport/Host Relauncher
/System/Library/Frameworks/Carbon.framework/Versions/A
/Support/LaunchCFMApp
/Users/peterf/Applications/Timbuktu Pro X/Timbuktu Pro
X.app/Contents/SharedSupport/Timbuktu Extension

root 2816 0.0 0.0 5724 0 std R 0:00.00 grep Timbuktu

[localhost:/Users/peterf] root# ps axuwww | grep 'Timbuktu'

root 2824 80.0 0.5 3484 1324 ?? R 0:01.26
/System/Library/Frameworks/Carbon.framework/Versions
/A/Support/LaunchCFMApp
/Users/peterf/Applications/Timbuktu Pro X/Timbuktu Pro
X.app/Contents/SharedSupport/Timbuktu Extension

root 321 0.0 0.0 1248 60 ?? Ss 0:02.57
/Users/peterf/Applications/Timbuktu Pro X/Timbuktu Pro
X.app/Contents/SharedSupport/Host Relauncher
/System/Library/Frameworks/Carbon.framework/Versions
/A/Support/LaunchCFMApp
/Users/peterf/Applications/Timbuktu Pro X/Timbuktu Pro
X.app/Contents/SharedSupport/Timbuktu Extension

root 2826 0.0 0.0 5724 72 std RV 0:00.00 grep Timbuktu

You can see exactly what's going on here:

The "Host Relauncher" with process ID (PID) number 321 is calling LaunchCFMApp to kick-start the Timbuktu Extension. For some reason, it's not starting, which leads to this endless looping. Here we see PID 2814 in the first listing, and a few seconds later, PID 2824.

"top" shows this, before:

Processes: 63 total, 3 running, 60 sleeping... 192 threads 22:49:44
Load Avg: 1.90, 1.61, 1.63 CPU usage: 57.1% user, 23.1% sys, 19.7% idle

To stop this, I killed the parent process with a TERM signal:

sudo kill -TERM 321

Then, the disk access stops, and "top" shows:

Processes: 61 total, 2 running, 59 sleeping... 188 threads 22:50:39
Load Avg: 0.31, 0.70, 0.80 CPU usage: 18.8% user, 23.4% sys, 57.8% idle

Ahhh. Peace and quiet...and a cooler, happier laptop.

Logrolling

Another processor drain I've found is that certain "Classic" apps are showing a modal dialog. I'm not at all sure why this is causing the process to dominate, but it's just another reason that I'm impatient to have all my apps in Cocoa (the native API for OS X)!

Here's a useful debugging/optimizing tool:

sudo tail -f /var/log/system.log

The tail command will show the most recent entries in the system log, and then update the window as new entries are written to the log. This will help isolate NetInfo problems. Just open a fresh Terminal window and leave tail running as you go about your work. You'll notice entries being written to the log as certain types of system events take place.

A variation on this might be useful as well:

sudo tail /var/log/*.log

This will dump the last few lines of every current log file.

Speaking of logs, they are automatically compressed and archived by the system. If you want to examine an archived log, you can do something like:

zcat /var/log/system.log.0.gz | grep 'sudo'

(Do this to see how many times the sudo command has been used ... )

You can dispose of archived logs when they are taking up too much room. rm -i /var/log/*.[7-9].gz will delete all the compressed files with suffixes between 7 and 9 in /var/log/ (the -i ("interactive") option will ask you to confirm each deletion).

I'm very excited to have a full POSIX-compliant OS running on my awesome Titanium PowerBook G4. I hope this article has demonstrated some useful tools to help you get the most out of your Mac.

If there's enough interest, I'll be back to offer some more insights into the brave new world of Mac OS X! Meanwhile, stay cool!

About Peter Fraterdeus

Peter (peterf@mac.com) bought a 128K Mac in October of 1984. He's very sorry to say that it was stolen some time later. He got his first e-mail account in 1985.

He's also a web partner at www.midsummernightstamps.com, a fine-art rubberstamp publisher (check it out!).

Derrick Story is the author of The Photoshop CS4 Companion for Photographers, The Digital Photography Companion, and Digital Photography Hacks, and coauthor of iPhoto: The Missing Manual, with David Pogue. You can follow him on Twitter or visit www.thedigitalstory.com.

Read more Mac Dev News Roundup columns.

Return to the Mac DevCenter.

Copyright © 2009 O'Reilly Media, Inc.