At this point we understand that a number of workarounds exist for the “CPU whine” noise bothering many MBP owners. What has remained unanswered, for the most part, is whether there is an impact, and if so how much, on the battery life when applying these workarounds. I have assumed that each of the workarounds takes away from battery life to some extent, but have been hard-pressed to declare with any confidence which is the “most efficient.”
Those days of uncertainty are over. At least, I’m ready to share my somewhat scientific results. So here is the experiment: “How long does it take a fully charged MacBook Pro to exhaust its battery to the point of forced sleep?” I applied this question to some of the workarounds I know of, and also to a control case: the MacBook Pro without any workaround (“with noise”).
So what did I do to make it “fairly scientific”? A few things. These are the preparations I made to the MBP, with the goal that battery drain should be as predictable as possible and therefore reveal any discrepancies caused by the underlying workaround. Since I have to wait around while this is happening, I also make no effort to achieve a particular long “control case” life:
- I configured the computer’s energy saving settings (for “Battery”) such that it should “never sleep” either the computer or display. I also unchecked the “Put the hard disks to sleep” option. These features all seem like they could add unpredictable savings to one test case while somehow not kicking in the same amount on another.
- I turned off Spotlight indexing for each of the 3 partitions on my MBP drive. Although Spotlight should only kick in when new files get added, I don’t want to take any chances that it suddenly decides to rebuild an entire index during the test.
- I turn the screen brightness up to high. Not only is this necessary for complete silence on my computer, it also helps drain the battery faster so I can get my answer.
- Before each test, I recharge the battery to 100% (and then some), and then restart the computer with the power cable attached. I then configure the particular workaround so that it is “active.” That is, the noise will not be audible during the test.
- After restarting the computer, I take care to run as little as possible. After enabling the particular workaround, I launch a small, custom application I’ve written which is designed to simply record the time it was launched and the time the computer was forced to sleep. As I launch the application, I pull the plug on the 100% charged battery, thereby starting the test.
The computer is left untouched in a corner of my office. After a few minutes the automatic screen saver kicks in, and continues to run until a couple hours later, when the power gets low enough that, despite my Energy Saver settings asking not to be put to sleep, the computer is forced to do so. Whenever I notice that the machine has actually gone to sleep, I plug the power back in and wake it up. The resulting difference in time between yanking the power and going to sleep is the “test result.” Now, I worried at first that the screen saver could be using enough CPU to essentially negate the power lost to QuietMBP’s CPU utilization technique, but the tests show that such concerns are unwarranted. QuietMBP’s impact on battery life is unarguably noticeable, despite the operation of a graphical screen saver for the bulk of the test time.
So, having hopefully described my test scenario sufficiently to make it interesting and respectable, here are my results, listed by name, brief summary, and time in hours, minutes, and seconds. The order is from “most battery life” to least, with the difference from the control case in parentheses:
- Ear Plugs – Noisy MBP control case. 2:43:36
- Single CPU – Disable the second core to minimize the noise. 2:28:04 (-15:32)
- MagicNoiseKiller – Like the Mirror widget but no Dashboard involved. 2:27:58 (-15:38)
- QuietMBP – CPU idle utilization. 2:17:26. (-26:10)
So, no doubt in my mind working around the problem costs battery life, but at least I have a bit more perspective on what I’m trading for my sanity. What’s interesting of course is that Single CPU mode appears to cost battery life: the same amount as MagicNoiseKiller! This has been anecdotally discussed on various forums, but I was curious to discover its apparent truth. My theory is that when both CPUs are running, the machine doesn’t have to work as hard to do “everyday stuff.” Probably when you disable a CPU, the remaining CPU works overtime to get the same work done, and this costs it more power.
Tests that will be less interesting but still worth trying when I get more time:
- Photo Booth Visible – Photo Booth running in an open window.
- iChat Video Hidden – iChat video preview on but minimized.
- Mirror Widget – Classic “Magic” workaround, open and close Dashboard widget.
So what is the takeaway? The MacBook Pro is flawed, but you can make rational choices about which workaround has the least impact on your lifestyle.
If I can’t exploit the full battery life of my computer without distracting noises, then it’s no “professional” computer. I still don’t know what to do – I’m intrigued by suggestions like the one from Jasmine on a previous post, who suggests that perhaps the power supply just needs to have “epoxy poured on one of the coils.” If some kind of retrofix is possible, then I’d like to have the issue addressed when I send mine in for the screen inverter buzz. If they can’t fix it I may push for a (late) return, since I find the computer to be unusable without these compromising workarounds.
Those of us suffering the noise feel pretty helpless: we spent all the money and we have to sit and question the correctness of our decision. I don’t know if there is any value in online petitions or if this one is even the most appropriate one to target my signature to, but I signed it. Maybe it will help, and I don’t think it can hurt.