[SOLVED] Pandora Lost Charge Overnight


fusion_power said:
Very nice and still very interesting, especialy mp3 playing. :)

But if underclocking has no effect, why did Pandora clock to 14MHz when "power saving" mode is enabled? ^^""

See below? Possibly optimism about the state of progress towards that target?

fusion_power said:
I hope, a new Kernel comes soon for the Pandora. I've read that there could be alot HW stuff enabled with, if we are lucky.

Sounds like it is at the top of the list.
 
Last edited by a moderator:
fusion_power said:
But if underclocking has no effect, why did Pandora clock to 14MHz when "power saving" mode is enabled? ^^""
Because TI said that lower clock speeds == better battery time, and OPT blindly accepted this because it makes sense.
Only now we see empirical evidence suggesting that that is not the case.
 
Last edited by a moderator:
WizardStan said:
Because TI said that lower clock speeds == better battery time, and OPT blindly accepted this because it makes sense.
Only now we see empirical evidence suggesting that that is not the case.
With the current kernel. I found some stuff proposed by TI to go into the kernel on a mailing list dated a couple of weeks ago (which doesn't help us today, but looks like it might understand all of the voltage domains in the omap platform, so might not need any extra config).
 
Last edited by a moderator:
WizardStan said:
fusion_power said:
But if underclocking has no effect, why did Pandora clock to 14MHz when "power saving" mode is enabled? ^^""
Because TI said that lower clock speeds == better battery time, and OPT blindly accepted this

Did TI say that? I always thought TI pushed the OMAP as a device which intelligently scaled its CPU to save battery life without the need for overclocking.

As usua, however, I have no evidence to back up this claim :p
 
Last edited by a moderator:
Pleng said:
WizardStan said:
fusion_power said:
But if underclocking has no effect, why did Pandora clock to 14MHz when "power saving" mode is enabled? ^^""
Because TI said that lower clock speeds == better battery time, and OPT blindly accepted this

Did TI say that? I always thought TI pushed the OMAP as a device which intelligently scaled its CPU to save battery life without the need for overclocking.

As usua, however, I have no evidence to back up this claim :p
There is a trade off between responsiveness and power saving, it may be that at 14MHz the governor would request higher speeds fairly frequently (even if the background CPU load is only 50% or so). I can't imagine that the transition between operating states is too efficient either, spinning up clocks and waiting for them to lock, etc. (no evidence to support it, but underclocking has always been assumed to be good for power - and only with a full system, handling timers and stuff, is is possible to test)
 
Last edited by a moderator:
Pleng said:
WizardStan said:
fusion_power said:
But if underclocking has no effect, why did Pandora clock to 14MHz when "power saving" mode is enabled? ^^""
Because TI said that lower clock speeds == better battery time, and OPT blindly accepted this

Did TI say that? I always thought TI pushed the OMAP as a device which intelligently scaled its CPU to save battery life without the need for overclocking.

As usua, however, I have no evidence to back up this claim :p
It only does all this stuff if the respecitve configurations are activated in the kernel. Currently basically no powersaving options are active in the kernel. Yes, there is *huge* potential for optimizations! But all this stuff takes time.
 
Last edited by a moderator:
peca said:
I think that HF4 should set "low power" clock speed to 125 MHz or so, but not so low as 14 MHz (which seems to have no sense).
Currently, it does not change the MHz. It is trivial to modify though.
 
Last edited by a moderator:
Pleng said:
Did TI say that? I always thought TI pushed the OMAP as a device which intelligently scaled its CPU to save battery life without the need for overclocking.
Which is the exact same as saying "lower clock speed saves battery".
Whether it is scaled automatically or manually set, it should be the same. What we're seeing is that lower clock does not appear to affect the power usage in any appreciable way.
 
Last edited by a moderator:
In fact scaling CPU clock is only beneficial together with voltage scaling. Lowering the clock means you can lower the voltage as well(it won't crash) and _that_ saves battery life. In the current scenario with the CPU at 14MHz at OPP3 it's complete nonsense and contra productive. Besides often you don't even save battery life with activated dynamic scaling. It might prevent a misbehaving process from draining the battery, but it also hampers performance which will drain battery more than necessary as well.
 
mali said:
In fact scaling CPU clock is only beneficial together with voltage scaling. Lowering the clock means you can lower the voltage as well(it won't crash) and _that_ saves battery life.
So what we need from the "low power" mode is for it to set the clock to 125Mhz and the voltage to OPP1. 125Mhz being the maximum clock speed recommend for the lowest voltage rating OPP1. Automatic scaling would be nice, but this would be a pretty good stop-gap I think.
Using the power estimation spreadsheet the power usage is almost halved going from OPP3 to OPP1.
 
Last edited by a moderator:
WizardStan said:
mali said:
Using the power estimation spreadsheet the power usage is almost halved going from OPP3 to OPP1.

Now that's my kind of low power mode, especially if we can combine it with turning the screen off rather than just the backlight(see thread in software hacking... not possible just yet though)! Whats more that's still enough CPU power to play mp3s is it not? I think when we get something like this it should be configured by default to kick in when the screen gets shut.
 
Last edited by a moderator:
Pleng said:
Now that's my kind of low power mode, especially if we can combine it with turning the screen off rather than just the backlight(see thread in software hacking... not possible just yet though)! Whats more that's still enough CPU power to play mp3s is it not? I think when we get something like this it should be configured by default to kick in when the screen gets shut.

From that "Turn the screen off" thread in the software hacking forum
tsh said:
Screen Blank : 130mA (which comes to 30 hours, if the instantaneous value is to be believed)
If cutting the CPU to OPP1 can shave another 50mA off, that'd push the battery to 50 hours with the CPU running at 125Mhz which is definitely enough for MP3 playback.
Think about it: the Pandora had a projected max music playback time of 100 hours with very special code doing almost magical things with just the DSP. Everyone knew it would never actually happen, but it was nice to dream. We're looking at a theoretical 50 hours without really doing anything special: no new and magic code, no special CPUless mode; just cranking the thing way way down and running a regular MP3 player. What kind of life are people getting out of their iPods these days?
 
Last edited by a moderator:
Well, the average life on my iPod nano (current version, as far as I'm aware) is about sixteen to eighteen hours, if that helps. I only need to charge it once a week or so, given my usage patterns.

I can easily see my Pandora displacing it more than it already has, if that comes to pass. :p
 
WizardStan said:
Pleng said:
Now that's my kind of low power mode, especially if we can combine it with turning the screen off rather than just the backlight(see thread in software hacking... not possible just yet though)! Whats more that's still enough CPU power to play mp3s is it not? I think when we get something like this it should be configured by default to kick in when the screen gets shut.

From that "Turn the screen off" thread in the software hacking forum
tsh said:
Screen Blank : 130mA (which comes to 30 hours, if the instantaneous value is to be believed)
If cutting the CPU to OPP1 can shave another 50mA off, that'd push the battery to 50 hours with the CPU running at 125Mhz which is definitely enough for MP3 playback.

Sorry, no. These tests with no activity do not mean the cpu is running an idle loop burning as much power as if it were active. Already I have shown playing mp3 takes the runtime down from 23 hours to 17 with the backlight off but screen on.

It will help, but don't get too excited till we can test it.
 
Last edited by a moderator:
But 50 hours would be reasonable for a full battery to last in this upgraded low-power mode whilst the Pandora is not doing anything?
 
Pleng said:
But 50 hours would be reasonable for a full battery to last in this upgraded low-power mode whilst the Pandora is not doing anything?

Yes, I thing that just opp1 might get to the 40-50 hour idle @125MHz - and it seems likely that this might 'just happen' with the latest kernel, if it is able to scale opp based on frequency (which is driven by cpu load). We still need to get the backlight and screen off switching. It may be that there is other stuff which can be shut off too, like the nubs, audio, SD (and then it starts getting messy, because how does the system know what can be shut off) I'm just wary of people making extrapolations from my numbers, particularly when I have no idea what opp1 does for power!

It might be interesting to capture if people have any use-cases other than:
* Screen off, audio streaming (wifi)
* Screen off, audio playback
* Dedicated audio playback only
* Running slow (alarm clock)
* Suspend (<5sec on)

Already, this is getting quite complex outside of the area where stuff can be self-regulating. How would the kernel cope with SD being offline, and would that rely on having some dedicated code in NAND to take over from the kernel if we went into this special optimised mp3 mode?
 
Last edited by a moderator:
tsh said:
Sorry, no. These tests with no activity do not mean the cpu is running an idle loop burning as much power as if it were active. Already I have shown playing mp3 takes the runtime down from 23 hours to 17 with the backlight off but screen on.
That seems fairly odd; CPU scaling isn't active in the kernel, so the idle process should literally be burning cycles by itself. Whether it's processing an MP3 or just a looping NOP, it should be about the same power usage. Unless the audio circuitry is taking up more power than I'd considered.
 
Last edited by a moderator:
^ I think handling idle is a completely different thing that has nothing todo with those other power saving features. Putting a processor in idle mode should be included in any Linux kernel, I suppose. I'm neither a Linux nor power saving expert, though.
 
mali said:
^ I think handling idle is a completely different thing that has nothing todo with those other power saving features. Putting a processor in idle mode should be included in any Linux kernel, I suppose. I'm neither a Linux nor power saving expert, though.
The idle process is still a process though, albeit one with a really low priority. It still does "stuff" whenever the CPU isn't doing anything else. See, a computer isn't like a brain: if part of your brain isn't active, it just isn't active. A CPU is constantly reading and executing instructions, even when "idle".
 
Last edited by a moderator:
Back
Top