Aug 6 2006, 12:46 PM
"There's been a fair amount of interest in an offhand comment I made recently about saving a lot of standby time by making an LED blink less frequently. So let's spend some time talking about what burns power on your Smartphone. Hopefully this will give you an understanding of where that battery power went and maybe help you figure out how to squeeze a little more life out of your devices."
Aug 6 2006, 03:50 PM
Main Processor, Phone Processor, Lights, Camera, Wifi, Bluetooth, Screens, Audio, RTC, VRAM-Support (To prevent need to full reboot), Anything with a current really. . .
Aug 6 2006, 06:38 PM
he does make some good points but i havent seen many devices that have LEDs on when in standby (except when i miss a call or sms on my phone, but i consider that worth it
thier is a trick or two i can use to minimise the power loss of LEDs. for exapmle if they have a 0.7v drop then i can attach 5 in series, this means they all get lit (at the same time as well, think keyboard backlight) but instead of consumming 2mA each the entire lot of LED's consume 2mA in total
its a nice trick for lighting large areas, another one is to drive them with a PWM signal, you pump x2 thier rated power throgh them for half the time really quicly. due to the persistance of vision our eyes have it apears brighter than driving it with DC however you use the same amount of power as one that was just connected to the supply voltage
of course these are tricks i have learnt from programming 8bit micro controllers where the power budget for the circuit might be only 1mA and the device has to be sleeping for 90% of the time to do that
in standby the most power hungry device will be the DRAM, when running it will be the CPU, the cpu will consume so much power compared to an LED that turning one on or off will have a negligable affect on the total battery life, the same is true for the DRAM however the LED will have a much larger affect (i would take a guess and say you its impact on battery life mesured in minutes lost would be about4-5 times greater, going out on a limb i would say you would lose 20mins standby)
keep in mind i expect standby battery life to at least one day, now for the real kicker: we can cut standy power consumption in half by fidling with the ram chips. all we need to do is defragment the memory and put it all towards the begining of one chip. then turn the rest of the memory cells "off". we could in fart leave the memory fragmented and turn off the holes but compacting would be more effective. however i dont think linux has this capability or if it is worth pursuing over just turning off the holes in memory
one of the design choices was to have 2 16 bit memory chips in parallel to decrease the complexity (basically it means one less chip select line which is alot more important than it sounds) if we used 2 32bit chips and had them one after the other then it is quiet posible we could turn off an entire unused chip which should have huge power savings
CPU wise, i wont to get dynamic CPU speed changing into the kernel asap, in fact if i did handel the money for the project i would add a $10 development fee to the final price and use it to fund a bounty on this feature, making the chip go idle when nothing is happeninng is nice in terms of power but nothing beats changing the cpu frequency. (i use to listen to mp3 on my x30 by clocking the cpu to less than 100Mhz, it gave me an extra hour of batter life, leaving it at 624Mhz and doing nothing would only give me 2.5 hours (normal run time was 4 hours))
next trick we can do is called dynamic power gating, its the same trick OZ isusing for the sound chip, if you are not using a part of the processor turn the power to that part off. in practice it can be hard to do and requires keeping track of all refrences to the hardware (some bieng easier than others to manage)
in the end however i cant stop you running wifi bluetooth and the cpu processor at full speed all the time while the device is doing nothing, that is the biggist killer of battery life no matter how much i try and save. there are cpu speed mangment programs and some are better than others but perhaps we need a power managment program in user space the dynamically tweaks things such as transmit power acording to policies we have set
cpufreqd is a good one, ever had dynamic cpu frey turned on and let the kernel handel it? i find when i watch a moive the cpu toggles between to fast and too slow. with cpufreqd i can apply a policy that when a certin program (mplayer) is started, to jack up the cpu speed or chang the cpu speeds it toggles between (say a 50% max speed and 1000% max speed instead of 0% to 100%)
the phone is important however it consumes the most power when reciving and transmitting, all the other times it is idle unless searching for a cell phone tower (that chews throgh power). clever hardware tricks can fix this like proper impedence matching (if they are not matched then part of the power is wasted) even with proper impedence matching only half of the power we try to dump into the antenna will actually be used (correct me if i am wrong)
and btw what is VRAM, for going idle i was just going to switch the dram to its low power state like all the other PDAs
Aug 7 2006, 07:21 AM
Linux kernel does do some memory defragmentation, but likely not enough. Build the capability at the hardware level, and have that on a todo list, I'm sure that somebody has already tried to do this at some point. Is it in the plans to have the code and static memory portions of the program to be left in ROM? If so, does that require changes to the swapping code of the kernel?
Aug 7 2006, 03:06 PM
i belive that some of the software suspend patches might have this feature built in
software suspend would be great for us as we could then put the device into a deeper sleep by turning off the sdram chips
you could have the kernel and program stuff in rom and it has been discused (look for exectue in place or XIP). at the moment that is awhile off however i intend to look into again in the futre