You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
Does Android throttle the CPU when the battery gets low?
- Thread starter Logan F
- Start date
Courtandrach
New member
I'll preface this with saying I haven't glanced at the linux/drivers/power directory of the Android source, but here's how it works based on what I've read and the relation to Linux:
There are 2 power states. A "suspend" sleep, which is the case of when you hit the power button, and there's the runtime power management. The runtime power management is fully dependent on the the hardware drivers. I'd guess based on my prior OMAP experience is that most processors using android follows ondemand scaling. So if more power is needed the CPU will kick into full gear, whereas if you're just sitting there, it should scale down and waste very little CPU.
I highly doubt that as your battery is depleted that the runtime power management scales differently. Although, I have with Linux servers setup similar profiles. If a server went on UPS I'd scale down the CPU and fan speeds. For simplicity, I doubt Android does any of that. It'd be a complex test case.
EDIT: Also there are usually set levels of ondemand (think low medium high, or sometimes just low and high, etc).
As far as linpack is concerned, it's hard to say. I have no idea where they're grabbing the CPU stats from, and no idea about the drivers in use on the platform...
There are 2 power states. A "suspend" sleep, which is the case of when you hit the power button, and there's the runtime power management. The runtime power management is fully dependent on the the hardware drivers. I'd guess based on my prior OMAP experience is that most processors using android follows ondemand scaling. So if more power is needed the CPU will kick into full gear, whereas if you're just sitting there, it should scale down and waste very little CPU.
I highly doubt that as your battery is depleted that the runtime power management scales differently. Although, I have with Linux servers setup similar profiles. If a server went on UPS I'd scale down the CPU and fan speeds. For simplicity, I doubt Android does any of that. It'd be a complex test case.
EDIT: Also there are usually set levels of ondemand (think low medium high, or sometimes just low and high, etc).
As far as linpack is concerned, it's hard to say. I have no idea where they're grabbing the CPU stats from, and no idea about the drivers in use on the platform...
"get over it"
New member
Haha, no problemo..
To sum it up: It most likely doesn't throttle down as the battery drains, because it's already super efficient in how it uses the power by using ondemand power settings (only use it if you need it).
To sum it up: It most likely doesn't throttle down as the battery drains, because it's already super efficient in how it uses the power by using ondemand power settings (only use it if you need it).
There would be very little point.
Consider what happens when (on Android 1.6 or above) you press Menu -> Settings -> About phone -> Battery use. What's the top hardware item on the list? WiFi? Display? My point is, Display is nearly always top of the list or 2nd top. It uses a ton of power.
So, lets say you're running an app, and that app needs to do some processing which would normally take a second at full processor speed, but the processor is throttled to 1/10th it's speed. What happens? Well, it takes 10 seconds to process the same code.
Now, let's assume the processor uses 1/10th the power when running 1/10th the speed (it wouldn't, of course, as its internal RAM and other components will require the same power no matter what state the other parts of the processor are in - it would use much more than 1/10th)... that means it takes the same amount of power to process the same stuff, only it does it more slowly. So either way the CPU uses the same power after 10 seconds is up.
But...
Full speed: 1 second of display.
1/10th speed: 10 seconds of display.
So all you've done is use a load more power by having the screen on for longer and the user got fed up waiting.
Of course this only applies when the user is waiting on the CPU. A lot of the time the CPU is waiting on I/O (network, SD card, user input, etc), or the screen is off and it's doing stuff in the background.
Consider what happens when (on Android 1.6 or above) you press Menu -> Settings -> About phone -> Battery use. What's the top hardware item on the list? WiFi? Display? My point is, Display is nearly always top of the list or 2nd top. It uses a ton of power.
So, lets say you're running an app, and that app needs to do some processing which would normally take a second at full processor speed, but the processor is throttled to 1/10th it's speed. What happens? Well, it takes 10 seconds to process the same code.
Now, let's assume the processor uses 1/10th the power when running 1/10th the speed (it wouldn't, of course, as its internal RAM and other components will require the same power no matter what state the other parts of the processor are in - it would use much more than 1/10th)... that means it takes the same amount of power to process the same stuff, only it does it more slowly. So either way the CPU uses the same power after 10 seconds is up.
But...
Full speed: 1 second of display.
1/10th speed: 10 seconds of display.
So all you've done is use a load more power by having the screen on for longer and the user got fed up waiting.
Of course this only applies when the user is waiting on the CPU. A lot of the time the CPU is waiting on I/O (network, SD card, user input, etc), or the screen is off and it's doing stuff in the background.
Extorian's point is dead on. There's nothing to gain, in fact, you might waste more power by implementing something like that. The only thing I've done it on is servers, and those were running 100% CPU constantly. So if the backup power came on we'd throttle it down significantly. The reason being is we wanted to milk the UPS battery for as long as possible but still allow our process queues to stack up until full power came back on. In android's case we're ondemand and 95% of the time running in the low state. So we gain nothing.
jassycute23
New member
Exactly - and servers are different as they don't have displays on all the time - most people using them are remote. So throttling down servers can save power, not that anyone would care unless running on UPS.