nice thread i'll check later.

Originally Posted by Suarez7

No. smartassv2 has.. great governor and lulzactive have

SmartassV2 does not have a screen-off profile. (Smartass has). It has only a "sleep_ideal_freq" to which the governor ramp down CPU aggressively when screen is turned off.
If some task demands more power during screen off, the frequency can go all the way upto maximum frequency depending on the load/demand.

Lulzactive has screen-off profile and the max-freq for scree-off state is configurable as well.

Originally Posted by droidphile

Yes, i have the same opinion.
Second graph in this thread by Ezekeel, shows the difference between lower and higher frequency steps' battery consumption with and without LPA/deep idle. As it occurs, higher frequency supports race-to-idle better there

Again, "100 mhz bad compared to 200 mhz" depends on we're using lpa or not. (sched_mc=2 or 3).

Anyhow, since only first core can hit lpa, screen-off profiles with: different governor, hard limiting frequency, switching to single core mode, etc actually does a little harm than good by delaying for race-to-idle.

Yup - thanks to stuff like idle states and multiple cores, many of the old "rules of thumb" have become FAR more complicated.

In my opinion - hard-limiting to 200 is bad. I hard-limit to 500 as a safety measure - voltage increases a decent amount at 800, and if something drives more than a blip at 800, something is wrong.

Deciding when to turn on/off the second core is much tougher - having it on gets you "done quicker" in theory - but turning it on takes time, and some tasks run less efficiently when spread across cores. Also it may be better to hit 800 MHz than to run both cores at 500.

Originally Posted by droidphile

SmartassV2 does not have a screen-off profile. (Smartass has). It has only a "sleep_ideal_freq" to which the governor ramp down CPU aggressively when screen is turned off.
If some task demands more power during screen off, the frequency can go all the way upto maximum frequency depending on the load/demand.

Lulzactive has screen-off profile and the max-freq for scree-off state is configurable as well.

That is a weird one as i always thought smartassv2 had that profile already implemented in it. Honestly i prefer smartassv2 compare to lulz cause phone sleeps better and when in idle does not lose as much batter as lulz would. Thanks for explaining friend

Sent from my GT-I9100 using xda premium

Originally Posted by Entropy512

Yup - thanks to stuff like idle states and multiple cores, many of the old "rules of thumb" have become FAR more complicated.

In my opinion - hard-limiting to 200 is bad. I hard-limit to 500 as a safety measure - voltage increases a decent amount at 800, and if something drives more than a blip at 800, something is wrong.

Deciding when to turn on/off the second core is much tougher - having it on gets you "done quicker" in theory - but turning it on takes time, and some tasks run less efficiently when spread across cores. Also it may be better to hit 800 MHz than to run both cores at 500.

Yup, 'rules of thumb' are no longer valid. It's the world where "ondemand" can save juice, "conservative" can conserve nothing, and so on, with more and more sophisticated tunables in the user space.

800 has to be the 'weirdest' frequency. Some devices enters deep sleep at 800 (when user configures so), device need to be @800 for a few ms when awaken, voltage required considerably increase @800, and so on. With voodoo louder, equalizer and powerampp contributing to music-play in screen-off state, CPU spends most of the time at 100/200 and negligibly little at 500. So 500 is the ideal-high screen-off cap freq. (When device hits deep sleep, this is however overriden and cpu set to 800 or 1000 for the req time anyways)

Using hotplugging and single core mode is sometimes funny if you think of a task that cause low load on cpu0.(assuming low UP thresh & high LOW thresh for hotplugging) The time taken to switch cpu1 plus time to turn it off (when low threshold is found) plus the time taken to do the task may be more than the time taken for cpu0 in single core mode to do the same task.

Kudos to what geko has done for the many once-newbies on here - he has provided a stable platform on which newbies can test, and to improve on. I for one, greatly appreciate his help.

Originally Posted by coolfire

Kudos to what geko has done for the many once-newbies on here - he has provided a stable platform on which newbies can test, and to improve on. I for one, greatly appreciate his help.

+1 now i don't have to feel bad about bugging you for your latest config. i can just refer to this page. nice!

I wanted to post feedback for geko: raising all your UV settings with 50mV has kept my device all day running without a single problem. Maybe I will try to go down 25 mV again to get even closer to your setup. To bad my device can't handle your config, but like this it's close

Originally Posted by coolfire

Kudos to what geko has done for the many once-newbies on here - he has provided a stable platform on which newbies can test, and to improve on. I for one, greatly appreciate his help.

Exactly the point of this config.

Thanks for your understanding mate.

Originally Posted by legionxx

+1 now i don't have to feel bad about bugging you for your latest config. i can just refer to this page. nice!

Yeah, for me it's no more sending out 50 PMs per day lol

Originally Posted by XDA mark

I wanted to post feedback for geko: raising all your UV settings with 50mV has kept my device all day running without a single problem. Maybe I will try to go down 25 mV again to get even closer to your setup. To bad my device can't handle your config, but like this it's close

Dude, so my suggestion is working fine. I'd say leave it for a bit longer then if everything else is fine, start reducing each step by 25mV. Remember to give a bit of time to run it each step at reduced voltage before going onto the next frequency.

Good luck.

Been running your settings for over 12 hours now. So far everything seems good. Been using the noop/ conservative scheduler governor combo. Put the device through the paces and stability wasn't an issue.

Thanks!

Will report back on battery life tomorrow sometime.