yashsingh1/xdaforums huggingface dataset:
[Samsung Galaxy Nexus] Ezekeel:
You seem to take this discussion personally it seems. Do not do that.

SpeedStep exists due to historical reasons from a time processors did not have advanced power saving C-states. The only way back then was to decrease the frequency.

The NS benchmark showed that instead of having a significantly larger battery drain for the higher frequency it is about the same for both in spite of frequency difference. That does technically not qualify as race-to-idle because nothing is gained, but it shows the increased usage of the DEEP IDLE state keeps the increased power consumption due to the higher frequency at bay.

It is a matter of how efficient the DVFS works compared to the C-states. For all that I have heard to far for Intel processors the C-states are more efficient, for the Hummingbird it seems to about the same, and for the OMAP4 either DVFS is really efficient or the C-states are lacking. I was wrong simply assuming that the race-to-idle applies in general - one has to measure that for each and every device.
[Samsung Galaxy Nexus] aron7awol:
I'm not taking anything personally. I'm trying to put an end to the bad information being spread around these parts by respected kernel developers such as yourself.

All the Nexus S benchmark showed was that having the deep-idle state made the drain difference smaller than without deep-idle. Nobody is disputing that to be the case. The higher frequency was still less efficient. The benchmark was also testing a small CPU load. I've already stated the difference will be small with a small CPU load. And again, your testing methodology was flawed: you were using battery percentage.

Ok, let's talk about Intel specifically, then. Here is an Intel whitepaper: ftp://download.intel.com/design/network/papers/30117401.pdf

It specifically mentions Ohm’s Law, where P=Power, C=Capacitance, V=Voltage, and F=Frequency, to be P = C*V^2*F. Notice the quadratic growth in Figure 1.1

It's a whitepaper from the Pentium M processor in 2004. So, are you suggesting that more modern Intel processors suddenly don't follow Ohm's Law now that they have more advanced C-states?
[Samsung Galaxy Nexus] Ezekeel:
Did you even read the article you yourself linked for me. The author says himself that this equation is an oversimplification which was maybe true 10 years ago.

It takes only into account the dynamic power consumption, but for modern processors the static power consumption is a significant factor. And the only way to get rid of that is to disable parts of the chip which have to run all the time even at lowest frequency.

Or since you like equations so much, the real power consumption is

P = C * V^2 * f + X

where X is the static power consumption. And the only way to reduce that is to switch off parts of the hardware.

And for modern hardware X is no longer negligible compared to the size of the other term.

Read this:

http://chipdesignmag.com/lpd/blog/tag/static-leakage/

http://www.google.de/url?sa=t&rct=j...5MS3Dg&usg=AFQjCNHINqlKnOEnlWte_7HDDfxPuHPvQw chapter 4.2

http://www.ece.rochester.edu/~albonesi/research/papers/micro02_2.pdf Introduction and Conclusion are enough

Please stop accusing other people of spreading false information assuming that everything you do not know must be false.
[Samsung Galaxy Nexus] aron7awol:
Believe me, I completely understand that there is additional static consumption, and thus the formula is not a 100% perfect representation of the exact amount of power a CPU will consume. But you know what, it's still pretty damn close. The static consumption would have to be enormous in order to offset the huge efficiency difference between speed steps. It simply is not nearly that large. And this is why, despite the imperfections of using f*V^2 as the end-all be-all, it's still good enough to use as a guideline, and also why, in real-world testing, race to idle turns out to be bogus.

How high do you think this static consumption is? It seems that you are greatly overestimating it.

Edit: By the way, SpeedStep still exists in Core i7. If it were counterproductive to use, don't you think they would have scrapped it by now?
[Samsung Galaxy Nexus] Ezekeel:
No it is not close anymore for modern processors. That is the point.

Did you even bother reading these links I gave you?

Here let me quote it for you

And DVFS is still included for modern processors because there are certain tasks which cause a high number of wakeups which reduce the efficiency of the C-states or prevent them from being used altogether. For example on the GN during hardware-accelerated video playback a latency of 10µs is requested which causes the scheduler to only use the C1 (WFI) state. During such tasks scaling down the frequency is the next best thing to do.

Any other questions?
[Samsung Galaxy Nexus] aron7awol:
It's not close? 6.99x and 6.80x aren't close?

Now you're trying to turn this discussion into whether the C4 state saves more power than scaling down the frequency? Well obviously it does, nobody is saying it doesn't. If you can't use the C-states, the next best thing to do is scale down the frequency. Yes, of course, that is obvious. Your point?

Man, I give up on trying to have a reasonable discussion with you about this. This whole discussion was supposed to be about whether using higher frequencies to race-to-idle saves power over using lower frequencies. Now you're focusing on other things like f*V^2 not being 100% perfect because the real life data collected by ro_explorer proved your theory wrong. Then you tried to turn it into "Ok, on the Galaxy Nexus it isn't better, but on the Nexus S it was." No. It wasn't better on the Nexus S. It wasn't better on the Nexus One. From everything I've read, it wasn't better on any of these Intel chips you keep talking about either. It is simply bogus. I don't know what else to say to try to make you understand this, or to get you to let it go and admit you were wrong if you do already understand it.

We can continue this debate when you can produce some real data supporting race to idle. Until then, sorry, you were wrong.
[Samsung Galaxy Nexus] Ezekeel:
No, I am not trying to change the topic.

You asked me why frequency scaling is still supported on modern processors and I gave you the explanation why sometimes it is still necessary.

The original topic of the discussion was if race-to-idle works on the GN. We have seen from the measurements that it does not.

You generalized this to all processors and turned this into a discussion whether race-to-idle does work at all on any processor that is out there.

I explained to you that it does since it does reduces the static leakage which is unchanged by DVFS.

Then you doubted that static leakage is significant. I quoted people that are considered with chip-design professionally saying that is significant for modern processors.

So to make it clear, my chain of arguments is:

The only way to reduce static leakage are the higher C-states. By maximizing the time in the higher C-states the static leakage is minimized. Since the static leakage is a significant portion of the total power consumption of modern CPUs, the savings in static power consumption can outweight the increase in dynamic power consumption. The question whether race-to-idle works on a certain CPU depends on the relative magnitude of both.
[Samsung Galaxy Nexus] Ezekeel:
I found a brilliant research paper from IBM. It explains why for some systems it is efficient to run at max frequency while for some it is not. It also shows experimental results how the energy consumption of an Intel Pentium based system is lower when running at top speed.

http://www.research.ibm.com/arl/projects/papers/ICS2002-freqScaling-final.pdf

I hope you do not believe that these guys at IBM also only try to spread false information. :rolleyes:
[Samsung Galaxy Nexus] twilightrevenant:
Umm. From what I can tell, the data shows that higher frequency drains more battery when screen off and running mp3. No matter c4 state.

By that is not really an important usage scenario. I am more hoping that glados kernel will provide better screen on battery performance with more responsiveness due to higher frequency.
[Samsung Galaxy Nexus] Ezekeel:
Yes, unfortunately and unexpectedly it does on the GN. We already had that cleared up a gazillion posts ago. Unfortunately since then the thread has moved in another direction.

I think it is at least a relevant scenario and I myself listen to music (mostly FLACs) a lot. So if the 20% increased drain turn out to be backed up by the benchmark I am currently running, this has to be addressed. I might need to re-introduce that screen_off_max_freq option.
[Samsung Galaxy Nexus] aron7awol:
I agree with all of this. However, I'm yet to see a single case of the higher frequency actually being more efficient, so I assume the static leakage isn't large enough (before the IBM article you linked in the following post, of course). That's what I've been asking for.

Thanks for this link. What a great read. So they did find a circumstance where a Pentium III was actually more efficient at a higher frequency, a web server handling HTTP requests. Awesome, finally a piece of evidence that suggests race to idle can work under the right circumstances, specifically with the right combination of processor and workload. Their critical power slope concept is truly brilliant. It also sheds light onto why super low frequency states don't exist.

Now we have some more questions to answer:

1. Do any modern SoCs have similar efficiency states? Nexus S is an example you have brought up, but better testing needs to be done before any conclusions can be drawn. Are there significant differences between the Hummingbird and OMAP4460 that you would expect efficiency across states to be drastically different? I know they are both 45nm, so there shouldn't be a difference in leakage due to a difference in process.

2. Is there a workload that has a realistic chance of happening on a phone where a higher frequency will be more efficient?

3. Can we figure out the critical power slope for the Galaxy Nexus based on the data ro_explorer has collected? If not, what other data do we need?

This thread is officially productive again :)
[Samsung Galaxy Nexus] loudaccord:
I like when smart people are productive :)
[Samsung Galaxy Nexus] Ezekeel:
I finished my benchmarks investigating the battery drain of MP3 music playback with screen off. Using the stock music app with airplane mode activated I did log the battery charge over 10h of music playback (starting with a fully charged battery) using the performance governor, the first time with a maximum frequency of 1320MHz and the second time with 770MHz (both +10% with Live OC).

For 10h MP3 music playback the total battery consumption with 1320MHz is 27% while with 770MHz the battery drain is only slightly reduced to 26%.

So these results can confirm ro_explorer's measurements that the battery consumption is higher at a higher frequency, however the relative difference in battery consumption for the two frequencies is only about 4% (1% for a total of 26%) while ro_explorer's data suggest a significantly higher increase of about 20%.

I do not know enough about electronics to judge which one of the two methods is more accurate (I will ask Adam again to take a look, he is the expert), but one has to keep in mind that both methods have a certain error. On the one hand the battery capacity as reported by the battery electronics has an error, however that error depends on the current capacity and is not random - so for the same capacity the error should also be roughly the same and cancel out when comparing the two frequencies. On the other hand directly measuring the wattage and comparing these only works is the wattage values are the exact time-averaged wattages over the entire task. Since ro_explorer did not measure the wattage over a time with a high enough resolution to account for the wattage changes and then integrated over those, but simply approximated the time-averaged wattage visually, this can be a source for error.

So far are am more inclined to believe the battery capacity measurements are closer to reality since they directly measure and compare the total enery consumption integrated over the entire task instead of comparing the energy drain at one point and relying on the additional approximation of visually estimating a time-averaged wattage. And judging purely from the capacity measurements I currently do not see any reason to reduce the frequency when screen off. But I certainly will keep an eye on the developments and see what the experts have to say.
[Samsung Galaxy Nexus] twilightrevenant:
Wow nicely done. I had thought that in personal experience screen off battery did not change much.

Isn't the mp3 got a dedicated unit to decode that anyways? Wouldnt imagine the core frequency to affect that much.
[Samsung Galaxy Nexus] Ezekeel:
Can you please elaborate on what you think are nasty flaws of Wheatley, besides that it naturally does not work for devices that do not have a deeper idle state that can be used reasonably efficient.
[Samsung Galaxy Nexus] Ezekeel:
As shown in the IBM article above, increasing the frequency does not necessarily result in an increase in power consumption per unit of work. The savings in dynamic leakage can offset the increased dynamic power consumption - and this does not only work for low loads.

I agree that it would be nice if Wheatley would be able to check for himself if he can be used efficiently on the device, but as you can see from the article it depends on a lot of parameters that are very hard, if not impossible, to determine automatically at run time.

So to determine whether Wheatley will work on a certain device is an exercise I leave to the kernel devs and users.
[Samsung Galaxy Nexus] Entropy512:
Let's go back to the equation above:

Power = Joules/second

Frequency = Cycles/second

So let's try and rearrange the equations to Joules/cycle (e.g. energy per unit of work)

We start with:

Joules/second = (StaticPowerConstant + DynamicPowerConstant*Cycles/Second)*(V^2)

Multiply by seconds:

Joules = (StaticPowerConstant*Seconds + DynamicPowerConstant*Cycles)*(V^2)

Divide by cycles:

Joules/Cycle = (StaticPowerConstant*(Seconds/Cycle) + DynamicPowerConstant)*(V^2)

So if V were constant - Minimizing Seconds/Cycle would be the clear winner in all cases. But V must increase as Seconds/Cycle decreases. So the optimal efficiency in terms of joules/cycle is going to be some point dependent on the two constants (static and dynamic power) and on how V changes with frequency.

My believe is that on Exynos, this would lie somewhere in the 500-800 MHz range if LPA were easier to enter - but its target residency is so long and so many conditions block it, that as long as a kernel developer does not implement 100 MHz, they will rarely see benefits from trying to focus on time-in-idle.

OMAP4 is different - OMAP4 can hit C4 far more easily. It also looks like it has far fewer blockers that prevent C4 and force a drop to a lower state, but it's hard to tell without looking in more detail.

Edit: You may wish to revisit Section 6 of the paper you linked. Voltage scaling clearly changes the game, especially, based on their results, on ARM. Also note that I believe there have been significant breakthroughs in process technology over the years that reduce leakage current quite a bit, since the paper dates from a decade ago. I am in a hurry as I have to head to hockey, but note that they basically say operating an SA-1100 below 74 MHz was pointless because it was better to hit idle states - but above this point, it was better to scale frequency. I suspect most ARM processors have leakage that reduces this point to somewhere near the bottom of the frequency bins, in fact possible below the stock minimum frequency of the CPU, which would explain why the stock minimum keeps increasing.
[Samsung Galaxy Nexus] Ezekeel:
On the GN the C4-state is used a lot: http://rootzwiki.com/topic/14685-kernel26-jan-glados-v15/page__view__findpost__p__394599

Hardware accelerated video playback blocks the C-states > C1 from being used, but this can be changed without causing any trouble (https://github.com/Ezekeel/GLaDOS-nexus-prime/commit/77b73155d3ec17acd67b6313ad62da5b04e3e406).

I agree that the experimental results in the paper are outdated. I also think that extrapolating these results to the present technology is pretty useless. That is why I decided to rely on user feedback and benchmarks. And so far the user feedback was overwhelmingly positive reporting significant improvements in battery runtime.
[Samsung Galaxy Nexus] Entropy512:
Well, obviously present technology is going to be different from those results - but I would expect that ARM has put a LARGE focus into reducing leakage current. I'd be really curious to see fine-grained current measurements of the governor in action (I'm hoping to build a dummy battery with current measurement in the next month or two - if you want the design when I'm finished you're welcome to it, other than the mechanicals of the battery it should work fine with a GNex.) - to be honest, I tend to doubt user feedback. If you tell them battery life will increase, or even suggest that it might, they'll almost always tell you battery life is awesome and what you've done is the Second Coming. Look at what a governor rename and some hype did for acceptance of conservative governors with the minimum polling interval restrictions removed over in I9100-land...

That's interesting that video playback blocks the lower C-states, considering that it looks like the exit latency of the lower ones is supposedly only slightly lower. Of course, the numbers could be bogus. (I really feel like Samsung pulled the Exynos numbers out of its ass - why is exit latency 10 us but target residency 40ms for LPA? My guess is that real exit latency is much higher, they just make up for it with the crazy high target residency. But is 40ms excessive?)

I know Samsung blocks LPA in a wide variety of situations. In addition they perform DVS locks during video playback to force the clock frequency higher - in the case of Hummingbird, I know this is partly to make sure the bus frequency isn't dropped too low, although I really need to decobweb my Hummingbird PLL calcs - because I could understand them locking out 100 MHz, but I'm not sure why the lock out 400 on the Galaxy Player. (I no longer own any other Hummingbird device.)

I haven't even looked to see what DVFS locks are used (if any) in the I777/I9100...

Either way - paying attention to C-state residencies in the governor has significant potential. I'm just rather skeptical that targeting the maximum clock frequency is the right approach - if it were, more people would be doing it. I can understand Samsung being too stupid to figure it out, but TI really seems their **** when it comes to hardware/software integration at this point.
[Samsung Galaxy Nexus] gogol:
If you have time to redo the display tests with various brightness?

0%, 15%, 30%, 50%

Using dark and bright homescreens.

Thanks.

---------- Post added at 06:24 AM ---------- Previous post was at 06:09 AM ----------

What app can be used to log battery consumption?

A very simple app, with option to run log at specific duration: 30 minutes, 1 hour, etc.

Which at the end it will output something like this:

Start log at: datetime

End log at: datetime

Start battery at: x%

End battery at:y%

Battery drain is z% per seconds , m% per minutes

Common parameters:

Brightness: b%

wifi was on/off

3g was ...

Airplane mode ...

Nfc ...

Sync ...
[Samsung Galaxy Nexus] ro_explorer:
Have you looked at the additional tests (part #7)?

http://xdaforums.com/showpost.php?p=21777071&postcount=65
[Samsung Galaxy Nexus] Nevod:
While this thread seems to be long forgotten, I still see something very important here.

Maybe it's just me, but with all that CPU governor, clocking and idle-state talk, the GPU seems to be overlooked. From combining screen and CPU test results, seems that GPU is always drawing about 0.5W even when there is no action.

While it of course depend on the person, but my main use profile is web browsing (wifi or mobile data, not much difference actually, I mostly read forums without large pictures, so the traffic is miniscule while amount of information on each page is massive) with minimal or even sub-minimal brightness.

At such profile seems that main power hog is the GPU. I may be asking silly questions now, given I have not dived in-depth into that, but is it possible to apply governoring/dynamic clocking to GPU? Has it been tried?
[Samsung Galaxy Nexus] randommmm:
in additional test, I see there are quite some difference between franco kernel to the Glados kernel, are they under same MPU voltage? That would be strange same CPU running in the same speed consume different battery
[Samsung Galaxy Nexus] ro_explorer:
As I also replied on your PM, the screen alone, when is active, will draw about 0.4 W of power (this is required apparently by keeping the matrix active and the pixels pre-excited, basically in a "ready-to-display-picture" mode. This is also the main cause of the display glow you see in pitch black environment, while the screen is active w/o displaying anything (black picture).

The voltages and governors implementation are the root cause for this.
[Samsung Galaxy Nexus] RogerPodacter:
The problem is why don't other amoled screens show this glow on true black?

I have my nexus one and gnex, both with dead pixel detect installed showing the full screen black color in total darkness. Gnex has the glow, nexus one I'd dead black. Original sgs is the same.

So what do previous generation amoled screens show dead black, but the new HD ones do not?
[Samsung Galaxy Nexus] egps2:
I am also very curious as to why this ready state is required? Also, this glow is VERY une even and makes the screen (GS2) look VERY ugly at very low sub 0 brightness levels (eg with screen filter). Is there a way to reduce this? It may save even more power with black wallpapers and other ui elements. Sorry if this thread is considered dead but it is not too old and I believe this is an important question!

Thanks for any input :)
[Samsung Galaxy Nexus] ro_explorer:
Only Samsung engineers can answer this :) ... but anyway ... it looks like new AMOLED technologies are ready for mass production so I bet that in 1-2 years from now we will see much better amoled screens.

I also had uneven black blacks but after about 4 months of usage the 0 level brightness is now even.
[Verizon Droid Charge] Chopstix9:
I'm gonna be gettin a G-Nex & givin the Charge to my wife. I took it back to stock, rooted it and de-bloated with TiBu. I had been using the imnuts-nofullbatt-debloated421.zip but it's not working with this stock OTA ROM rooted. Is there a fix version out there that wil work with this?
[HD2 General] cyhak:
Hello people i downloaded yesterday this SD Android Rom : http://xdaforums.com/showthread.php?t=957652

Then i tried this... i started usually the clrad.exe and then the Haret.exe....

Then i came to a blackscreen with a small white text on the left corner of the Disply... i waited and waited and nothing happended....

I tried this more ten 10 Times bu it dont works....

Then i found out that i have to flash my Radio...

My actually Rom is : 2.05.51.05_2

I read on the internet that i have to install first HSPL and then i can flash my Radio..?Right?

And is it dangerous?

But i do not know wich HSPL or Radio i should take, to make running my HTC HD2 Android...

Please can you help me?

Can you give me the link to HSPL and Radio Rom please...

My SPL is 1.42.0000... and so on

I found that there is a hspl and hspl2 3, and 4... wich should i take?

Sorry for my verry bad english...

Greetings from Austria
[HD2 General] samsamuel:
You can use hspl 2, 3 or 4, makes no difference. For me, I would use hspl2 and select "2.08.hspl" and then flash radio 2.15.50.
[HD2 General] cyhak:
and is it safe or dangerous?

can i brick my phone?

can i use then android rom on myphone if i install the spl that you mentioned?
[HD2 General] dinukap4:
Bumppppppppppp