Related
I did an experiment with some interesting results. It started out as my beginner's attempt to compare two kernels.
It evolved into providing insight (I think) regarding up/down threshhold parameters for the "conservative" cpu governor
If you dont’ want to read the whole thing, jump to the conclusion section posted at the end.
Phone configuration – installed qkster’s UCLB3 with AT&T bloatware removed, added custom kernel, rooted.
To remove variable cpu loads, I turned wifi/data off and turned off the continuously-running programs that I have installed myself (Power Tutor and Tasker).
To create a steady cpu load, I started the program “relax and sleep” (calm background noise program, available for free). I checked one audio channel in the program, and pushed back button to place program in the background, still creating noise. (I think relax and sleep is a good choice of program for cpu testing in general because it allows to check variable number of channels which does put variable cpu load.. although in this case I only used only one channel.. and note that you cannot recreate this experiment if you use mp3 music app instead, because it uses much less cpu than one relax and sleep channel)
Then I started setcpu for monitoring and experimentation. Repeated with several different kernels.
Results with Entropy’s daily driver kernel.
I set the test setup in setcpu to conservative governor, Fmax = 1200, Fmin = 100, i/o scheduler = noop.
The cpu frequency in Mhz now has the following pattern:
800, 1000,800, 1000, repeat ... (frequency changing approx once per second)
Results with with Zen Infusion-Z A/1600 kernel.
I set the test setup in setcpu to conservative governor, Fmax = 1200, Fmin = 100, i/o scheduler = noop (same as before, intending to compare the performance of the kernels).
The cpu frequency in Mhz now has the following pattern:
1200 (constant).
ok. On the surface one might conclude Entropy’s kernel is somehow handling the load better without ratcheting up the frequency. But the story gets more interesting than that:..
Next I tried Zen’s same kernel Infusion Z/1600 with everything the same except change the cpu governor from “conservative” to “on-demand “
The cpu frequency in Mhz now has the following pattern:
200, 400, 200, 400, 200, 400, 200, 400, 200, 400, 200, 400, 200, 400, 200, 400, 1200 repeat
(changing about once per second, mostly 200, 400, pops into 1200 only very infrequently).
But wait! The "conservative" governor is supposed to be better on the battery than the on-demand governor, and yet for the exact same conditions, we’re gettings higher cpu frequency (1200 constant) with conservative than with on-demand (mostly 200/400 with occasionaly 1200). It’s the exact opposite of how it's supposed to be. Surprising, don’t you think!!???!!
So now let’s look at some other governor settings that don't seem to get much attention.
Go to “governor” page of setcpu with “conservative” selected on the main page. The following values appear repeatably after kernel installation for each kernel, so I am ASSUMING these are default values provided in the kernels themselves (open to comment if I have somehow come to the wrong conclusion)
For Zen’s Infusion-Z (A or B, 1600 or 1400)
up threshold = 80
down threshold =20
(also freq step = 5, sampling rate = 78124 although I don’t think these are important for this post)
For Entropy’s DD
up threshold = 50
down threshold =35
(also freq step = 20, sampling rate = 40000 although I don’t think these are important for this post)
(both kernels have sampling down factor = 1, ignore nice load = 0).
I think we can explain my "experimental" results by examining the above up and down thresholds and making some assumptions about the nature of the load (my assumptions are admittedly contrived in attempt to explain these observations, but they seem reasonable to me).
I ASSUME the steady cpu load I have created in my steup varies in the range 350-400 Mhz quasi-steady state (not perfectly constant due to other processes jumping up in the background).
I ASSUME that before the steady cpu load is reached, there is a temporary increase in cpu loading to 700Mhz or more associated with me flipping screens around to get from the relax and sleep appliation to the setcpu application. Within several seconds, this temporary increase will be gone and only the quasi-steady portion 350-400 Mhz remains.
First look at performance of Zen's Infusion-Z A/1600 while in conservative with default settings in the above experiment. That initial spike of 700Mhz load was enough to get us above the up-threshhold of the 800M-hz level (80%*800Mhz = 640Mhz) and push us to 1200M-hz (1200 comes after 800 in progresion for Zen A, which has no 1000). Once we got to 1,200Mhz, we are NEVER going to get down from there until we reach a load corresponding to the down-threshhold of that level which is 240Mhz (20%*1200Mhz = 240Mhz). And with my relax and sleep application running at 350-400Mhz, it won't happen. That is quite a depressing thing to think – I could put my relax and sleep on for an hour as backgorund noise, and my cpu would be buzzing at 1,200Mhz even though the load is only 350-400Mhz.
This seems very undesriable for battery life.
Now lets look at performance of Entropy’s daily driver in conservative/default setings in the above experiment. The postulated 350-400Mhz cpu load occasionally exceeds the up threshhold of 800Mhz (50%*800Mhz = 400) and once in 1000Mhz occasionally drops below dropout setting of the 1000M-hz (35%*1000Mhz = 350). (And now you know why I postulated 350-400). I have two comments about these Entropy results. The first is minor/tangential, the second more important.
1 - First comment (minor/detour) has to do with cycling between different cpu frequencies which is created by the governor (not the load). I don't think it's any problem at all, but this type of cycling is more likely to occur when the diferences between adjacent frequencies are large. For example let’s say the cpu load was rock solid pure steady state (not varying) at 250Mhz. The up threshhold for 400Mhz setting is 200 (50%*200) while the down threshhold for 800Mhz is 280 (35%*800). So we have postulated a situation where the cpu demand is pure steady state (250Mhz), yet the governor will never find a steady state solution... if it’s in 400Mhz it wants to upshift and if it’s in 800Mhz it wants to downshift. Again I don’t think it’s a problem (it's probably ok to let the two frequencies time-share back and forth) but there is a strategy to avoid it if we want to avoid it, as follows. Considering the highest possible ratio between adjacent frequencies (for these kernels) is 2.0, then we should set things so the ratio of (UpThreshold / DownThreshold) > 2.0 in order to avoid this cycling (which is probably not a problem, more later)
2 – Second comment is more important because it relates to battery usage (as I percieve it). Original postulated load that explains this experiment results is 350Mhz-400Mhz. Yet the cpu is running at 800-1000Mhz. Twice as high. That’s wasting some battery I think.
To summarize results so far, it seems to me that Zen’s kernel default thresholds have potential to waste battery due to low down threshhold (20%), which can keep it at high CPU rate forever, even though the load has decreased substantially. In theory we could be setting the cpu almost 5 times as it needs to be in the situation where steady load decreases to just above 20% of the higher level.. The Entropy’s kernel default threshhold have potential to waste battery due to the low up threshold (50%). In theory we can be setting the cpu almost twice as fast as it needs to be in the situation where the steady load increases to just above 50% of the lower level. Entropy's kernel defaults also create the potential for continuos cycling between frequencies even in the presence a of perfectly steady cpu load, since ratio up/down is less than 2 (I don’t think that's a problem, the only reason I mention cycling is because it feeds into my strategy for selecting down threshold - see below).
So what settings should we use for up/down thresholds? Actually I haven't done my complete due diligence in searching before posting this thread, if someone has a good link with recommendations and/or discussion on this subject I'd be interested. I have seen the generic xda thread on governors and I don't think it was covered there in terms of specific recommended values. Here's my thought process fwiw:. Higher is better for battery on both numbers (at some possible expense of performance). I remember seeing on other sites a default up threshhold of 95% (listed, but not discussed). That makes sense to me for battery saving... shift up at the last minute. Perhaps this high value gives small slowing of response to demand increase, but I don’t think it’s much slower (especially for rapid cpu load increase which is the most critical for response...rapid increase means short time to get from 50% to 95%... short time means not a big response penalty difference) and certainly it seems worthwhile to try to strive for an efficient operating point in long-term steady state. Additionally, we're talking about the "conservative" governor which is supposed to favor battery (we can set up a setcpu profile to invoke on-demand or interactiveX in situations when we want more responsiveness and don't care as much about battery, at least these are availble in Zen's). I don’t recall seeing any number for down threshhold, but should be high as possible again to save battery. How high? I don't know. The only way to put a limit I can think of it is to impose an arbitrary (maybe unnecessary) requirement that we don't want any cycling in pure steady state as discussed above. This means we need down threshhold at least a factor of 2 below up. So I pick 95/2, rounded down to nearest round nubmer of 45%. There may be further improvements if we drop that requirement to avoid cycling and allow even higher down-threshhold, but at least we know the down threshhold of 45% would seem to have moved in the right direction for battery from the defaults. So up/down 95/45 is my pick for now.
Using conservative governor with 95% up threshold and 45% down threshhold (still noop i/o) in above conditions on Zen’s kernel, I’m seeing frequency pattern
400, 400, 400, 400, 400, 400, 400, 400, 800, repeat
in other words mostly 400, intermittent jump to 800.
Certainly the up/down 95/45 settings for conservative governor perform better batterywise than the default settings for conservative governor given in both kernels for this one experiment. To me, it seems very reasonable to expect it to also be better batterywise accross a wide range of expected operations, but it's open to comment.
Small detour - why did we do better batterywise on Zen's on-demand default settings than on Zen's conservative default settings for this particular cpu loading?. The settings for Zen's on-demand default include an up threshhold of 95% and no down threshhold. So on-demand governor apparenlty finds some other way to shift down. Since the 20% down threshold that was causing the problem in Zen's conservative governor default settings is not present in the on-demand governor... that probably explains why the on-demand didn't get hung up at the higher level and performed better afterwards. Another thing to note, if 95% up threshhold is responsive enough for the on-demand, it should surely be responsive enough for the for the conservative...supports the previous sugestion to increase conservative up threshhold to 95%.
CONCLUSIONS:
There is only thing in this entire thread that I am completely 100% positive about, and it is that Zen and Entropy know lightyears more about this stuff than me. In fact, that is the very reason that I was extremely careful to record the as-found default settings in order to preserve any intelligence that went into those defaults before I started tweaking.
So I can reach one of two conclusions:
#1 – I am completely misunderstanding how this conservative cpu governor works
or...?
#2 – The developers never intended for the “default” values to be used, instead they envisioned the users would adjust them as needed.
In the event that #2 were correct, then it would seem logical for battery-concious users to tweak these up/down threshhold settings of the conservative governor. My thoughts would be to set them to 95/45 by the logic above.... may or may not be considering all relevant factors. I'm open to thoughts and comments....
In the above analysis, I have assumed that power consumed by the cpu can be predicted from the cpu frequency (for a given voltage setting of course).
I now believe that assumption might be incorrect.
The reason I believe it is false is a result of another experiment I just did.
I set the cpu governor to performance to maintain constant 1200Mhz.
Then I looked at the cpu power usage trace in "Power Tutor" program.
I expected to see power attributed to cpu usage as constant, but it was varying up and down.
And by moving the homescreens around, I could create a dramatic and predictable increase in power usage of cpu (as indicated on Power Tutor).
All of this change in power consumption of the cpu occurred while the cpu governor was in performance mode with cpu frequency constant at1200Mhz.
I didn't expect that. I can't really explain it (can anyone else?). But clearly there is more to the story than I thought (assuming that the cpu power usage reported by the Power Tutor is correct, which I'm not sure of either).
To evaluate the battery friendliness of variouis governor settings, it might be more useful to watch the power tutor results when performing the above experiments, instead of just watching the cpu frequency as I did before.
Over my head...
How does the battery cycle pan out?
It would be nice if you or someone else had a spare phone to test this battery consumption theory.
I would wonder if the report of consumption is also correct.
The bottom line that I would be interested in seeing is how long can the phone, running a certain kernel and governor, last.
For example: Charge to 100%. Take off charger. Wifi off, Cell data off and in Airplane mode (removing signal variable).
Then run kernel with governor - record the battery duration.
e.pete - nice work! I appreciate your empirical approach to this topic.
I can add the following: you have described accurately how the conservative governor works. For OnDemand, the governor behavior results in the CPU at max under load and minimum when idle, with a smaller amount of time being spent at the steps in between based on thresholds. On my phone today with OnDemand, for example, I'm at 1600mhz 6% of the time, 100mhz 5% of the time, and 800mhz 2% of the time. Deep sleep is 83% and the other CPU frequencies are all below 0.5%.
In general use, conservative should be kinder to the battery and to the hardware. The recommendations I have seen for Linux platforms is to use conservative where battery life matters and ondemand when there is a constant external source of power (i.e. PC or server). Of course, actual use determines how the governor performs. Most smartphones have a lot going on even when the screen is off. A good indicator of average CPU use over the course of a day is CPUSpy. This app, combined with a decent battery monitor can help tell the story from a macro/whole system perspective over time. On the "be kind to hardware" topic, conservative should increment and decrement to adjacent frequencies based on load. This behavior might be happening too fast for SetCPU or other realtime monitor to capture..that's where CPUSpy can show what is happening over a larger period of time. These more gradual transitions may result in less wear and tear on the phone hardware, but I have not seen any significant evidence that this is a factor in the usual life span of a smartphone. (On the flip side, setting the governor to performance and OC to max setting...that is NOT recommended and could harm the phone).
That said, the two kernels you tested have the following default characteristics:
Entropy DD - Conservative/BFQ - Optimized for stability and battery life
Infusion (Bedwa/Zen) - OnDemand/CFQ - Optimized for performance
The Infusion kernels do not include optimization settings for conservative. As you surmised, the expectation is that if you are going to change these settings you have some idea of what you are aiming for and will adjust accordingly.
If battery life is your aim, I've found that the best savings are realized in optimizing transition to sleep when the phone is not being used, minimizing the number of apps that attempt to keep the phone awake, and being selective in your use of wifi and data radios (although too much mucking around with this last option can lead to triggering some of the known bugs in these kernels which manifest as a higher than normal Android OS or Dialer/RILD drains - as seen on the standard battery usage screen in Settings).
On this last topic, there's another thread (which I see you have visited) which covers discussion and work on these known battery drain anomalies: http://forum.xda-developers.com/showthread.php?t=1408433
Here is some additional information on governors courtesy of Big Blue... http://publib.boulder.ibm.com/infoc...?topic=/liaai/cpufreq/TheOndemandGovernor.htm
And a bit more info ... https://wiki.archlinux.org/index.php/CPU_Frequency_Scaling
Truckerglenn said:
Over my head...
Click to expand...
Click to collapse
:what: I'm so glad there are people much smarter then myself here. Great work electricpete :thumbup: even if I followed about half of it
Sent from a de-FUNKt Infuse
Pete - Here's a link to a thread that has a lot of information about governors, i/o schedulers, tweaks, scripts, and kernel objects:
http://forum.xda-developers.com/showthread.php?t=1369817
Thanks everyone, a lot of good info.
Especially Zen, very useful info and links.
It was a very interesting comment about certain governor strategies being hardware unfriendly if they jump increase the cpu from min to max.
I never realized that was a factor (only thought the max speed was important).
But it definitely sounds plausible. Maybe (?) the rapid temperature increase causes uneven temperature (cpu gets hot before attached plate gets hot) and therefore uneven thermal expansion, which causes mechanical stresses. I can imagine there are other subtle aspect of the cycling up/down that can be important. If you have any more info or links on the effects of cpu governor strategy upon hardware life readily available, I'd be very interested to hear it. (If not readily available, that's fine too, I will do some googling).
I did find this link which suggested it's better for the hardware life to run at 100% (I guess for us that's 1200Mhz) than it is to cycle up/down. It's not written about phones but about PCs. There might be some differences in the technical aspects. There are of course big differences in the priorities for PCs... they don't care about power usage as much as phones do, and pc users probably expect a longer life than phone users do.
http://www.overclockers.com/overclockings-impact-on-cpu-life/
Thanks again.
I will report back if I get some free time to continue experimenting... maybe this weekend.
Primary consideration (as you've noted) with smartphones is battery conservation. ARM processors are engineered to operate at multiple frequency steps, and to turn off where possible. Without this capability phones would need a much higher capacity battery. As for PCs, current processors include frequency stepping technology to reduce power consumption and heat, and perhaps extend life by keeping temps lower.
The main conclusion of the article you referenced (which is 13 years old, btw, but does contain a wealth of good foundational information) is that heat is the primary enemy. This is a major factor with smartphones as they have limited ability to dissipate heat. An Infuse running at 1200mhz (or 1600mhz OCed) confined to a purse or pocket, or (as reported in these forums a while back) under a pillow gets hot very quickly. This will lead to conditions that will harm the phone. At one time, my phone had an error condition causing the Dialer to go crazy (rild process) and peg the CPU at 100% for an extended period of time, while the phone was also plugged into a charger (thus heat from the charging process too). The end result of this was a temperature that tripped a heat sensor threshold, causing the phone to shut itself off. So there are, at least, limited protections against extreme events.
As I noted above, I've not seen any evidence that the normal (or even OCed) frequency stepping that occurs with smartphones leads to failures within the normal in service period for these devices - 2 to 4 years in most cases. Running at 100% all the time may put your phone's health at risk and will definitely impair your battery life.
Zen - Good points. One thing I do take away from the article (along with your comments) is the cuumulative effect of cycling, So when I settle on up/down threshholds, I may try to avoid putting them too close together in order to avoid extra cycling (keep Max/Min threshhold ratio >2). Although I do realize these particular cycles between two adjacent frequencies are not as bad as bad as the cycle between min and max frequency.
more test results
I have completed some testing using PowerTutor and results reported in attached spreadsheet.
I would say the results only muddy things further. Don’t read any further if you don’t have a tolerance for ambiguity.
SETUP (common to all tests)
In all tests, I had similar setup as in the original post: 1 channel of “relax and sleep” running to create a constant cpu load, and all other continuous-run programs turned off except power tutor.
Some other details common to all tests: Tasker off, Wifi off, data off, Power Tutor on
No uv
Noop I/o governor used throughout.
WHAT CHANGES BETWEEN TESTS:
See the spreadsheet, tab labeled “summary”.
The things that changed between tests are in rows 3 thru 8, labeled “Tested Configuration”
As you can see, between tests, I varied the Up threshhold and Down threshhold. I varied the kernel. I varied the governor (mostly conservative, but performance used).
WHAT WAS RECORDED DURING EACH TEST:
1 – Recorded power usage of CPU, LCD, Audio as reported in Power Tutor over the course of one minute. I converted them to battery %/hr (conversions shown in tab “Notes”) and listed them in rows 12-14
2 – Recorded the actual cpu frequencies seen in setcpu “home” screen, similar to original post and listed these in row 15. I attempted to guess the average frequency over time and put this in row 16.
3 Rows 18-23 are the Quadrant results for the six categories that Quadrant reports (yes, I know people don’t like Quadrant, just recorded as a datapoint)
WHAT PATTERNs EMERGE:
1 – Entropy’s DD and Zen’s Infusion-A use comparable power (as reported by Power Tutor) in this particular experiment.
2 – Zen’s Infusion does better on quadrant score in this particular experiment, when both are set at the same governor configuration (100-1200, conservative), . Not surprising since Zen said he has optimized for performance.
3 – How does the governor frequency affect power usage? This is the muddy part. There is no doubt that if we blindly take the data at face value, then there IS a correlation between cpu frequency and power attributed to the cpu by Power Tutor. However the correlation that emerges from the data is in the opposite direction from what anyone in the world would think: this data suggests that increasing CPU frequency causes decrease in power consumption reported by power tutor. See tab labeled “chart 1” for graphical depiction of this result.
As you can see in the graph, there is not a random spread of results (as would be the case if random unacconted-for errors were at work). There is a definite correlation. What it suggests perhaps is that there can be a systematic error in the way PowerTutor measures power that depends on cpu frequency.... in other words the error itself (between measured and actual) somehow depends on cpu frequency.
So, I am just reporting some results. I am definitely not suggesting anyone overclock to save power (that would be truly bizarre and I’d probably be kicked out of xda for suggesting something so silly).
On the other hand, as stated in the 2nd post of this thread, I’m still very leery of using cpu frequency as an indicator of power that cpu is drawing... because there is just too much going on inside that black box that I don’t know about. For one thing, the cpu itself may draw different amounts of power at a given frequency depending on it’s loading because the registers may not be doing anything at low loads. For another thing, there are a lot of other things in the phone (like RAM, bus) that may draw some power but probably get lumped in with the reported cpu power in Power Tutor and others. Perhaps the cpu is somehow more efficient at interfacing with these others parts of the system when cpu is at high speed, enabling it to reduce the power they draw. The point is, it’s a lot more complicated then I assumed in my first post.
I have heard Entropy mention that before changing kernels we should always reset UV settings (and reboot) and reset other cpu related settings (Fmin and Fmax I assume).
I would like to add another item: always uninstall setcpu before changing kernels and reinstall it after you change.
The reason: I have seen some very weird results of setcpu when I left it installed in between swapping kernels. Like for example cpu running at 1600Mhz even though Fmax is 1200Mhz and there are no profiles allowing 1600. Those weird results are not included in the above data (I observed the frequencies during each trial as reported in the spreadsheet).
Power Tutor has a great interface and very detailed stats available. Seems to have great credentials based on their website.
But I can only conclude we can’t trust it for our particular phone because of results above (power draw goes down as cpu speed goes up) and some other results I have seen (it seems to suggest that power used by my display does not change depending on dark/light backround, and also seems to suggest that power used by the phone does not change when I change the volume of music playing).
So, I’m looking for another way to be able to track power usage closely.
I kind of like qkster’s idea to just watch the battery go down.
I’d like to try to automate that using Tasker. I can write a program which will help me build a log of power usage.
The interface will be:
push a start icon and it prompts me to enter description of conditions that will be tested
wait some period of time (this is the constant-load test period that we're evaluating...may be listening to mp3)
push a stop icon and it prompts me for comments about anything that happened during the test.
At time of pressing the start icon, it will also record from the system:
1 - clock time (in seconds)
2 - voltage in millivolts to 4 digits of resolution (like 3784 millivolts)
3 - battery life remaining in percent to 2 digits of resolution (like 43%)
The same info will be recorded from the system upon pressing the stop icon.
All this info will be appended to a logfile and we can compute drain based on change in battery divided by change in time.
I can get these voltage and % life stats using the method suggested by Brandall’s tutorial here:
http://tasker.wikidot.com/using-linux-shell-with-tasker-for-a-technical-battery-widget
I couldn’t get the grep command to work, but I can still extract the required voltage and percent-life-remaining from the Battery sysdump using the tasker variable splitter command (I’ve already got that part programmed).
No-load voltage has a roughly known relation to battery life, but there’s also the matter of voltage drop accros the internal battery impedance that varies with load at the time of the measurement, so we don’t see no-load voltage, we see something lower which makes the whole thing somewhat variable.
Percent Remaining is the exact thing I want. But it is only given rounded to two digits, (43%). If I wanted to do a trial run listening to a 5-minute MP3 draining something like 12% per hour, the battery drop during that that 5 minutes will be only around 1%... the difference between two kernels or cpu frequency settings will be only a very small fraction of that 1%, so comparing the start and stop values which are both rounded to 1% would introduce an enormous error compared to the thing we're interested in. I can surely reduce that error by working with longer times, but that starts to become a PITA. That may end up being the only solution, but if there's any way to avoid it I'd like to be able to gather data in shorter chunks.
Which leads me to a QUESTION:
Does anyone know whether there is any way to retrieve or estimate “battery % remaining” with greater resolution that two digits (ie 43.26% instead of just 43%)?
unintended consequences from changing up threshhold
I used the following setup for almost a month:
Zen’s Infusion A Kernel (with my stock GB), conservative governor
UpThreshold = 95
DownThreshhold = 45
Only twice during the month, I saw the following:
Received a phone call. I could see the name of the caller. I couldn’t hear the caller. When I finally got hold of them later, they told me they could hear me even though I couldn't hear them.
That was very tough to figure out because it only occurred on two out of probably 30 or 40 phone calls received in a month.
The two phone calls did originate from cell phones in the same geographic area (near my work, an hour away from my home).
Then I had a breakthrough when I set up my work voicemail to automatically call my Android phone. Almost every time it called, the problem appeared (I couldn’t hear the robot voice telling me I had a message).
I kept leaving myself messages to reproduce the problem and narrow it down.
I found out it only occurs when my phone is asleep at time of the call (doesn’t occur if phone is awake at time of the call).
I removed my UV and problem continued.
I adjusted my governor and could make problem go away.
I narrowed it down to the up threshhold.
Repeatable with 95/45 up/down, the problem occurs.
Repeatably with 80/45 up/down, the problem does not occur.
I have gone back and forth between those two settings at least four times and each time it confirms the symptom is directly related to the governor setting.
Exactly why that is I’m not sure. Maybe the cpu is to slow to wake up to handle the call? Sounds kind of hokey, but I guess it doens’t really matter.
The bottom line for me: 80/45 is a great place for me to stay. Eliminates the “can’t hear caller” problem and still does pretty good at preventing cpu from going to high frequency when listening to my relax and sleep program for long periods of time.
If anyone has gone to 95/45 based on my recommendation, you might rethink it, especially if you see unusual behavior.
Hello, I want to start discussion and know your experiences how much energy can you save using cpu scaling. I have read thread that explains governors and I/0 schedulers in threads like here: http://forum.xda-developers.com/showthread.php?t=1950084 and my Samsung galaxy Young (GT-S 5360) with JellyBlast 3.0.4 rom installed works best with:
min: 150 Mhz,
max: 832 Mhz,
governor: performance,
IO scheduler: SIO.
Heres the problem: I want to be os and webpages scroll in my phone fluent and it is near 100% only when using governor "performance" which is not recommended. But I dont see any affect to "miles per gallon" because when I run cpu statistics, the cpu is in "deep sleep" all time when dispay is off and phone locked. My phone usage is sometimes to make one or two phonecalls a day.
But there is another situation: dispay brightness on 25% or 50%, wifi or 3G turned on and browsing the web and listenting music during travelling.
So my question is if there is some posibility to measure how many watts eats each hardware component in phone and because of this if it makes any sense to dynamically scale down CPU when display and wirelles are active, how many electricity can it save compared to consumption of display and wirelles, lets say +5 or +10 percent time on battery makes no sense for me.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Ultimate battery guide
Battery, one of the most important thing on todays phones. Even if we have awesome battery life we always want more and it is never enough.
This is the small guide to tips, trick and tweaks to improve battery life.
This topic is to share tips and tricks and basically just small talk about battery and sharing screenshots.
Use Gsam or Android battery history to show your battery life.
Our goal is to make most of the screen on time with average use of 24 hours. So lets start.
Post 1: Tips
Post 2: ROMS, kernels, undervolting, underclocking
Tips to improve battery life
Location services
One of the first thing that your device will ask when you are setting up your phone. Most of the users let them ON and just forgot about them. Location services are battery hungry and the will drain your battery like you drinking juice.
Thing is that you do not need them always, just sometimes. Turn it OFF then. I have them turned off always and when I need it I just simple turn it ON.
Wi-Fi
Wi-Fi scanning is thing that will drain your battery always. When you are out and you are not expecting to use wi-fi any time soon turn it off. You do not need to run scanning all the time.
You could also edit build.prop to reduce.
Edit wifi.supplicant_scan_interval. Default value is 180. You can set it higher to reduce the scanning intervals.
Signal strength / Network mode
Signal strength is always trouble for battery. Weak signal will drain more battery. Also, constant changing between 4G/3G and 2G will drain battery faster.
Tweak to this is to set your phone to only use 2G, 3G or 4G.
Example: when I am not using my phone, or it is connected to wifi my network is on 2G. I dont need 3G or 4G then and changing network state is disabled then because it will stay always on 2G. I found it has positive effect on battery.
When I need, I just simple toggle 3G or 4G.
Screen brightness
Screen is the thing that drains most of our battery. There is not much philosophy here. Higher brightness will drain more battery.
My personal setup is that I do not use auto brightness. I always change brightness manually. Right now during winter my brightness does not go more then 25% outside, and inside it is lower. At night it is under 10%.
I found that not using auto brightness has also slight positive effect on battery.
Syncing / Airplane mode / Vibration / Animations / Task Killers
Lets start in order.
Syncing: more syncing your device does it drains more battery. On your phone probably you do not to sync all accounts and apps you have every few minutes or hours. Set those apps you do not need on manual sync.
Airplane mode: I am using airplane mode during night because I do not want to be disturbed during sleep. With airplane mode battery consumption during night is 0%. Yes, zero percent.
Vibration: more your device vibrates, more battery it drains. You can reduce vibrations on keyboard settings and similar. I found that is not much effect on battery but it has slight.
Animations: animations drains your battery also and who really needs them. Personally, I am annoyed with them and I always switch them to 0 or .5. You can do that in Settings-Developers options
Task Killers: task killers, clean maters and similar software is a big NO. You dont need it. It does more damage then good.
Bloatware
Yes, bloatware. There is huge amount of bloatware on our phones and we really do not need it. So, what to do? Freeze that bloatware.
You can find list of apps HERE.
ROMS and kernels
Custom ROMs and kernels will give you in most cases better battery life then stock firmware. Plus there is huge amount of options to play with. You can read more in posts bellow.
Summary:
If you change some of those thing you will see the effect.
You can always use apps like Greenify or Tasker and play with their options.
How to follow your battery life
GSam Battery Monitor
This one of the most useful apps to track your battery. On Lollipop (even on Kitkat) it will not give you much useful info without root.
If you are using it without root everytime you reboot the phone statistic would be reset also. If you have root it will give you access to wakelocks and some other stuff, plus stats would not get reseted.
Play store link
Wakelock detector
Wakelocks, one of the painful things on phone. If you see your battery is draining faster in idle then you got problem with wakelocks. This is useful app because it shows wakelocks on very simple setup and you can discover which app is causing which wakelock.
Play Store link
Disable service
If you are using Wakelock detector you need this app also. With this app you can freeze every single process that app can launch. It will provide detail look on all processes from apps. With this app I have reduced wakelocks to 1%.
Play Store link
ROMS
Discussion about ROMs never looked nice. It always gets to what you personally like. Some ROMs will be easier on battery, some will be rough. You will never know before you try them.
Kernels
Kernels are similar to ROMS but you can play with them. Currently there is not much kernels available but you can play even with stock one.
I recommend to use Trickster MOD Kernel Settings app to play with kernel settings.
Undervoting
Undervolting is the thing when you control how much power each CPU frequency can have. Trickster MOD app gives really nice view on them. You can undervolt every frequency by itself or all in one.
My personal recommendation is to undervolt them at once. I always use -50 value. Found it stable.
Of course, you can always play with different values but remember: when you play with this do not click on option "Set on Boot" or you will end in bootloop if you click it. Click that option when you find out that values are safe for using and stable.
Underclocking
Underclocking is changing your CPU frequency. Rough truth is that we dont need our CPU to run on 2,7 GHz in normal use. Only gamers will need that probably but since this is not thread were we are aiming gamers we dont need that high frequency.
Me personally, I use always 1,7 GHz or 1,9 GHz. To my daily usage (most common like everyone else but without games) this is more then enough. Everything is still smooth and runs fast.
Governors
A CPU governor in Android controls how the CPU raises and lowers its frequency in response to the demands the user is placing on their device. Governors are especially important in smartphones and tablets because they have a large impact on the apparent fluidity of the interface and the battery life of the device over a charge.
You can find explanation hidden here.
Many users have wrote about governors and they are practically the same on most of the phones so I will copy list from droidphile.
On his topic you have more details about governors.
Link to original topic: http://forum.xda-developers.com/galaxy-s2/general/ref-kernel-governors-modules-o-t1369817
I) MANUAL:
These are the 19 governors we're talking about.
1) Ondemand
2) Ondemandx
3) Conservative
4) Interactive
5) Interactivex
6) Lulzactive
7) Lulzactiveq
8) Smartass
9) SmartassV2
10) Intellidemand
11) Lazy
12) Lagfree
13) Lionheart
14) LionheartX
15) Brazilianwax
16) SavagedZen
17) Userspacce
18) Powersave
19) Performance
1) Ondemand:
Default governor in almost all stock kernels. One main goal of the ondemand governor is to switch to max frequency as soon as there is a CPU activity detected to ensure the responsiveness of the system. (You can change this behavior using smooth scaling parameters, refer Siyah tweaks at the end of 3rd post.) Effectively, it uses the CPU busy time as the answer to "how critical is performance right now" question. So Ondemand jumps to maximum frequency when CPU is busy and decreases the frequency gradually when CPU is less loaded/apporaching idle. Even though many of us consider this a reliable governor, it falls short on battery saving and performance on default settings. One potential reason for ondemand governor being not very power efficient is that the governor decide the next target frequency by instant requirement during sampling interval. The instant requirement can response quickly to workload change, but it does not usually reflect workload real CPU usage requirement in a small longer time and it possibly causes frequently change between highest and lowest frequency.
2) Ondemandx:
Basically an ondemand with suspend/wake profiles. This governor is supposed to be a battery friendly ondemand. When screen is off, max frequency is capped at 500 mhz. Even though ondemand is the default governor in many kernel and is considered safe/stable, the support for ondemand/ondemandX depends on CPU capability to do fast frequency switching which are very low latency frequency transitions. I have read somewhere that the performance of ondemand/ondemandx were significantly varying for different i/o schedulers. This is not true for most of the other governors. I personally feel ondemand/ondemandx goes best with SIO I/O scheduler.
3) Conservative:
A slower Ondemand which scales up slowly to save battery. The conservative governor is based on the ondemand governor. It functions like the Ondemand governor by dynamically adjusting frequencies based on processor utilization. However, the conservative governor increases and decreases CPU speed more gradually. Simply put, this governor increases the frequency step by step on CPU load and jumps to lowest frequency on CPU idle. Conservative governor aims to dynamically adjust the CPU frequency to current utilization, without jumping to max frequency. The sampling_down_factor value acts as a negative multiplier of sampling_rate to reduce the frequency that the scheduler samples the CPU utilization. For example, if sampling_rate equal to 20,000 and sampling_down_factor is 2, the governor samples the CPU utilization every 40,000 microseconds.
4) Interactive:
Can be considered a faster ondemand. So more snappier, less battery. Interactive is designed for latency-sensitive, interactive workloads. Instead of sampling at every interval like ondemand, it determines how to scale up when CPU comes out of idle. The governor has the following advantages: 1) More consistent ramping, because existing governors do their CPU load sampling in a workqueue context, but interactive governor does this in a timer context, which gives more consistent CPU load sampling. 2) Higher priority for CPU frequency increase, thus giving the remaining tasks the CPU performance benefit, unlike existing governors which schedule ramp-up work to occur after your performance starved tasks have completed. Interactive It's an intelligent Ondemand because of stability optimizations. Why??
Sampling the CPU load every X ms (like Ondemand) can lead to under-powering the CPU for X ms, leading to dropped frames, stuttering UI, etc. Instead of sampling the CPU at a specified rate, the interactive governor will check whether to scale the CPU frequency up soon after coming out of idle. When the CPU comes out of idle, a timer is configured to fire within 1-2 ticks. If the CPU is very busy between exiting idle and when the timer fires, then we assume the CPU is underpowered and ramp to max frequency.
5) Interactivex:
This is an Interactive governor with a wake profile. More battery friendly than interactive.
6) Lulzactive:
This new find from Tegrak is based on Interactive & Smartass governors and is one of the favorites.
Old Version: When workload is greater than or equal to 60%, the governor scales up CPU to next higher step. When workload is less than 60%, governor scales down CPU to next lower step. When screen is off, frequency is locked to global scaling minimum frequency.
New Version: Three more user configurable parameters: inc_cpu_load, pump_up_step, pump_down_step. Unlike older version, this one gives more control for the user. We can set the threshold at which governor decides to scale up/down. We can also set number of frequency steps to be skipped while polling up and down.
When workload greater than or equal to inc_cpu_load, governor scales CPU pump_up_step steps up. When workload is less than inc_cpu_load, governor scales CPU down pump_down_step steps down.
Example:
Consider
inc_cpu_load=70
pump_up_step=2
pump_down_step=1
If current frequency=200, Every up_sampling_time Us if cpu load >= 70%, cpu is scaled up 2 steps - to 800.
If current frequency =1200, Every down_sampling_time Us if cpu load < 70%, cpu is scaled down 1 step - to 1000.
7) Lulzactiveq:
Lulzactiveq is a modified lulzactive governor authored by XDA member robertobsc and is adapted in Siyah kernel for GS2 and GS3. Lulzactiveq aims to optimize the second version of luzactive from Tegrak by a) providing an extra parameter (dec_cpu_load) to make scaling down more sensible, and b) incorporating hotplug logic to the governor. Luzactiveq is the first ever interactive based governor with hotplugging logic inbuilt (atleast the first of its kind for the exynos platform). When CPU comes out of idle loop and it's time to make a scaling decision, if load >= inc_cpu_load CPU is scaled up (like original luzactiveq) and if load <dec_cpu_load, CPU is scaled down. This possibly eliminates the strict single cut-off frequency for luzactiveq to make CPU scaling decisions. Also, stand hotplug logic runs as a separate thread with the governor so that external hotplugging logic is not required to control hotplug in and out (turn On and Off) CPU cores in multi core devices like GS2 or GS3. Only a multi core aware governor makes real sense on muti-core devices. Lulzactiveq and pegasusq aims to do that.
8) Smartass:
Result of Erasmux rewriting the complete code of interactive governor. Main goal is to optimize battery life without comprising performance. Still, not as battery friendly as smartassV2 since screen-on minimum frequency is greater than frequencies used during screen-off. Smartass would jump up to highest frequency too often as well.
9) SmartassV2:
Version 2 of the original smartass governor from Erasmux. Another favorite for many a people. The governor aim for an "ideal frequency", and ramp up more aggressively towards this freq and less aggressive after. It uses different ideal frequencies for screen on and screen off, namely awake_ideal_freq and sleep_ideal_freq. This governor scales down CPU very fast (to hit sleep_ideal_freq soon) while screen is off and scales up rapidly to awake_ideal_freq (500 mhz for GS2 by default) when screen is on. There's no upper limit for frequency while screen is off (unlike Smartass). So the entire frequency range is available for the governor to use during screen-on and screen-off state. The motto of this governor is a balance between performance and battery.
10) Intellidemand:
Intellidemand aka Intelligent Ondemand from Faux is yet another governor that's based on ondemand. Unlike what some users believe, this governor is not the replacement for OC Daemon (Having different governors for sleep and awake). The original intellidemand behaves differently according to GPU usage. When GPU is really busy (gaming, maps, benchmarking, etc) intellidemand behaves like ondemand. When GPU is 'idling' (or moderately busy), intellidemand limits max frequency to a step depending on frequencies available in your device/kernel for saving battery. This is called browsing mode. We can see some 'traces' of interactive governor here. Frequency scale-up decision is made based on idling time of CPU. Lower idling time (<20%) causes CPU to scale-up from current frequency. Frequency scale-down happens at steps=5% of max frequency. (This parameter is tunable only in conservative, among the popular governors )
To sum up, this is an intelligent ondemand that enters browsing mode to limit max frequency when GPU is idling, and (exits browsing mode) behaves like ondemand when GPU is busy; to deliver performance for gaming and such. Intellidemand does not jump to highest frequency when screen is off.
11) Lazy:
This governor from Ezekeel is basically an ondemand with an additional parameter min_time_state to specify the minimum time CPU stays on a frequency before scaling up/down. The Idea here is to eliminate any instabilities caused by fast frequency switching by ondemand. Lazy governor polls more often than ondemand, but changes frequency only after completing min_time_state on a step overriding sampling interval. Lazy also has a screenoff_maxfreq parameter which when enabled will cause the governor to always select the maximum frequency while the screen is off.
12) Lagfree:
Lagfree is similar to ondemand. Main difference is it's optimization to become more battery friendly. Frequency is gracefully decreased and increased, unlike ondemand which jumps to 100% too often. Lagfree does not skip any frequency step while scaling up or down. Remember that if there's a requirement for sudden burst of power, lagfree can not satisfy that since it has to raise cpu through each higher frequency step from current. Some users report that video playback using lagfree stutters a little.
13) Lionheart:
Lionheart is a conservative-based governor which is based on samsung's update3 source. Tweaks comes from 1) Knzo 2) Morfic. The original idea comes from Netarchy. See here. The tunables (such as the thresholds and sampling rate) were changed so the governor behaves more like the performance one, at the cost of battery as the scaling is very aggressive.
To 'experience' Lionheart using conservative, try these tweaks:
sampling_rate:10000 or 20000 or 50000, whichever you feel is safer. (transition latency of the CPU is something below 10ms/10,000uS hence using 10,000 might not be safe).
up_threshold:60
down_threshold:30
freq_step:5
Lionheart goes well with deadline i/o scheduler. When it comes to smoothness (not considering battery drain), a tuned conservative delivers more as compared to a tuned ondemand.
14) LionheartX
LionheartX is based on Lionheart but has a few changes on the tunables and features a suspend profile based on Smartass governor.
15) Brazilianwax:
Similar to smartassV2. More aggressive ramping, so more performance, less battery.
16) SavagedZen:
Another smartassV2 based governor. Achieves good balance between performance & battery as compared to brazilianwax.
17) Userspace:
Instead of automatically determining frequencies, lets user set frequencies.
18) Powersave:
Locks max frequency to min frequency. Can not be used as a screen-on or even screen-off (if scaling min frequency is too low).
19) Performance:
Sets min frequency as max frequency. Use this while benchmarking!
Schedulers
Everything has been said about them so I will use droidphile explanations.
Link to original topic: http://forum.xda-developers.com/galaxy-s2/general/ref-kernel-governors-modules-o-t1369817
Q. "What purposes does an i/o scheduler serve?"
A.
Minimize hard disk seek latency.
Prioritize I/O requests from processes.
Allocate disk bandwidth for running processes.
Guarantee that certain requests will be served before a deadline.
So in the simplest of simplest form: Kernel controls the disk access using I/O Scheduler.
Q. "What goals every I/O scheduler tries to balance?"
A.
Fairness (let every process have its share of the access to disk)
Performance (try to serve requests close to current disk head position first, because seeking there is fastest)
Real-time (guarantee that a request is serviced in a given time)
Q. "Description, advantages, disadvantages of each I/O Scheduler?"
A.
1) Noop
Inserts all the incoming I/O requests to a First In First Out queue and implements request merging. Best used with storage devices that does not depend on mechanical movement to access data (yes, like our flash drives). Advantage here is that flash drives does not require reordering of multiple I/O requests unlike in normal hard drives.
Advantages:
Serves I/O requests with least number of cpu cycles. (Battery friendly?)
Best for flash drives since there is no seeking penalty.
Good throughput on db systems.
Disadvantages:
Reduction in number of cpu cycles used is proportional to drop in performance.
2) Deadline
Goal is to minimize I/O latency or starvation of a request. The same is achieved by round robin policy to be fair among multiple I/O requests. Five queues are aggressively used to reorder incoming requests.
Advantages:
Nearly a real time scheduler.
Excels in reducing latency of any given single I/O.
Best scheduler for database access and queries.
Bandwidth requirement of a process - what percentage of CPU it needs, is easily calculated.
Like noop, a good scheduler for solid state/flash drives.
Disadvantages:
When system is overloaded, set of processes that may miss deadline is largely unpredictable.
3) CFQ
Completely Fair Queuing scheduler maintains a scalable per-process I/O queue and attempts to distribute the available I/O bandwidth equally among all I/O requests. Each per-process queue contains synchronous requests from processes. Time slice allocated for each queue depends on the priority of the 'parent' process. V2 of CFQ has some fixes which solves process' i/o starvation and some small backward seeks in the hope of improving responsiveness.
Advantages:
Considered to deliver a balanced i/o performance.
Easiest to tune.
Excels on multiprocessor systems.
Best database system performance after deadline.
Disadvantages:
Some users report media scanning takes longest to complete using CFQ. This could be because of the property that since the bandwidth is equally distributed to all i/o operations during boot-up, media scanning is not given any special priority.
Jitter (worst-case-delay) exhibited can sometimes be high, because of the number of tasks competing for the disk.
4) BFQ
Instead of time slices allocation by CFQ, BFQ assigns budgets. Disk is granted to an active process until it's budget (number of sectors) expires. BFQ assigns high budgets to non-read tasks. Budget assigned to a process varies over time as a function of it's behavior.
Advantages:
Believed to be very good for usb data transfer rate.
Believed to be the best scheduler for HD video recording and video streaming. (because of less jitter as compared to CFQ and others)
Considered an accurate i/o scheduler.
Achieves about 30% more throughput than CFQ on most workloads.
Disadvantages:
Not the best scheduler for benchmarking.
Higher budget assigned to a process can affect interactivity and increased latency.
5) SIO
Simple I/O scheduler aims to keep minimum overhead to achieve low latency to serve I/O requests. No priority quesues concepts, but only basic merging. Sio is a mix between noop & deadline. No reordering or sorting of requests.
Advantages:
Simple, so reliable.
Minimized starvation of requests.
Disadvantages:
Slow random-read speeds on flash drives, compared to other schedulers.
Sequential-read speeds on flash drives also not so good.
6) V(R)
Unlike other schedulers, synchronous and asynchronous requests are not treated separately, instead a deadline is imposed for fairness. The next request to be served is based on it's distance from last request.
Advantages:
May be best for benchmarking because at the peak of it's 'form' VR performs best.
I/O Schedulers
Disadvantages:
Performance fluctuation results in below-average performance at times.
Least reliable/most unstable.
7) Anticipatory
Based on two facts
i) Disk seeks are really slow.
ii) Write operations can happen whenever, but there is always some process waiting for read operation.
So anticipatory prioritize read operations over write. It anticipates synchronous read operations.
Advantages:
Read requests from processes are never starved.
As good as noop for read-performance on flash drives.
Disadvantages:
'Guess works' might not be always reliable.
Reduced write-performance on high performance disks.
reserved
A Mugen 6200 wouldn't hurt either
2SHAYNEZ
---------- Post added at 04:17 PM ---------- Previous post was at 04:14 PM ----------
Also...... Wheatley gov? Not in list.
2SHAYNEZ
shayneflashindaily said:
A Mugen 6200 wouldn't hurt either
2SHAYNEZ
---------- Post added at 04:17 PM ---------- Previous post was at 04:14 PM ----------
Also...... Wheatley gov? Not in list.
2SHAYNEZ
Click to expand...
Click to collapse
Mugen is to big for daily use to me
Will add Wheatley to the list.
Lop but it was a free battery
2SHAYNEZ
Jury duty today meant a lot of screen on time.
shimbob said:
View attachment 3055082
Jury duty today meant a lot of screen on time.
Click to expand...
Click to collapse
so how many hours of screen on time did u get in one charge?
7hours sot
stock phone, stock CM11 12/12. No real tweaks asides stripping out .apks before flashing CM11 and Greenify.
shimbob said:
7hours sot
Click to expand...
Click to collapse
ROM and tweaks ? Extended battery ? More info.
2SHAYNEZ
Well that's kind of cool. 8hrs (of mostly screen off) and 0% battery drain
Nice. I managed to get that during the night also but with airplane mode ON.
I think I have a rogue app eating battery, I only get 2H Screen on time, and it will drain battery without thouching it, I've flashed multiple Roms, I'm going to completely wipe my phone and do a clean install, I remember the first day I got the phone I went all day and still had battery, and that was heavy usage as I was playing with it
SmokeyTech1 said:
I think I have a rogue app eating battery, I only get 2H Screen on time, and it will drain battery without thouching it, I've flashed multiple Roms, I'm going to completely wipe my phone and do a clean install, I remember the first day I got the phone I went all day and still had battery, and that was heavy usage as I was playing with it
Click to expand...
Click to collapse
Maybe you should start all over with flashtooling back to stock. If you can't figure it out.
2SHAYNEZ
shayneflashindaily said:
Maybe you should start all over with flashtooling back to stock. If you can't figure it out.
2SHAYNEZ
Click to expand...
Click to collapse
I installed greenify and snapdragon battery guru, it appears almost all my apps run at startup and stay running, so i hibernated all of them
SmokeyTech1 said:
I installed greenify and snapdragon battery guru, it appears almost all my apps run at startup and stay running, so i hibernated all of them
Click to expand...
Click to collapse
I would avoid snapdragon battery guru, that thing is notoriously bad when it comes to wakelocks. In the end, it probably uses more battery than it saves.
In any case, you need a wakelock detector to pinpoint the source of wakelocks.
4ndroid99 said:
I would avoid snapdragon battery guru, that thing is notoriously bad when it comes to wakelocks. In the end, it probably uses more battery than it saves.
In any case, you need a wakelock detector to pinpoint the source of wakelocks.
Click to expand...
Click to collapse
So after completely wiping my phone and starting over, im sitting here with 13% battery and 2H screen on time, i should add i use a VPN 24/7, and on battery stats the Android OS and Android System use 20% by them selves, so either its something really deep in the phone or my battery is shot
Tuning Battery Life on Samsung Note 3 N900
I don't have a device anymore, but I still wish to share my experience and how I achieved 6 hours SoT with my typical daily usage on this phone.
This guide is for CM12.1 / AICP 10.0 (I recommend latter, it's the same CM 12.1 but with more options).
You can try this settings on aurora/stock ROMs with respective custom kernel (Suemax).
First of all, you need a kernel with Synapse support. This section is for CM12.1/AICP only! Don't try to flash these kernels if you are on Aurora/Stock - you'll have bootloop!
-- Download Stock and DJMax81's V2 kernel from this post and Suemax kernel from this post.
-- Make a backup
-- Flash CM12.1-DJmax81-Kernel-Lite-V2.zip
-- Boot your phone once and open Camera app to ensure it works.
-- Reboot to recovery and flash CM12.1-SueMax-Kernel-V3-By-DJMAX81.zip dirty. No need to wipe cashes.
-- If you encounter issues, restore backup or flash CM12.1-Stock.zip to return to the stock CM12.1 kernel.
Now you can fine-tune your Exynos!
First, disable touchboost. It's some sort of cheating Samsung use to make it's touchwiz not so laggy. On stock Android you simply don't need it, even if you set max CPU to lowly 250 Mhz, Stock Android UX is still decently smooth.
How to do this: open Synapse, go to the QoS tab. There are many, many sliders to control boost in different situations. Slide every one of them to the left. Now you gave full control of your phone freq to the governor.
This setting alone gave me up to 1 hour of SoT when texting or browsing. Because these are not demanding tasks and there's no need for CPU freq to ramp up.
Second, set min GPU speed to 100 MHz. This will save some juice when idle. Go to GPU Control in settings and set the corresponding Min freq slider to 100 MHz, then apply (you need to push the Set GPU settings button and a tick at the right top). You can also adjust Max GPU freq to suit your gaming needs. The more max GPU speed, the better gaming perfomance will be and the worse battery life in games (600 MHz stock value).
Third, let's go to Kernel Adiutor and here are some profiles for you that I found best!
Max Performance profile: Use zzmoove governor, max CPU speed to 1900 MHz, and at advanced governor settings set disable_hotplugging to 1.
Exynos hotplugging has rather negative effect on battery life as I found from my tests, you should never use it. If you are reading this and on Stock/Aurora ROM: disable hotplugging. It makes your battery life worse! Here is the test on Snapdragon 801, on Exynos hotpluging would yield even worse results because CPU with less core active will spend more time on unefficient A15 cores.
Zzmoove is the smoothest and fastest governor I found that still uses all available frequencies wisely.
That's the profile one should use for heavy games (and also set max GPU speed to 720 MHz in Synapse if you need it).
Performance profile: Use Interactive governor and max CPU speed 1900 MHz.
Interactive governor proactively ramps CPU to high (but not highest freq) to ensure great smoothness and still yield not-that-bad battery life (I had usually 4 hours SoT with 2G). For better fine-tuning you can go to advanced governor settings and set hispeed_freq to something in the middle, 800 MHz for example (but not lower than 800). hispeed_freq setting is the intermediate cpu speed which governor uses when there's initial load on cpu.
Balanced profile: Change governor to Ondemand, max CPU speed is still 1900 MHz.
You shouldn't worry, with touchboost disabled it would rarely ramp up to max speed, most often sitting on energy-efficient A7 cores and sometimes ramping to 1200 of A15, going even higher only when needed - still gives you whole power of your device without restrictions. DJMax81 did great job tuning this governor to our needs. You still can set max CPU lower (to 1400 Mhz) if you wish to conserve battery more on this profile.
Power saving profile: Go to Synapse and enable a slight touchboost: on QoS tab set CPU freq touchboost level 1 to 800 MHz (only the first slider). Then in Kernel Adiutor change CPU governor to Interactive. Set Max CPU speed to 1400. Go to advanced governor settings and set hispeed_freq to 400 MHz.
These settings are doing two things:
1. When not in use (e.g. you are not touching your phone), your device will use ONLY energy-efficient A7 cluster. So max 1300 MHz (it shows 650 MHz in Kernel Adiutor because A7 cluster is showing it's real freq divided by 2) with four cores - a performance level of middle-ground MTK device. Most often the phone will use 800 MHz freq of A7 (that's 400 MHz setting of hispeed_freq - a division by 2, remember)
2. When you are using device (actively tapping), touchboost will switch your device to A15 cores (starting from 800 MHz - at this freq they consume roughly same amount of energy as 1300 MHz'd A7) and if needed, interactive governor will ramp the freq even some more - up to 1400 MHz. When there will be no load, freq will drop to the minimum and system will switch to A7 cluster until next time you use it.
Extreme Power Saving profile: Disable touchboost, CPU governor is Interactive. At advanced governor settings set hispeed_freq to 400 MHz.
This makes your phone use ONLY energy-efficient A7 cluster no matter what circumstances. No matter what max CPU freq is set, interactive governor can't switch from A7 cluster to A15 (maybe that's a bug, but we'll use it). You can set max CPU speed to 650 MHz for sure, didn't make a difference for me.
Yes, it may lag. Yes, games are not playable. But we don't paint your screen black and white at least. Movies are fine, texting is fine, browsing too, 1300 MHz of A7 are still quite good - it's like low-end phone but with 3 GB RAM and AMOLED. Combine it with lollipop powersaving mode and GPU powersave bias (set in Synapse, always clocks GPU at 100 MHz). And your phone will go on and on and on...
Don't forget to click thanks button. Tell me your experience. My device is broken so there could be some mistakes. My apologizes. Have a nice day!
First. Thank u sir
Sent from my SM-A9000 using Tapatalk
Dude thank !!!!!!!
Where's Link's My Bro
Send From My N900. Resurrection Mix 5.5.9
hostess79197 said:
Where's Link's My Bro
Send From My N900. Resurrection Mix 5.5.9
Click to expand...
Click to collapse
Kernel Adiutor doesn't make profiles to share. You have to manually set parameters and then save profile for your device. That's only the guide of parameters to use for your needs.
Thanks for sharing.
I'm using TOS (a Chinese rom) now, and I got excellent battery life. The phone is still smooth.
If you're strict with battery life, TOS is really worth trying.
View attachment 3777633
View attachment 3777634
View attachment 3777635
Noyllopa said:
Thanks for sharing.
I'm using TOS (a Chinese rom) now, and I got excellent battery life. The phone is still smooth.
If you're strict with battery life, TOS is really worth trying.
View attachment 3777633
View attachment 3777634
View attachment 3777635
Click to expand...
Click to collapse
wow that battery life looks awesome, where u got the rom?
can u share it?
im still using kitkat rom myself since battery is better than any lollipop rom
ervanthe said:
wow that battery life looks awesome, where u got the rom?
can u share it?
im still using kitkat rom myself since battery is better than any lollipop rom
Click to expand...
Click to collapse
Here’s the download page. http://tos.cn/download/details-4.html
View attachment 3778089
SPEN working. But there‘s no GAPPS, you need to flash it yourself.
looking cool!
Noyllopa said:
Here’s the download page. http://tos.cn/download/details-4.html
View attachment 3778089
SPEN working. But there‘s no GAPPS, you need to flash it yourself.
Click to expand...
Click to collapse
is that rom based on cm or touch wiz? probably cm coz of u mentioned gapps. But spen is working is doubting me that is touchwiz. Also how big is that rom? and is it prerooted?
that battery pics that u showed r awesome!
is it stable to use in everyday?
any lags? and free ram available?
tnx ! cheers!
Anirup =) said:
is that rom based on cm or touch wiz? probably cm coz of u mentioned gapps. But spen is working is doubting me that is touchwiz. Also how big is that rom? and is it prerooted?
that battery pics that u showed r awesome!
is it stable to use in everyday?
any lags? and free ram available?
tnx ! cheers!
Click to expand...
Click to collapse
Based on Touch Wiz. In China google is blocked so there's no gapps.
The rom is already prerooted, you just need to open it in Manage(an app)-Permissons-Root access.
It's 905MB.
Now i'm using it everyday, it's quite stable and smooth. And games (e.g. Hearthstone) are playable.
I don't know how to install Xposed, it errors every time I want to flash it.
As for free ram, I don't know how to check it in this rom.
i want to know that if this kernel works on flyme rom
Sent from my SM-N900 using Tapatalk
Makshow said:
Tuning Battery Life on Samsung Note 3 N900
I don't have a device anymore, but I still wish to share my experience and how I achieved 6 hours SoT with my typical daily usage on this phone.
This guide is for CM12.1 / AICP 10.0 (I recommend latter, it's the same CM 12.1 but with more options).
You can try this settings on aurora/stock ROMs with respective custom kernel (Suemax).
First of all, you need a kernel with Synapse support. This section is for CM12.1/AICP only! Don't try to flash these kernels if you are on Aurora/Stock - you'll have bootloop!
-- Download Stock and DJMax81's V2 kernel from this post and Suemax kernel from this post.
-- Make a backup
-- Flash CM12.1-DJmax81-Kernel-Lite-V2.zip
-- Boot your phone once and open Camera app to ensure it works.
-- Reboot to recovery and flash CM12.1-SueMax-Kernel-V3-By-DJMAX81.zip dirty. No need to wipe cashes.
-- If you encounter issues, restore backup or flash CM12.1-Stock.zip to return to the stock CM12.1 kernel.
Now you can fine-tune your Exynos!
First, disable touchboost. It's some sort of cheating Samsung use to make it's touchwiz not so laggy. On stock Android you simply don't need it, even if you set max CPU to lowly 250 Mhz, Stock Android UX is still decently smooth.
How to do this: open Synapse, go to the QoS tab. There are many, many sliders to control boost in different situations. Slide every one of them to the left. Now you gave full control of your phone freq to the governor.
This setting alone gave me up to 1 hour of SoT when texting or browsing. Because these are not demanding tasks and there's no need for CPU freq to ramp up.
Second, set min GPU speed to 100 MHz. This will save some juice when idle. Go to GPU Control in settings and set the corresponding Min freq slider to 100 MHz, then apply (you need to push the Set GPU settings button and a tick at the right top). You can also adjust Max GPU freq to suit your gaming needs. The more max GPU speed, the better gaming perfomance will be and the worse battery life in games (600 MHz stock value).
Third, let's go to Kernel Adiutor and here are some profiles for you that I found best!
Max Performance profile: Use zzmoove governor, max CPU speed to 1900 MHz, and at advanced governor settings set disable_hotplugging to 1.
Exynos hotplugging has rather negative effect on battery life as I found from my tests, you should never use it. If you are reading this and on Stock/Aurora ROM: disable hotplugging. It makes your battery life worse! Here is the test on Snapdragon 801, on Exynos hotpluging would yield even worse results because CPU with less core active will spend more time on unefficient A15 cores.
Zzmoove is the smoothest and fastest governor I found that still uses all available frequencies wisely.
That's the profile one should use for heavy games (and also set max GPU speed to 720 MHz in Synapse if you need it).
Performance profile: Use Interactive governor and max CPU speed 1900 MHz.
Interactive governor proactively ramps CPU to high (but not highest freq) to ensure great smoothness and still yield not-that-bad battery life (I had usually 4 hours SoT with 2G). For better fine-tuning you can go to advanced governor settings and set hispeed_freq to something in the middle, 800 MHz for example (but not lower than 800). hispeed_freq setting is the intermediate cpu speed which governor uses when there's initial load on cpu.
Balanced profile: Change governor to Ondemand, max CPU speed is still 1900 MHz.
You shouldn't worry, with touchboost disabled it would rarely ramp up to max speed, most often sitting on energy-efficient A7 cores and sometimes ramping to 1200 of A15, going even higher only when needed - still gives you whole power of your device without restrictions. DJMax81 did great job tuning this governor to our needs. You still can set max CPU lower (to 1400 Mhz) if you wish to conserve battery more on this profile.
Power saving profile: Go to Synapse and enable a slight touchboost: on QoS tab set CPU freq touchboost level 1 to 800 MHz (only the first slider). Then in Kernel Adiutor change CPU governor to Interactive. Set Max CPU speed to 1400. Go to advanced governor settings and set hispeed_freq to 400 MHz.
These settings are doing two things:
1. When not in use (e.g. you are not touching your phone), your device will use ONLY energy-efficient A7 cluster. So max 1300 MHz (it shows 650 MHz in Kernel Adiutor because A7 cluster is showing it's real freq divided by 2) with four cores - a performance level of middle-ground MTK device. Most often the phone will use 800 MHz freq of A7 (that's 400 MHz setting of hispeed_freq - a division by 2, remember)
2. When you are using device (actively tapping), touchboost will switch your device to A15 cores (starting from 800 MHz - at this freq they consume roughly same amount of energy as 1300 MHz'd A7) and if needed, interactive governor will ramp the freq even some more - up to 1400 MHz. When there will be no load, freq will drop to the minimum and system will switch to A7 cluster until next time you use it.
Extreme Power Saving profile: Disable touchboost, CPU governor is Interactive. At advanced governor settings set hispeed_freq to 400 MHz.
This makes your phone use ONLY energy-efficient A7 cluster no matter what circumstances. No matter what max CPU freq is set, interactive governor can't switch from A7 cluster to A15 (maybe that's a bug, but we'll use it). You can set max CPU speed to 650 MHz for sure, didn't make a difference for me.
Yes, it may lag. Yes, games are not playable. But we don't paint your screen black and white at least. Movies are fine, texting is fine, browsing too, 1300 MHz of A7 are still quite good - it's like low-end phone but with 3 GB RAM and AMOLED. Combine it with lollipop powersaving mode and GPU powersave bias (set in Synapse, always clocks GPU at 100 MHz). And your phone will go on and on and on...
Don't forget to click thanks button. Tell me your experience. My device is broken so there could be some mistakes. My apologizes. Have a nice day!
Click to expand...
Click to collapse
Hello sir.... I am using sumax v3 karnel with the settings you have mentioned in the thread. Everything is fine... Battery life is great... No problem of heating... Speed is ok but i have facing a problem.... MY PHONE FREEZES RANDOMLY ANY SOLUTION PLEASE HELP. IT FREEZES WHEN SCREEN IS OFF AND I HAVE TO RESTART MY PHONE. I AM USING CYANOGENMOD 12.1. PROBLEM OCCURS ONLY WHEN I USE SUMMAX KARNEL AND PRESCRIBED SETTINGS.
set cpu gov ondemand because its hard to wake up cores on extreme low freq when on sleep mode
Sent from my SM-N900 using Tapatalk 2
Makshow said:
Tuning Battery Life on Samsung Note 3 N900
I don't have a device anymore, but I still wish to share my experience and how I achieved 6 hours SoT with my typical daily usage on this phone.
This guide is for CM12.1 / AICP 10.0 (I recommend latter, it's the same CM 12.1 but with more options).
You can try this settings on aurora/stock ROMs with respective custom kernel (Suemax).
First of all, you need a kernel with Synapse support. This section is for CM12.1/AICP only! Don't try to flash these kernels if you are on Aurora/Stock - you'll have bootloop!
-- Download Stock and DJMax81's V2 kernel from this post and Suemax kernel from this post.
-- Make a backup
-- Flash CM12.1-DJmax81-Kernel-Lite-V2.zip
-- Boot your phone once and open Camera app to ensure it works.
-- Reboot to recovery and flash CM12.1-SueMax-Kernel-V3-By-DJMAX81.zip dirty. No need to wipe cashes.
-- If you encounter issues, restore backup or flash CM12.1-Stock.zip to return to the stock CM12.1 kernel.
Now you can fine-tune your Exynos!
First, disable touchboost. It's some sort of cheating Samsung use to make it's touchwiz not so laggy. On stock Android you simply don't need it, even if you set max CPU to lowly 250 Mhz, Stock Android UX is still decently smooth.
How to do this: open Synapse, go to the QoS tab. There are many, many sliders to control boost in different situations. Slide every one of them to the left. Now you gave full control of your phone freq to the governor.
This setting alone gave me up to 1 hour of SoT when texting or browsing. Because these are not demanding tasks and there's no need for CPU freq to ramp up.
Second, set min GPU speed to 100 MHz. This will save some juice when idle. Go to GPU Control in settings and set the corresponding Min freq slider to 100 MHz, then apply (you need to push the Set GPU settings button and a tick at the right top). You can also adjust Max GPU freq to suit your gaming needs. The more max GPU speed, the better gaming perfomance will be and the worse battery life in games (600 MHz stock value).
Third, let's go to Kernel Adiutor and here are some profiles for you that I found best!
Max Performance profile: Use zzmoove governor, max CPU speed to 1900 MHz, and at advanced governor settings set disable_hotplugging to 1.
Exynos hotplugging has rather negative effect on battery life as I found from my tests, you should never use it. If you are reading this and on Stock/Aurora ROM: disable hotplugging. It makes your battery life worse! Here is the test on Snapdragon 801, on Exynos hotpluging would yield even worse results because CPU with less core active will spend more time on unefficient A15 cores.
Zzmoove is the smoothest and fastest governor I found that still uses all available frequencies wisely.
That's the profile one should use for heavy games (and also set max GPU speed to 720 MHz in Synapse if you need it).
Performance profile: Use Interactive governor and max CPU speed 1900 MHz.
Interactive governor proactively ramps CPU to high (but not highest freq) to ensure great smoothness and still yield not-that-bad battery life (I had usually 4 hours SoT with 2G). For better fine-tuning you can go to advanced governor settings and set hispeed_freq to something in the middle, 800 MHz for example (but not lower than 800). hispeed_freq setting is the intermediate cpu speed which governor uses when there's initial load on cpu.
Balanced profile: Change governor to Ondemand, max CPU speed is still 1900 MHz.
You shouldn't worry, with touchboost disabled it would rarely ramp up to max speed, most often sitting on energy-efficient A7 cores and sometimes ramping to 1200 of A15, going even higher only when needed - still gives you whole power of your device without restrictions. DJMax81 did great job tuning this governor to our needs. You still can set max CPU lower (to 1400 Mhz) if you wish to conserve battery more on this profile.
Power saving profile: Go to Synapse and enable a slight touchboost: on QoS tab set CPU freq touchboost level 1 to 800 MHz (only the first slider). Then in Kernel Adiutor change CPU governor to Interactive. Set Max CPU speed to 1400. Go to advanced governor settings and set hispeed_freq to 400 MHz.
These settings are doing two things:
1. When not in use (e.g. you are not touching your phone), your device will use ONLY energy-efficient A7 cluster. So max 1300 MHz (it shows 650 MHz in Kernel Adiutor because A7 cluster is showing it's real freq divided by 2) with four cores - a performance level of middle-ground MTK device. Most often the phone will use 800 MHz freq of A7 (that's 400 MHz setting of hispeed_freq - a division by 2, remember)
2. When you are using device (actively tapping), touchboost will switch your device to A15 cores (starting from 800 MHz - at this freq they consume roughly same amount of energy as 1300 MHz'd A7) and if needed, interactive governor will ramp the freq even some more - up to 1400 MHz. When there will be no load, freq will drop to the minimum and system will switch to A7 cluster until next time you use it.
Extreme Power Saving profile: Disable touchboost, CPU governor is Interactive. At advanced governor settings set hispeed_freq to 400 MHz.
This makes your phone use ONLY energy-efficient A7 cluster no matter what circumstances. No matter what max CPU freq is set, interactive governor can't switch from A7 cluster to A15 (maybe that's a bug, but we'll use it). You can set max CPU speed to 650 MHz for sure, didn't make a difference for me.
Yes, it may lag. Yes, games are not playable. But we don't paint your screen black and white at least. Movies are fine, texting is fine, browsing too, 1300 MHz of A7 are still quite good - it's like low-end phone but with 3 GB RAM and AMOLED. Combine it with lollipop powersaving mode and GPU powersave bias (set in Synapse, always clocks GPU at 100 MHz). And your phone will go on and on and on...
Don't forget to click thanks button. Tell me your experience. My device is broken so there could be some mistakes. My apologizes. Have a nice day!
Click to expand...
Click to collapse
Hello Where can I go to see the "Kernel Adiutor" whether I need to install it from PlayStore?
SAINI99 said:
set cpu gov ondemand because its hard to wake up cores on extreme low freq when on sleep mode
Sent from my SM-N900 using Tapatalk 2
Click to expand...
Click to collapse
Sir i have been already using ondemand governor but problem priciest i reflashed the rom and usesed with stock karnel for 2 days phone didn't freeze with stok karnel but as i flashed the karnel and set the given values it started freezing again... I want to use the karnel because everything is better than the stock one heating issue is major one with the rom but can be solved by the karnel but how to get rid of freezing problem.
Balraj77712 said:
Hello sir.... I am using sumax v3 karnel with the settings you have mentioned in the thread. Everything is fine... Battery life is great... No problem of heating... Speed is ok but i have facing a problem.... MY PHONE FREEZES RANDOMLY ANY SOLUTION PLEASE HELP. IT FREEZES WHEN SCREEN IS OFF AND I HAVE TO RESTART MY PHONE. I AM USING CYANOGENMOD 12.1. PROBLEM OCCURS ONLY WHEN I USE SUMMAX KARNEL AND PRESCRIBED SETTINGS.
Click to expand...
Click to collapse
Try to increase voltage slightly, +25 mV should be fine. Kernel Adiutor - CPU Voltage - Global at right top. It will not make any effect to battery life. If I remember correctly, Suemax kernel is a bit undervolted by default and if on most phones it's fine, on some it can make issues.
premryp007 said:
Hello Where can I go to see the "Kernel Adiutor" whether I need to install it from PlayStore?
Click to expand...
Click to collapse
You can install it from Play Store, if you don't have one. On my ROM it was just built-in. Synapse should be built-in in kernel, you can update it from Play Store as usual.
Makshow said:
Try to increase voltage slightly, +25 mV should be fine. Kernel Adiutor - CPU Voltage - Global at right top. It will not make any effect to battery life. If I remember correctly, Suemax kernel is a bit undervolted by default and if on most phones it's fine, on some it can make issues.
Sir i have set cpu voltage +25 the problem have been solved by doing so but some time cpu voltage automatically increased and phone start lagging and freezing... Any solution sir.. Thanks in advance.
Click to expand...
Click to collapse
Balraj77712 said:
Sir i have set cpu voltage +25 the problem have been solved by doing so but some time cpu voltage automatically increased and phone start lagging and freezing... Any solution sir.. Thanks in advance.
Click to expand...
Click to collapse
Hmm, can you tell some more about this? I don't even have a clue, how the voltage can be increased automatically and phone start to lagging from more voltage? Usually, it's the contrary: more voltage = more stability for overclock etc.
Makshow said:
Hmm, can you tell some more about this? I don't even have a clue, how the voltage can be increased automatically and phone start to lagging from more voltage? Usually, it's the contrary: more voltage = more stability for overclock etc.
Click to expand...
Click to collapse
Sir i set the cpu voltage by +25. Phone didn't freeze but after a day it freezed again when i checked the cpu voltage after restarting the phone it was the default values i set it by +25 again. After 7-8 hours some apps like Es file Explorer, Whats app, uc browser stopped working (saying like whats app is not responding) i was unable to move some content from phone to sd card. Other functions like settings, dialer etc. Was working. Phone didn't connect to pc. Neither restarted nor power off (restarting and shutting down.) after restarting the cpu voltage was more then the default values. See screenshots sir
Balraj77712 said:
Sir i set the cpu voltage by +25. Phone didn't freeze but after a day it freezed again when i checked the cpu voltage after restarting the phone it was the default values i set it by +25 again. After 7-8 hours some apps like Es file Explorer, Whats app, uc browser stopped working (saying like whats app is not responding) i was unable to move some content from phone to sd card. Other functions like settings, dialer etc. Was working. Phone didn't connect to pc. Neither restarted nor power off (restarting and shutting down.) after restarting the cpu voltage was more then the default values. See screenshots sir
Click to expand...
Click to collapse
Really strange. What ROM do you use? And build date.
I've been reading about some kernel modification staff for couple of days now. I have searched for best kernel governor for Google pixel, there was 2-3 threads and in all of them people stated like "bro you're crazy, don't touch stock sched governor it's the most optimised one for pixel". I was like okay, I won't touch, I get it. But than I saw one thread where users voted for which governors they used, and interactive governor had enormous votes compared to other ones, so I thought there must be the reason for that. After messing up with interactive governor settings, I managed to get about 25-30% more battery life than I had on sched. all this without any noticable decrease in performance. Sched governor rises frequencies so often even if you are just on home screen and simply press empty space, all four CPU cores go to sky at max speed, whereas interactive governor is like quiet intelligent killer who sits and waits for big tasks to go full power. Screenshot below shows my screen on time. Before that, it was somewhere between 3-4 hours. So, any thoughts or links about why I could be wrong and what am I missing - would be very very useful.
Interactive again, this time more optimised.
Levan_i said:
I've been reading about some kernel modification staff for couple of days now. I have searched for best kernel governor for Google pixel, there was 2-3 threads and in all of them people stated like "bro you're crazy, don't touch stock sched governor it's the most optimised one for pixel". I was like okay, I won't touch, I get it. But than I saw one thread where users voted for which governors they used, and interactive governor had enormous votes compared to other ones, so I thought there must be the reason for that. After messing up with interactive governor settings, I managed to get about 25-30% more battery life than I had on sched. all this without any noticable decrease in performance. Sched governor rises frequencies so often even if you are just on home screen and simply press empty space, all four CPU cores go to sky at max speed, whereas interactive governor is like quiet intelligent killer who sits and waits for big tasks to go full power. Screenshot below shows my screen on time. Before that, it was somewhere between 3-4 hours. So, any thoughts or links about why I could be wrong and what am I missing - would be very very useful.
Click to expand...
Click to collapse
So other than changing to interactive governor, which settings did you change?
Arju said:
So other than changing to interactive governor, which settings did you change?
Click to expand...
Click to collapse
Decreased cpu frequencies a bit, also changed some settings inside the interactive gov. Exkernel manager app also helps a lot with blocking wakelocks. Right now, I have small cores set to sched and big cores set to interactive, I guess this variant also will make a good screen on time and better performance. Anything else is the same as it was on sched governor before
Here are the screenshots
Current Sot is 1:30 so at the zero battery it must be somewhere near 4*1:30=6 hours
I suppose I'll stay with sched+interactive governor