Posted by Cary Chin on August 12, 2010
I like mazes and puzzles. And I like algorithms. When I was young, I discovered that most mazes could be solved almost trivially by applying a simple divide-and-conquer approach: solve the problem from both ends. I would start with a pencil in each hand, one at the beginning and one at the end of the maze. Then all you really have to do is draw until the lines cross. I didn’t realize it at the time, but the effect was to halve the depth of the search tree – two trees of depth N/2 generally works out better (way better!) than one tree of depth N, especially when you can apply some high-level guidance and heuristics, like a kid staring at a maze.
As we all have been thinking in recent years about the problems of power dissipation in devices, chips, SoC’s and systems, I thought it would be interesting to start to look at the problem at the highest level – that of the end product. Beyond the system level, above the system software, and even above the application software, the ultimate challenge is to be able to analyze and optimize power at the product level.
You must be thinking, “Is he nuts? We’re not even close to the point of completely understanding power behavior through the system level, let alone interactions and dependencies through the software stack.” So what is this all about? Simple. I’m just suggesting to tackle the problem from the finish of the maze. I’d like to know, starting on the finished product end, how much power is consumed in particular modules, for particular operations.
To get started, I’ve lined up my trusty set of iOS devices: iPad wifi, iPhone 4, iPhone 3GS, and iPhone 3G. I’ve nixed my iPod Touch because it doesn’t have enough free memory to load our test vehicle. As a measuring stick, I’m using a digital copy of the movie Star Trek (hey, if you’re gonna watch a movie 100 times or so, it might as well be a good one). To develop a baseline, I fully charged all of the devices, and then played Star Trek as many times as I could until each device shut down. This was done in a “max battery” configuration: airplane mode, with wifi, bluetooth, and location services all off, brightness and sound at minimum. I suppose you could use this setup as a movie player in a very dark airplane (if you knew how to read lips)! It might not be realistic, but the experiment yielded very interesting results. All of the devices performed much better than I expected. The iPad played Star Trek (2 hours, 6 minutes, 46 seconds) 7 and ¾ times before draining its battery completely! That’s over 16 hours of video playback! Similarly, the iPhone 4 had a Star Trek score of 4.75, and the 3GS around 4.1. Both were over 8 hours of video playback. The iPhone 3G only lasted through 1.75 Star Treks, but it’s also the oldest device (over 2 years), so its battery capacity is probably down by at least 30-40% (no I don’t know how many “charge cycles” it’s been through).
After all of those millions of recall petitions, email campaigns, blogs, and general nasty comments about battery life, is it possible that we’ve all got an 8+ hour portable movie player in our pockets and purses? Yep. So why is it that my original iPhone couldn’t last through the morning at work, with subsequent versions only marginally better? What’s using all that juice? And wouldn’t it be cool if we could tell during the design phase of the phone that this would be a problem?
We’ll answer these questions starting next time. Let’s start walking back from the end of the maze.