Now that I've migrated from a first-generation MacBook to a first-generation MacBook Air as my primary day-to-day system, it's probably time to retire the long-running 'Living With Apple's MacBook' post series...in favor of an 'Air'y successor ;-) To begin this first post (of, judging from past history, many), I've got a follow-up on my earlier-today commentary regarding adding single-key forward-delete capability to the MacBook Air's keyboard. A bit of Googling led me to an open-source program called DoubleCommand that perfectly addressed my issue by enabling me to redefine the right option key. Granted, the forward-delete functionality spans not only virtual machines but also the foundation 'Leopard' operating system, since DoubleCommand is an OS X application, but that's fine with me. Conversely, my virtualized Windows XP mouse cursor just freaked out again...back to windowed Fusion mode while I wait for v2.02, I guess...

A weird system glitch that I periodically encounter involves the Samsung HS081HA 80GB 1.8" hard drive. It'll randomly emit an odd noise, which I believe occurs when the platter spins down and the head parks, and which another MacBook Air owner captured on video (and audio):

The drive seems to work fine, but I still find the squeal disconcerting. It's ironic given that Samsung's own product documentation (PDF) notes, "Noise is among the biggest issues for HDDs in portable audio/video applications. No one wants to hear the clicking sounds of the HDD while listening to music or recording videos. With its innovative grooved cover design, the 1.8” HDD prevents acoustic noise from leaking out. In addition, Samsung's SilentSeek™ technology controls the actuator and thus reduces noise." Maybe I'll migrate to that Samsung SSD sooner versus later...

Now to the main topics of this particular post. One day last week while I was busily cleaning up old emails and RSS feed posts in Outlook 2000 running under VMware Fusion, my Windows XP virtual machine abruptly became molasses-slow. At first I thought I had a Fusion-specific problem, but everything else I had running was crawling, too, and suspending the VM didn't bring relief. I launched Activity Monitor and noticed that process kernel_task was consuming more than an entire core's worth of resources (i.e. >100% CPU, since Activity Monitor assumes a single-core CPU).

A bit more Googling informed me that I was encountering a well-documented CPU overheating issue with this system. As review, recall that the first-generation MacBook Air mates a Santa Rosa core logic chipset to a specially packaged, low-voltage version of Intel's 65nm Merom CPU, whereas the just-introduced second-generation MacBook Air uses a follow-on 45nm Penryn microprocessor paired with an Nvidia chipset. Initial Merom-based MacBook Air firmware releases would, when the CPU got too hot due to lengthy heavy use (a common bane of airflow-deficient ultralight laptops), shut down one of the two CPU cores...thereby severely throttling performance.

In early April, Apple released an EFI (extensible firmware interface) update for the system, which seems to suppress core shutdowns but doesn't seem to make much (if any) practical improvement in usability under hot-CPU conditions. Instead of a brute-force core neuter, cyberspace gossip suggests that the OS X microkernel instead starts tossing abundant idle instructions at the CPU, thereby enabling it to cool down...but in the process grinding to a halt any useful work it was previously tackling. As mentioned two paragraphs ago, I've periodically noticed kernel_task-induced slowdowns when I'm asking virtualized Windows XP (therefore VMware Fusion) to do 'heavy lifting'; I've also noticed them, for example, when I try to play back YouTube- or Hulu-sourced video clips within Firefox natively running in OS X.

The latter glitch is the result of the Intel integrated graphics core's limited codec support for hardware-accelerating video processing operations, thereby throwing the bulk of the decode task back at the MacBook Air's dual-core 1.6 GHz CPU. Many of the Internet discourses I found recommended the use of Magnus Lundholm's $10 CoolBook utility (here's one of the most indepth discussions I stumbled across), and after a few days' worth of experimentation with CoolBook I wholeheartedly concur with others' counsel. Here are the default operating voltages for the MacBook Air's Merom CPU at various throttled-or-not clock speeds:

CoolBook leverages a technique long used by CPU over-clock enthusiasts, that of lowering the processor's core voltage in order to decrease power consumption at a given clock speed. For the over-clock crowd, the end result of undervolting is (assuming a non-clock-locked CPU in-hand) the ability to run at higher-than-spec'd speeds without triggering thermal shutdown sensors. For CoolBook, conversely, the objective isn't to clock the MacBook Air's CPU any faster than its spec'd 1.6 GHz...instead it's to lower the amount of power consumed by (and therefore the amount of heat coming off) the processor at a given clock speed. After much experimentation with CPUTest and other burn-in resources, it appears that the CPU in my particular system can stably run at 0.9V across its entire frequency range, as the following screenshots prove:

If I wanted to, I could even eliminate (for example) the fastest clock setting (or few) for non-AC-adapter operation, leading to incremental battery life at the expense of peak speed. And, by powering the CPU with a core voltage 0.2375V below the Apple-defined default at 1.6 GHz, I haven't yet encountered another kernel_task-induced slowdown in spite of conscious attempts on my part to induce such a scenario. Note that your mileage may be vastly different...while one CPU might be able to reliably run at substantial under-voltage levels, another one might fail at anything below nominal voltages. You'll need to iteratively experiment, as I did, to discover the optimum clock-and-voltage pairings for your particular piece of hardware.

With reduced power consumption comes longer battery life, along with a delay in the system fan ramp up from its 2500 RPM initial speed to the highly audible 6200 RPM peak rate. But inevitably, eventually, the fan crescendos at top speed, and in Apple's infinite wisdom the firmware then tends to keep the fan screaming at 6200 RPM even after the processor subsequently cools down. Cue smcFanControl2, another enthusiast-developed utility, this one particularly intended to provide user control of fan speeds. The program GUI enables you to set a minimum fan speed at or above the Apple firmware-defined default. I've got it set at 3810 RPM, for example, which might seem counter-intuitive at first glance. But the incremental 1310 RPM beyond the default minimum setting still isn't audible, it makes a negligible negative impact on battery life, and by keeping the system cooler than the default it substantially delays the onset of perceptible fan RPMs.

Delays...but doesn't eliminate. However, as some courageous (or depending on your perspective, foolhardy) souls subsequently discovered, smcFanControl2 also lets you limit the maximum fan speed. By developer conscious intent, this particular feature is only accessible via the Terminal command line, and overrides also don't survive system sleep and reboot cycles (though it's possible to craft a script to surmount these particular speed bumps). And, given that running semiconductor devices (not to mention HDDs) beyond their spec'd maximum operating temperatures is a 'great' way to dramatically shorten their operating lives, I think I'll stick with 6200 RPM audible fan rates.

p.s...after reading all this, you might wonder if I have any regrets about not waiting for a second-generation MacBook Air with more robust CPU, Nvidia graphics subsystem, etc. The short answer; no way. Consider, first, that I only paid a bit above $800 for this system after rebates. And about those Nvidia graphics...Apple seems to be having some serious issues with the Geforce 9400M, in spite of rumoured vigorous cherry-picking on Nvidia's part, and it's not yet clear to what degree the problems can be fixed (or worked around) in software versus being fundamental hardware flaws. You would have thought by now that Apple would have learned its lesson about Nvidia's thermal shortcomings...