Related
I wanted to know what the different governors do, rather than filling dev's threads up with questions I thought i would have a look around and do this for others who like me wanted to know what they do:
1: Interactive
The CPUfreq governor "interactive" is designed for low latency, interactive workloads. This governor sets the CPU speed depending on usage, similar to "ondemand" and "conservative" governors. However there is no polling, or 'sample_rate' required to scale the CPU up. Sampling CPU load every X ms can lead to under powering the CPU for X ms, leading to dropped framerate, stuttering UI etc..Scaling the CPU up is done when coming out of idle, and like "ondemand" scaling up will always go to MAX, then step down based off of cpu load.
There is only one tuneable value for this governor: min_sample_time: The ammount of time the CPU must spend (in uS) at the current frequency before scaling DOWN. This is done to
more accurately determine the cpu workload and the best speed for that workload. The default is 50ms.
2:Min Max
well this governor makes use of only min & maximum frequency based on workload... no intermediate frequencies are used.
3:Smartass
(Quoted from another author http://www.ziggy471.com/2010/11/07/s...-governor-info ) - "is based on the concept of the interactive governor.
I have always agreed that in theory the way interactive works – by taking over the idle loop – is very attractive. I have never managed to tweak it so it would behave decently in real life. Smartass is a complete rewrite of the code plus more. I think its a success. Performance is on par with the “old” minmax and I think smartass is a bit more responsive. Battery life is hard to quantify precisely but it does spend much more time at the lower frequencies.
Smartass will also cap the max frequency when sleeping to 352Mhz (or if your min frequency is higher than 352 – why?! – it will cap it to your min frequency). Lets take for example the 528/176 kernel, it will sleep at 352/176. No need for sleep profiles any more!"
4:Scary
A new governor wrote based on conservative with some smartass features, it scales accordingly to conservatives laws. So it will start from the bottom, take a load sample, if it's above the upthreshold, ramp up only one speed at a time, and ramp down one at a time. It will automatically cap the off screen speeds to 245Mhz, and if your min freq is higher than 245mhz, it will reset the min to 120mhz while screen is off and restore it upon screen awakening, and still scale accordingly to conservatives laws. So it spends most of its time at lower frequencies. The goal of this is to get the best battery life with decent performance. It will give the same performance as conservative right now, it will get tweaked over time.
I assume performance, conservative, powersave and ondemand are self explanatory,
Userspace - finding conflicting info, so if a dev wants to help me out ??
All this info was found on the web in various places, where possible I have quoted where from. If people would like me to link back to them please let me know I will add.
This is purely to help people understand the governors a little without filling dev threads
Can people also leave user feedback on the governors they have been using to give us a reference point to help us all
if it helped hit thanks
Dooms Kernel : http://forum.xda-developers.com/showthread.php?t=1226826
Schedulers post 3
Nice one Chiefy, good to know we have a thread for quick reference when needing it.
Schedulers
NOOP scheduler
The NOOP scheduler inserts all incoming I/O requests into a simple, unordered
FIFO queue and implements request merging.
The scheduler assumes I/O performance optimization will be handled at some
other layer of the I/O hierarchy; e.g., at the block device; by an intelligent
HBA such as a Serial Attached SCSI (SAS) RAID controller or by an externally
attached controller such as a storage subsystem accessed through a
switched Storage Area Network).
NOOP scheduler is best used with solid state devices such as flash memory
or in general with devices that do not depend on mechanical movement to
access data (meaning typical "hard disk" drive technology consisting of seek
time primarily, plus rotational latency). Such non-mechanical devices do not
require re-ordering of multiple I/O requests, a technique that groups together
I/O requests that are physically close together on the disk, thereby reducing
average seek time and the variability of I/O service time.
Deadline
The goal of the Deadline scheduler is to attempt to guarantee a start service time for a request[1]. It does that by imposing a deadline on all I/O operations to prevent starvation of requests. It also maintains two deadline queues, in addition to the sorted queues (both read and write). Deadline queues are basically sorted by their deadline (the expiration time), while the sorted queues are sorted by the sector number.
Before serving the next request, the Deadline scheduler decides which queue to use. Read queues are given a higher priority, because processes usually block on read operations. Next, the Deadline scheduler checks if the first request in the deadline queue has expired. Otherwise, the scheduler serves a batch of requests from the sorted queue. In both cases, the scheduler also serves a batch of requests following the chosen request in the sorted queue.
By default, read requests have an expiration time of 500 ms, write requests expire in 5 seconds.
Anticipatory
Anticipatory scheduling is an algorithm for scheduling hard disk input/output. It seeks to increase the efficiency of disk utilization by "anticipating" synchronous read operations.
"Deceptive idleness" is a situation where a process appears to be finished reading from the disk when it is actually processing data in preparation of the next read operation. This will cause a normal work-conserving I/O scheduler to switch to servicing I/O from an unrelated process. This situation is detrimental to the throughput of synchronous reads, as it degenerates into a seeking workload.[1] Anticipatory scheduling overcomes deceptive idleness by pausing for a short time (a few milliseconds) after a read operation in anticipation of another close-by read requests.[2]
Anticipatory scheduling yields significant improvements in disk utilization for some workloads.[3] In some situations the Apache web server may achieve up to 71% more throughput from using anticipatory scheduling.[4]
The Linux anticipatory scheduler may reduce performance on disks using TCQ, high performance disks, and hardware RAID arrays.[5] An anticipatory scheduler (AS) was the default Linux kernel scheduler between 2.6.0 and 2.6.18, by which time it was replaced by the CFQ scheduler.
BFQ
The Brain **** Scheduler (or BFS) is a task scheduler designed for the Linux kernel in August of 2009 as an alternative to the Completely Fair Scheduler and the O(1) scheduler.[2] BFS was created by veteran kernel programmer Con Kolivas[3].
The objective of BFS, compared to other schedulers, was to provide a scheduler with a simpler algorithm, that did not require adjustment of heuristics or tuning parameters to tailor performance to a specific type of computation workload. The BFS author asserted that these tunable parameters were difficult for the average user to understand, especially in terms of interactions of multiple parameters with each other, and claimed that the use of such tuning parameters could often result in improved performance in a specific targeted type of computation, at the cost of worse performance in the general case.[4] BFS has been reported to improve responsiveness on light-NUMA (non-uniform memory access) Linux mobile devices and desktop computers with fewer than 16 cores.
CFQ
CFQ, also known as "Completely Fair Queuing", is an I/O scheduler for the Linux kernel which was written in 2003 by Jens Axboe.
CFQ works by placing synchronous requests submitted by processes into a number of per-process queues and then allocating timeslices for each of the queues to access the disk. The length of the time slice and the number of requests a queue is allowed to submit depends on the IO priority of the given process. Asynchronous requests for all processes are batched together in fewer queues, one per priority. While CFQ does not do explicit anticipatory IO scheduling, it achieves the same effect of having good aggregate throughput for the system as a whole, by allowing a process queue to idle at the end of synchronous IO thereby "anticipating" further close IO from that process. It can be considered a natural extension of granting IO time slices to a process.
I am testing scary at the mo on stock gb so will edit my post tomorrow bro.
over the next week I will use scary, smartass, ondemand, conservative and interactive and report my findings back here
please all get involved and report back your findings
Can people also post their voltage findings with Dooms new kernel
Scary Report
Phone been on 9h 39m, medium usage, clocking set 128-1113, voltages changed as above post,phone very responsive and no lags, battery remaining 39%, AnTuTu benchmark 2755 linpack 39.
Interactive Report
128-1132 up time 6h 25mins, phone responsive no lag, medium usage 36% left, AnTuTu benchmark 2502 linpack 36 this governor doesnt seem to help battery level very much
6h 25mins and only 36% left? OMG! that's a battery drain!
Well, Quite frankly I went through the governors, Which do you think is better? Can you describe each governor in one word?
I'm on wolf rom with fps uncapped (3.x if i remember well) i haven't upgraded due to the issues pertaining to the users.
Can you just suggest me a good governor based on your experience? Can I get 24 hours of uptime with custom kernels or i still have to wait? ( I know I love OC that we had on 2.2 but looking at the battery drain I'm cautious whether or not to flash the custom kernels )
Thanks for your guide. It's epic!
Neo said:
6h 25mins and only 36% left? OMG! that's a battery drain!
Well, Quite frankly I went through the governors, Which do you think is better? Can you describe each governor in one word?
I'm on wolf rom with fps uncapped (3.x if i remember well) i haven't upgraded due to the issues pertaining to the users.
Can you just suggest me a good governor based on your experience? Can I get 24 hours of uptime with custom kernels or i still have to wait? ( I know I love OC that we had on 2.2 but looking at the battery drain I'm cautious whether or not to flash the custom kernels )
Thanks for your guide. It's epic!
Click to expand...
Click to collapse
so far the best governors that i have used have been Smartass and Scary but i will continue testing the governors and reporting back. Smartass was working great with no o/c for me, i will add this to this test. tomorrow i will test Scary with no o/c
Ok, my conclusions of using the scary gov on my modded stock gb is probally the best my phone has been, nearly all frequencies are being used, had to use min 192 and max 1190 as had a few screen off reboots but once using those settings my no more reboots. Battery life is the best i have had on custom kernel with flat line overnight, 3% loss, with wifi off and hourly updates of email, deep sleep working perfect as it should.
Overall, this is my personal favorite so far, just to add also this is using...
http://doomlord.sylvester20007.com/x10/x10_gb/dk/v02/dk-v02-X-modfxp_xrec.zip
I have not started using v03 of Dooms new kernel because of the good results with v02x.
Samrtass Report
Running Smartass governor uptime 5hours 1minute 128-1132cpu, medium usage, twitter, facebook two calls, brightness and 50%, AnTuTu Benchmark 1569 linpack 31 ( second linpac got WLOD ) battery 69%
Edit 10hours up time 42% battery left
As you can see smartass is a battery friend but performance suffers, although for my usage i find that this is the best governor for me at the minute
further governor tests continue
MIN/MAX Report
I tried to use this governor but it kept causing random reboots so gave up
keep going!!
I know this is missing topic but how would I overclock my x10. If it is, how safe is it?
Sent from my x10 Platinum
om23 said:
I know this is missing topic but how would I overclock my x10. If it is, how safe is it?
Sent from my x10 Platinum
Click to expand...
Click to collapse
From what I have encountered it depends on the age of your phone, it is safe and won't blow you phone up but some models can handle far greater stress. the newer phones tend to be able to overclock higher, all that will happen if you phone cant handle the overclock is you will get the dreaded WLOD and your phone will reboot, then if you have set the speed from boot you may get stuck at boot image, but if that is the case then you use flash tool and reflash
chiefy009 said:
MIN/MAX Report
I tried to use this governor but it kept causing random reboots so gave up
Click to expand...
Click to collapse
Thanks for this thread chiefy009!
I have tried all governors too (on Doom's kernel) and I have different experience to yours, so I thought I'd share.
For me, interactive/ondemand/smartass make the phone VERY choppy, especially while scrolling lists!
On the other hand, minmax gives me the smoothest and fastest results.
And I thought that jumping from Deep Sleep/MIN frequency to MAX frequency, without intermediate steps, would kill my battery but, to my amazement, battery life is very very good, I might say better than any other governor.
When I was using minmax as a module to the stock kernel, I got reboots too,
but since Doom integrated it into his kernel, it's stable as rock!
This is the info I found about this governor:
MinMax Governor (Battery Saver)
This governor will try to minimize the frequency jumps/changes which cause voltage spikes/changes and supposedly drain more battery life
Click to expand...
Click to collapse
Just my 2 cents!
My_Immortal said:
Thanks for this thread chiefy009!
I have tried all governors too (on Doom's kernel) and I have different experience to yours, so I thought I'd share.
For me, interactive/ondemand/smartass make the phone VERY choppy, especially while scrolling lists!
On the other hand, minmax gives me the smoothest and fastest results.
And I thought that jumping from Deep Sleep/MIN frequency to MAX frequency, without intermediate steps, would kill my battery but, to my amazement, battery life is very very good, I might say better than any other governor.
When I was using minmax as a module to the stock kernel, I got reboots too,
but since Doom integrated it into his kernel, it's stable as rock!
This is the info I found about this governor:
Just my 2 cents!
Click to expand...
Click to collapse
Thank you for getting involved, if you have time could you post all your findings on your usage of the governors ?
chiefy009 said:
Thank you for getting involved, if you have time could you post all your findings on your usage of the governors ?
Click to expand...
Click to collapse
Sure thing!
I am on Doom's kernel, which I believe includes all the available governors so far.
Scary Governor
Description coming from the author:
A new governor I wrote based on conservative with some smartass features, it scales accordingly to conservatives laws. So it will start from the bottom, take a load sample, if it's above the upthreshold, ramp up only one speed at a time, and ramp down one at a time. It will automatically cap the off screen speeds to 245Mhz, and if your min freq is higher than 245mhz, it will reset the min to 120mhz while screen is off and restore it upon screen awakening, and still scale accordingly to conservatives laws. So it spends most of its time at lower frequencies. The goal of this is to get the best battery life with decent performance. It will give the same performance as conservative right now, it will get tweaked over time.
Click to expand...
Click to collapse
Performance suffers, in my opinion.
It scales the CPU conservatively, so it is very annoying when playing games
or even syncing to get your Gmails.
Also, and this applies to all governors, speed is decreased when the sampling rate is high. Which means that if the CPU constantly checks for load in order to increase/decrease frequency, that will take its toll both to performance and battery life.
Smartass - Interactive - Ondemand
I am putting those 3 governors in the same category, because at least for me, they functioned very similarly.
What I noticed is that indeed the phone used almost all available frequencies before going to MAX, but the phone was laggy. Especially when scrolling in big lists, interactive and smartass gave me unacceptable performance. Ondemand was a tad better, but still, the phone seemed to "resist" scrolling for a few seconds and then go ahead and finally do it!
Battery life was pretty much the same as stock
(since ondemand is the default governor for stock kernel).
MinMax
As I stated in my previous post, minmax gave me the smoothest and fastest results.
This governor doesn't take intermittent load samples, when it first detects CPU load, aka you start using your phone, it jumps to the max frequency and stays there until you stop using it.
At this point, I want to express my opinion on the subject of "High Freq When Screen On", because many users complain about it, but I beg to differ.
In theory, CPU running at max frequency all the time, is heat generating and/thus battery consuming. Alas, be careful: in theory...
Because practically, when you use your phone, you usually do CPU demanding tasks.
When the phone is in my pocket/bag/drawer/whenever doing nothing, I want to be in Deep Sleep.
When I turn it on to look at the time of if there's any new notification, that lasts 30 secs - 1 minute. What frequency will be used then, is not that important.
When I turn it on to actually do something, I want it to be FAST.
If I can scroll a list faster, if I can open an app faster, then I will be using the phone for less time.
If the CPU is sampling and scaling up conservatively, the phone will be laggy
and I will need more time to accomplish my tasks.
All in all, I am not intimitaded by high frequencies while using the phone.
I would start worrying if I got no Deep Sleep -which isn't the case fortunately.
And my battery life is amazing, I get about 1 day and a few hours more,
with pretty heavy use.
Just my 2 cents on the matter.
Powersave
If you are ever really mad at your X10 and you want to see it struggle and suffer, then this is the governor for you! Enough said!
Performance
Pretty snappy, good for gaming and benchmarking, as it uses only MAX frequency. Not for prolonged use though, because it will ONLY use the max frequency (and Deep Sleep of course).
I'll make sure to make more tests in the future and post more thorough reviews!
Again, thanks for this thread chiefy009!!
My_Immortal said:
Sure thing!
I am on Doom's kernel, which I believe includes all the available governors so far.
Click to expand...
Click to collapse
Are you playing with the voltages at all ? if so could you record your findings for everyone ?
I am currently working through the governor list and then plan on trying to level out some voltages which work well
chiefy009 said:
Are you playing with the voltages at all ? if so could you record your findings for everyone ?
I am currently working through the governor list and then plan on trying to level out some voltages which work well
Click to expand...
Click to collapse
I have undervolted my phone using these values:
128000 Hz - 875 V
192000 Hz - 900 V
245760 Hz - 925 V
384000 Hz - 950 V
460800 Hz - 975 V
576000 Hz - 1000 V
652800 Hz - 1050 V
768000 Hz - 1100 V
844800 Hz - 1150 V
921600 Hz - 1200 V
998400 Hz - 1250 V
The phone runs pretty stable, didn't have a single reboot or WLOD so far (3 days).
Xperia X10i via Tapatalk
I will try those settings for undervolting
Smartass Update
This governor is working wonders for me at the minute, phone been online for 6hours, medium/light usage 128-1132mhz few calls, connected to bluetooth speaker in car, little web usage and twitter and the battery is still on 88%
That is impressive
Spreadsheets for CPU Governors and I/O Schedulers
GOVERNOR RESULTS
I/O SCHEDULERS
Summary of the Results
This is a summary of the six most commonly used governors, listed in order of performance.
Best Performing
#1 - Performance
--- : Use Noop or Deadline
--- : Uses a lot more battery
#2 - SmartassV2
--- : Use Noop or SIO
--- : Good choice if you use a lot of CPU intensive apps
#3 - LulzactiveV2
--- : Use Deadline or Noop
--- : Good choice if you use a lot of CPU intensive apps
--- : Uses a little more battery than SmartassV2
#4 - Lazy
--- : Use Deadline or CFQ
--- : Do not enable SOMF (Screen Off Max Frequency uses more battery)
--- : Good choice if you do not use CPU intensive apps
#5 - Ondemand
--- : Use Noop or Deadline
--- : Good choice if you do not use CPU intensive apps
--- : Saves slightly more battery than Lazy
#6 - Conservative
--- : Use CFQ or Noop
--- : Generally one of the worst governors for saving battery, see next post for why.
Check my summary in the Battery Drain thread for more info about how to save battery.
Where did the other benchmarks go?
All ICS ROM Benchmarks: this thread
Kernel Features and Benchmarks: this thread
Battery drain: this thread
Power Saving Governors: this thread
Thanks to all the developers.
Conservative Not Saving Power?
chickelnoodensoup said:
Is the summary in the first post correct with regard to conservative? Is it really "Generally one of the worst governors for saving battery"? Interesting.
Click to expand...
Click to collapse
I know it seems a little odd. It's because a lot of developers seem to have tweaked conservative to make it feel snappier, but it has resulted in more CPU time at the top frequency.
If you take a look at my new spreadsheet: http://goo.gl/ThVzX
...you can see conservative always uses more power when the screen is on (at least for the four kernels I tested).
There is just one exception where conservative saves more power than other governors, and that is when the screen is off, music is on, deep idle is on, and this only applies specifically to Air Kernel. PLEASE NOTE: Steve Garon does not include deep idle, but is working on it, neither does Eugene, but I've asked him to consider it. For these two kernels, if you are listening to music with the screen off, currently, the best power saving governor is Ondemand.
For people who don't use their phone while off, and don't use many intensive apps, Ondemand is the best power saving choice.
For people who use a lot of CPU intensive apps, SmartassV2 will be the better choice. It will scale more agressively, help prevent lags, and save energy being wasted through these delays.
If you listen to music with the screen off, and your kernel supplies deep idle, the best power saving governor is SmartassV2 (except for the case of Air Kernel, see above). This is because it keeps the CPU close to the most efficient frequency: 400MHz.
I hope that covers anything. If I've made any glaring errors in my reasoning, please let me know.
Choosing a Governor
Variety is the spice of life, so try them all! While Mathkid95 swears by Ondemand, developers Eugene373, morfic, and steve.garon all vetted this work and agreed that the highest performing CPU governor is likely to offer battery savings through the race-to-idle principal. Eugene added that finding the right I/O scheduler to combine with your governor will make a big difference too. Extra thanks to Steve for providing the kernel on which I based this test, and all his valuable input! The I/O scheduler for the test was cfq, and note: governors have settable parameters which may vary between developers.
Choosing a Scheduler
I/O schedulers perform differently depending on the governor you are using. I've investigated this using the six most popular CPU governors (vote here) vs the six available I/O schedulers in Eugene's kernel, and the four available in r_data's kernel. All governors are based on either ondemand, interactive, or conservative. Recommended reading is available here: schedulers also for governors
Schedulers tested against these popular governors:
SmartassV2 - interactive variant, and winner of the governor test.
LulzactiveV2 - interactive variant
Lazy - Ezekeel's governor, ondemand variant
Performance - included as a reference for high scores
Ondemand
Conservative
Testing Methodology
To test the kernels I want a fair environment, so any differences in the results are down to the kernel, and nothing else. To achieve this I first make sure I have a clean system:
1) Format /system and /cache and wipe dalvic
2) Install the ROM, install the kernel
3) Boot up, use nstools to select deadline for I/O scheduler
4) Then select a CPU governor and I/O scheduler depending on the test at hand
5) Titanium Backup to restore all my benchmark programs (app only). Set everything to off, no gps, no sync, no BT, airplane mode. Force GPU rendering is selected. Wifi is on for connecting to the benchmark servers. A power adaptor is in use so the battery is always full.
Then I begin testing.
For the CPU Governor Comparison study:
6) Power off and power back up. When lock screen arrives, wait one minute to settle the system, i.e. until screen auto-off. Count to three. Unlock, and begin testing, recording all scores. Start over with all the tests. Record those scores. (I now have two sets of scores for all the benchmarks to create a mean for improved accuracy). Then select next governor, power off and on, and start the cycle again.
For the I/O Scheduler Comparison study:
6) Power off and power back up. For each new scheduler I completed one test which I did not record, just to ensure that the program was properly cached in the system. I then recorded the subsequent ten results. After ten results, I would select the next scheduler, until I had finished all six, then I would also select the next governor and go back to the first scheduler. I repeated this cycle until I had collected data for performance, and the three other main governor types.
Statistics in the scheduler study are a little different to the other tests. They combine overall performance scores with overall variance scores (where lower is better). The formula is
a= Database IO score - 3 standard deviations
b= Write speed - 3 standard deviations
c= Read speed - 3 standard deviations
score=(a*b*c) to the power of 1/3
If you multiply three values together, and take the cube root (same as raising to 1/3) then you arrive at the geometric mean. This type of mean allows the comparison of two different schedulers based not just on their performance, but also how consistent in that performance they are. That score is then compensated by adjusting by half of the percentage discrepancy between the mean and median. For most scores that is an adjustment of less than 1%.
Summary of the Results
SmartassV2 won the governor benchmarks, and also performed well in the battery drain benchmarks.
The best I/O scheduler to combine with this is noop.
This is the combination I personally prefer. However, this is merely my opinion, based on my tests. Mathkid95 prefers ondemand. At the time of writing, Steve Garon and Franco prefer their own tweaked versions of conservative. (My tests indicate CFQ is the best match for conservative.)
Nice work on this!
bedalus said:
Summary of the Results
SmartassV2 won the governor benchmarks, and also performed well in the battery drain benchmarks.
The best I/O scheduler to combine with this is noop.
This is the combination I personally prefer. However, this is merely my opinion, based on my tests. Mathkid95 prefers ondemand. At the time of writing, Steve Garon and Franco prefer their own tweaked versions of conservative. (My tests indicate CFQ is the best match for conservative.)
Click to expand...
Click to collapse
Im also prefer smartassv2+noop. Really good combination
Very usefull, Thanks
Surnom said:
Very usefull, Thanks
Click to expand...
Click to collapse
No problem. If anyone is wondering why so few posts, it's because I recently separated this work away from my kernel benchmarking thread. Feel free to feedback.
bedalus said:
Summary of the Results
SmartassV2 won the governor benchmarks, and also performed well in the battery drain benchmarks.
The best I/O scheduler to combine with this is noop.
This is the combination I personally prefer. However, this is merely my opinion, based on my tests. Mathkid95 prefers ondemand. At the time of writing, Steve Garon and Franco prefer their own tweaked versions of conservative. (My tests indicate CFQ is the best match for conservative.)
Click to expand...
Click to collapse
Never kneww that SmartassV2 works best with noop! I used to have it with deadline. Now experiencing the best experience ever!
using Franco BFS Nov 1st
Thanks man! Thanks Franco!
SmartassV2/Noop +1
UPDATE: Steve had a rethink of his Conservative governor parameters, and I've updated the table to include this. Check column L.
Lower scores are natural with conservative. This time, with the new parameters, the scores are even lower. This indicates that the new conservative is throttling the frequencies more aggressively, but it should also be noted that this governor feels much more responsive than the previous incarnation.
Note - the IO score shows a great improvement, but this is due only to a boost in database IO through the recent FSYNC patch. Make sure you use stable voltages to avoid reboots and potential data loss. (No benefit to UV anyway - check the results of my battery study, see link above.)
thx mate! You do a great job!
Sent from my Nexus S using Tapatalk
Some serious work been put into this.. Anyway of listing governors in respect of there performance then a list of governors for best battery life and the recommended I/O schedulers to accompany them. I know the graph is there but it'll be easier for people like me (not so good with cpu settings) to just simply apply from a high to low list which indicates best performance or more battery life. I'm getting great battery life and decent performance using ondemand with noop but it eats battery a lot more when phone is in use compared to other combinations I've tried.
Sent from my HTC Desire S using XDA App
bedalus said:
Summary of the Results
SmartassV2 won the governor benchmarks, and also performed well in the battery drain benchmarks.
The best I/O scheduler to combine with this is noop.
Click to expand...
Click to collapse
Is it just me or does the spreadsheet say deadline is best with SmartassV2 with noop second?
dabado said:
Some serious work been put into this.. Anyway of listing governors in respect of there performance then a list of governors for best battery life and the recommended I/O schedulers to accompany them. I know the graph is there but it'll be easier for people like me (not so good with cpu settings) to just simply apply from a high to low list which indicates best performance or more battery life. I'm getting great battery life and decent performance using ondemand with noop but it eats battery a lot more when phone is in use compared to other combinations I've tried.
Sent from my HTC Desire S using XDA App
Click to expand...
Click to collapse
Good idea. I will try to do it today.
kernels ; battery ; ROM ; gov/sched
Thaks to your recommend, I use noop + SmartassV2.
I used cfq+tweaked conservative before that set, but I can't feel differece and battery life (I don't know this phrase mean but I'm saying it is very good!)
UPDATE: First post edited. Now summarises all findings. Also, makes it easier to read if you are using the XDA app
Thank you !
Bedalus, I did a little amateur test today.
I played some music with not-too-loud volume.
I keep my data ON, everything else is off.
The screen is always ON with lowest brightness because I'm looking at the CPU frequency used.
CPU min 200, max 1000.
I went to Processor settings and look at the CPU frequency used at the moment.
When I selected Conservative and let it stay for 10 seconds, the CPU freq is showing 1000 constant.
Then I selected Lazy and let it stay for another 10 seconds, the CPU freq is 400 constant.
With SmartassV2, let it stay for 10 seconds, the CPU freq is randomly jumping from 200, 400 and sometimes 1000.
Well my question is, shouldn't Conservative be constantly using the lowest frequency among the other governors?
From what I saw it is Lazy which constantly used the lowest.
What do you think?
I know this test is not reliable at all, so sorry if it's just a waste of time.
glennkaonang said:
Bedalus, I did a little amateur test today.
I played some music with not-too-loud volume.
I keep my data ON, everything else is off.
The screen is always ON with lowest brightness because I'm looking at the CPU frequency used.
CPU min 200, max 1000.
I went to Processor settings and look at the CPU frequency used at the moment.
When I selected Conservative and let it stay for 10 seconds, the CPU freq is showing 1000 constant.
Then I selected Lazy and let it stay for another 10 seconds, the CPU freq is 400 constant.
With SmartassV2, let it stay for 10 seconds, the CPU freq is randomly jumping from 200, 400 and sometimes 1000.
Well my question is, shouldn't Conservative be constantly using the lowest frequency among the other governors?
From what I saw it is Lazy which constantly used the lowest.
What do you think?
I know this test is not reliable at all, so sorry if it's just a waste of time.
Click to expand...
Click to collapse
It sounds like quite an interesting test. I'm surprised at the conservative result. Which kernel are you on?
Spreadsheet of Governor Power Use
BENCHMARK DATA
Summary
Out of the five most popular governors (ondemand, conservative, smartassV2, lazy, and lulzactiveV2) which one can save the most battery?
Total power use is calculated from the mA drain at the frequency x the %age of time spent at that frequency. mA drain figures available here.
Best Power Saving Governors
Best for Screen ON: Ondemand
Best Screen ON + performance: SmartassV2
- Good choice if you need a performance governor with some power saving
- SmartassV2 is also the winner of the governor benchmark: here.
What about when my Screen is OFF?
Best Governor for Screen OFF
Without Deep Idle: Same as Screen ON > Ondemand
With Deep Idle: Any governor...
...now it get's technical...
...Why 'any'? If you look at the spreadsheet, on average, with music ON and the screen OFF, the difference between the best (smartassV2) and worst drain (lazy) is 0.05mA (a tiny amount). Harrb already did a 10 hour test to establish how much each governor drains the battery while using deep idle:
Harbb's spreadsheet
Here's two of Harbb's results (phone's own stats for battery drain with matr1x):
- 23% - Lazy with DI
- 15% - SmartassV2 with DI (35% more efficient)
And my results (mA drain using matr1x):
- 0.30mA - Lazy with DI
- 0.24mA - SmartassV2 with DI (20% more efficient)
Harbb's result is the most reliable, as my original battery drain mA readings were all somewhat approximated due to the difficulties of reading accurately off a small scale on the analogue amp meter, especially when the scale is logarithmic and the mA drain is in the lower register. This means, if I assume my Smartass mA reading is correct, then my Lazy reading should be 0.405mA
While playing music, with the screen off, with DI enabled,
over a period of 1 hour:
a constant drain of 0.240mA = 864mA
a constant drain of 0.405mA = 1458mA
So choosing SmartassV2 over Lazy would prevent about 600mA being wasted in one hour. To put this in context, that is enough to power your screen for 3 seconds (assuming a drain of 200mA).
Since it will take about 3 seconds to change your governor, in practice, it would be a waste of effort to bother. Pick your preferred governor for screen ON, and don't worry about what happens while the screen is off (again, only if you have deep idle. If you don't, but want some power savings with the screen off, choose ondemand).
F.A.Q.
[Q] But Harbb's data clearly shows that the battery drain is much better under smartassV2. How can you say governor choice doesn't make a difference?
[A] Harbb's result is an 8% benefit over ten hours, so in one hour it's a 0.8% benefit. It's not a very practical amount.
For more battery saving tips, see my battery drain thread: here.
Where did the other benchmarks go?
Battery Drain Benchmarks: this thread
All ICS ROM Benchmarks: this thread
Kernel Features and Benchmarks: this thread
CPU Governors and I/O Schedulers: this thread
These tests were based on an the procedure first used by XDA user glennkaonang. Credit and thanks to Glenn. Thanks to r_data, mathkid95, steve.garon, and eugene373 for their kernels.
Conservative is not the Best
When the screen is ON, i.e. the phone is in active use. Generally Conservative does not save power. This is because most developers have included a tweaked version of conservative that keeps the frequency at its highest state for longer to improve the responsiveness.
There is one exception where conservative saves more power than other governors, and that is when the screen is off, music is on, deep idle is on, and this only applies specifically to Air Kernel. However, we are talking about a tiny amount of power (for more detail, see the first post.)
PLEASE NOTE: Steve Garon does not include deep idle, but is working on it, neither does Eugene, but I've asked him to consider it. For these two kernels, if you are listening to music with the screen off, currently, the best power saving governor is Ondemand.
Governor Parameters per Kernel
SG-NS-ICS (11th FEB TEST VERSION)
-Conservative
Sampling Rate: 40000
Up Threshold: 80
Down Threshold: 20
Ignore Nice Load: 0
Freq Step: 5
Sampling down factor: 1
-Ondemand
Sampling Rate: 40000
Up Threshold: 95
Ignore Nice Load: 0 (settable in SetCPU)
Powersave Bias: 0
Sampling down factor: 1
-SmartassV2
Awake ideal freq: 800000
Sleep ideal freq: 100000
Sleep wakeup freq: 99999999
Min CPU load: 25
Max CPU load: 50
Ramp down step: 256000
Ramp up step: 256000
Down rate: 99000
Up rate: 48000
-LulzactiveV2
Inc CPU load: 60
Pump up step: 1
Pump down step: 1
Screen off min step: 3 @400
Up sample time: 20000
Down sample time: 40000
MAT1X v17.0
-Conservative
Sampling Rate: 40000
Up Threshold: 80
Down Threshold: 20
Ignore Nice Load: 0
Freq Step: 5
Sampling down factor: 1
-Ondemand
Sampling Rate: 40000
Up Threshold: 95
Ignore Nice Load: 0 (settable in SetCPU)
Powersave Bias: 0
Sampling down factor: 1
-SmartassV2
Awake ideal freq: 768000
Sleep ideal freq: 245000
Sleep wakeup freq: 99999999
Min CPU load: 25
Max CPU load: 50
Ramp down step: 256000
Ramp up step: 256000
Down rate: 99000
Up rate: 48000
-LulzactiveV2
Inc CPU load: 60
Pump up step: 1
Pump down step: 1
Screen off min step: 5 @400
Up sample time: 20000
Down sample time: 40000
ICUP SPEEDY-7
-Conservative
Sampling Rate: 39062
Up Threshold: 70
Down Threshold: 30
Ignore Nice Load: 0
Freq Step: 5
Sampling down factor: 1
-Ondemand
Sampling Rate: 30000
Up Threshold: 95
Ignore Nice Load: 0 (settable in SetCPU)
Powersave Bias: 0
Sampling down factor: 1
-SmartassV2
Awake ideal freq: 800000
Sleep ideal freq: 100000
Sleep wakeup freq: 99999999
Min CPU load: 25
Max CPU load: 50
Ramp down step: 256000
Ramp up step: 256000
Down rate: 99000
Up rate: 48000
-LulzactiveV2 (not settable in NSTools, checked /sys/devices/system/cpu/cpufreq/lulzactive/)
Inc CPU load: 90
Pump up step: 4
Pump down step: 1
Screen off min step: 6 @400
Up sample time: 10000
Down sample time: 40000
AIR KERNEL 3.0 (TEST VERSION)
-Conservative
Sampling Rate: 20000
Up Threshold: 60
Down Threshold: 20
Ignore Nice Load: 0
Freq Step: 5
Sampling down factor: 1
-Ondemand
Sampling Rate: 40000
Up Threshold: 95
Ignore Nice Load: 0 (settable in SetCPU)
Powersave Bias: 0
Sampling down factor: 10
-SmartassV2
Awake ideal freq: 800000
Sleep ideal freq: 100000
Sleep wakeup freq: 99999999
Min CPU load: 25
Max CPU load: 50
Ramp down step: 256000
Ramp up step: 256000
Down rate: 99000
Up rate: 48000
-LulzactiveV2
Inc CPU load: 60
Pump up step: 1
Pump down step: 1
Screen off min step: 5 @400
Up sample time: 20000
Down sample time: 40000
The I/O Scheduler Selections
I selected the likely/proven best I/O scheduler for each kernel and governor combination, based on my previous work here: http://goo.gl/iJXWI
-SG-NS-ICS and Matr1x
Conservative: cfq
Ondemand: noop
SmartassV2: noop
LulzactiveV2: deadline
Lazy: deadline
For these two it's a little different in places:
-ICUP Speedy-7
Conservative: cfq
Ondemand: deadline*
SmartassV2: deadline*
LulzactiveV2: cfq*
Lazy: deadline
-Air Kernel
Conservative: deadline*
Ondemand: noop
SmartassV2: sio*
LulzactiveV2: noop*
Lazy: deadline
I've emboldened and marked with an * where the differences are.
UPDATE: Summary now includes more detail.
I was unable to complete the necessary details and caveats when I first opened the thread as I desperately needed sleep! Hopefully someone can check over my conclusions and make sure they all add up.
bedalus said:
UPDATE: Summary now includes more detail.
I was unable to complete the necessary details and caveats when I first opened the thread as I desperately needed sleep! Hopefully someone can check over my conclusions and make sure they all add up.
Click to expand...
Click to collapse
Awesome Benchmark again bedalus. Very instructive
I would add these points to the conclusions:
- There is a big difference in governors power consumption when screen is on (more than 10 mA between the best and the worst against a small 0.05 mA difference when screen is off)
- Conservative is the worst governor for screen on usage according to the benchmarks (Taking this point with reserves because conservative was tweaked by kernel developers).
- If we have a high "screen on" usage, onDemand will save us so much power
- If we have a low "screen on" usage, it should be better using SmartassV2 and have the best performance for the little time we use the phone
Waiting for your feedback on this bedalus.
Bedalus is loving benchmarking too much that sometimes, he tries to benchmark his benchmarks
tchaari said:
Awesome Benchmark again bedalus. Very instructive
I would add these points to the conclusions:
- There is a big difference in governors power consumption when screen is on (more than 10 mA between the best and the worst against a small 0.05 mA difference when screen is off)
- Conservative is the worst governor for screen on usage according to the benchmarks (Taking this point with reserves because conservative was tweaked by kernel developers).
- If we have a high "screen on" usage, onDemand will save us so much power
- If we have a low "screen on" usage, it should be better using SmartassV2 and have the best performance for the little time we use the phone
Click to expand...
Click to collapse
0.05mA difference: good point. I should probably mention that in the OP.
Yeah, conservative sucked pretty badly on all four of the kernels. Weird.
For me, all I do now is use my phone to check XDA, and I don't use it with the screen off, so I can save power with ondemand. But smartassV2 is provides a very smooth experience. What do I want more? Battery life or smoothness? Hmm... decisions, decisions...
EDIT: Just noticed your benchmark benchmark idea. Only if I am not sleeping.
bedalus said:
0.05mA difference: good point. I should probably mention that in the OP.
Click to expand...
Click to collapse
If you found that the last two points are useful, can you also integrate them in the OP too?
bedalus said:
Yeah, conservative sucked pretty badly on all four of the kernels. Weird
Click to expand...
Click to collapse
Yes it was a surprise to me too but when joining your benchmark results and the theoretical basics of conservative, it all makes sense. Conservative is taking too much time to compute a task (scaling up slowly). It also scales down too slowly when finishing. This is noticeable especially in discontinued use like browsing.
bedalus said:
For me, all I do now is use my phone to check XDA, and I don't use it with the screen off, so I can save power with ondemand. But smartassV2 is provides a very smooth experience. What do I want more? Battery life or smoothness? Hmm... decisions, decisions...
Click to expand...
Click to collapse
I don't think that you can "feel" the performance difference between ondemand and smartassV2 in such tasks. it should be better to stick to ondemand in this case I think
Yeah, testing ondemand now, back on slim ics, feels the same as smartass.
I'll look at the OP tomorrow, early night for me today.
kernels ; battery ; ROM ; gov/sched
bedalus said:
Yeah, testing ondemand now, back on slim ics, feels the same as smartass.
I'll look at the OP tomorrow, early night for me today.
Click to expand...
Click to collapse
I hope you will sleep smoothly now that this benchmark is finished
Can you indicate what schedulers you use for each of the governors? In my experience schedulers also have an effect to battery life so it'd be good to see whether they're the same or different.
nice work.. AGAIN
so this explains why im happiest with ondemand.
deetailed said:
Can you indicate what schedulers you use for each of the governors? In my experience schedulers also have an effect to battery life so it'd be good to see whether they're the same or different.
Click to expand...
Click to collapse
You could visit bedalus' other benchmark thread http://forum.xda-developers.com/showthread.php?t=1478418&page=1 and see which fits your taste best.
Anyway, great job on this new benchmark thread, bedalus.
I can't believe that you would actually go further on this.
Looking at your results, the best for me would be ondemand.
I rarely used my phone, only for messaging and XDA-ing , so most of the time the screen is off.
And as tchaari said, I couldn't see any difference between ondemand and smartassV2 in terms of performance.
Once again, thanks bedalus
Frankly, I thought everything that could be benchmarked already was. However, this data proves even more useful! Thanks, bedalus.
Now there is nothing left to tweak on my phone!
AeroEchelon said:
Frankly, I thought everything that could be benchmarked already was. However, this data proves even more useful! Thanks, bedalus.
Now there is nothing left to tweak on my phone!
Click to expand...
Click to collapse
There is ALWAYS more to tweak on our phones
Good work bedalus, your lack of sleep truly amazes me. I think we can enhance this a bit more by messing around a little with modified conservatives though. It shouldn't be very difficult at all to scale it down far quicker. I'm doing a couple of usage tests with various conservative settings and will let you know if i get any setups that may fit the bill.
As we know, conservative can easily give better performance than ondemand if told to, but i reckon we can get the best of both worlds. Does anyone know where i'd be looking to find the defaults of each governor in the kernel source? Saves me kernel crackflashing.
deetailed said:
Can you indicate what schedulers you use for each of the governors? In my experience schedulers also have an effect to battery life so it'd be good to see whether they're the same or different.
Click to expand...
Click to collapse
To save me trying to copy and paste on my phone this early on the morning, just follow the link below to gov/sched and you'll see a summary in the first post about which scheduler goes best with which governor, e.g. ondemand and noop.
kernels ; battery ; ROM ; gov/sched
simms22 said:
nice work.. AGAIN
so this explains why im happiest with ondemand.
Click to expand...
Click to collapse
Does morfic tweak on demand, I can't remember, I think I read it somewhere... ?
For completeness, and to save Harbb from becoming an emaciated crackflasher like us, I might just go through all the governers for each kernel I tested and note their settings down in the third post.
bedalus said:
To save me trying to copy and paste on my phone this early on the morning, just follow the link below to gov/sched and you'll see a summary in the first post about which scheduler goes best with which governor, e.g. ondemand and noop.
kernels ; battery ; ROM ; gov/sched
Click to expand...
Click to collapse
I think he was asking which scheduler you used with this benchmark. I'd bet it's deadline.
edit: bedalus, at least give me a couple of kernels to do and i'll note them down. You've had enough fun
bedalus said:
To save me trying to copy and paste on my phone this early on the morning, just follow the link below to gov/sched and you'll see a summary in the first post about which scheduler goes best with which governor, e.g. ondemand and noop.
kernels ; battery ; ROM ; gov/sched
Click to expand...
Click to collapse
Ah, I don't mean to ask what scheduler is recommended for each governor (because I've already got that info from your gov/sched thread ). Like Harbb said, I'm just asking that the specific scheduler used in this battery-saving benchmark is mentioned, whether you use the recommended for each or use the same scheduler for all of them (also I'm a she, not he ). Every phone is different and usage habits vary too, so I like to replicate the setup of benchmark winners to see if what you find best is best for me too.
My apologies deetailed. At least i got something right
As i said before, it is most likely deadline that was used since it has very uniform capabilities with each governor. Clarification would definitely be nice though, lack of sleep can do weird things.
tchaari said:
I don't think that you can "feel" the performance difference between ondemand and smartassV2 in such tasks. it should be better to stick to ondemand in this case I think
Click to expand...
Click to collapse
After repeatedly flashing all the kernels, ROMs, and trying all the governor / scheduler combinations that are possible, I've become attuned to the device. For some people they may 'feel' the difference intuitively, others might imagine a difference. But for me, I've had over ten years of practice in timing tiny fractions of a second, all thanks to sound engineering. For example, I used to add Haas delays to close mic'ed instruments to simulate 'early reflections', giving the psychoacoustic impression of greater depth and imagining to these instruments in the mix. These delays are anywhere from 5ms to 40ms.
For me, smartassV2 will always go from input on the touchscreen to an animated transition virtually instantaneously, but with ondemand, if you are coming from an idle state, there is always a little delay. It's tiny, maybe 100ms, but for a sound engineer, 100ms is a huge gulf.
Ok it's been so long and for the love of God! I still see a lot of users posting about how horrible their battery lives are. So, here are a couple of guides that I found. I'm copy pasting them here because (1) I find them very informative and (2) I can agree with the information provided from my experience. And hopefully you find it helpful too.
Please follow the original thread and thank bedalus for all his time and effort!
Governor And I/O Scheduler Studies
Direct Copy Paste---I TAKE NO CREDIT---Original Thread Here:http://forum.xda-developers.com/showthread.php?t=1470247
bedalus said:
Spreadsheets for CPU Governors and I/O Schedulers
GOVERNOR RESULTS
I/O SCHEDULERS
Summary of the Results
This is a summary of the six most commonly used governors, listed in order of performance.
Best Performing
#1 - Performance
--- : Use Noop or Deadline
--- : Uses a lot more battery
#2 - SmartassV2
--- : Use Noop or SIO
--- : Uses a little more battery
#3 - LulzactiveV2
--- : Use Deadline or Noop
--- : Uses a lot more battery
#4 - Lazy
--- : Use Deadline or CFQ
--- : Helps save battery as long as SOMF is not enabled
#5 - Ondemand
--- : Use Noop or Deadline
--- : Helps save battery
#6 - Conservative
--- : Use CFQ or Noop
--- : Helps save battery
Check my summary in this thread for more info about how to save battery.
Thanks to all the developers.
Caveats
The most important thing to remember is that the testing hardware is a nexus s. Although I believe they are essentially the same device, there may be differences in how the galaxy s hardware affects performance. Do some experimenting yourself, and if it feels right, go with it!
Click to expand...
Click to collapse
--------------------------------------
Battery Saving Tips
Direct Copy Paste --- I TAKE NO CREDIT --- Original Thread Here: http://forum.xda-developers.com/showthread.php?p=22126792#post22126792
bedalus said:
Spreadsheet of the Battery Drain Data
BATTERY DRAIN BENCHMARKS
VIDEO of how it's done! (Do NOT try it yourself!)
NEW: Lab study done by nathanson666 see here and featured on the XDA's portal and twitter here.
Summary of Results
#1 - With screen on, if the processor is Idle, 100MHz saves the most power.
#2 - Regardless of your choice of governor, even with extreme undervolting, you are not going to be able to increase your battery life by more than 2%. (Click here for explanation.)
For the instability introduced by UV, it seems a 2% increase in battery life isn't really worth it! REMEMBER rebooting uses so much power, a single one would more than undo any savings made by UV.
#3 - The most power saving governor is Ondemand. If you need a high performance governor, use smartassV2, which offers some battery savings.
#4 - This is one point that everyone ought to know, but I'm including because many people seem to believe in myths: if the screen is off, and the CPU is not active, neither deep idle nor UV will have any impact on battery life.
#5 - The matr1x kernel by mathkid95 mainly saves power through UV of the INT voltages. You may need to raise these if you have freezes/reboots with your phone (in addition to raising the ARM voltages). I found that a maximum of 1 mA can be saved through INT UV, regardless of whether the CPU becomes idle (or with screen off in deep idle), so this is a constant saving. However, it is a very small saving, and doesn't apply if the phone is asleep. Remember, reboots cost more juice than UV can ever save.
#6 - If you have an amoled display, black saves a great deal of power. After that, red. If you have a black and red theme, this is saving you power!
#7 - If you are determined to UV, I found that my phone would become unstable with UV settings that were fine when the battery was fully charged. So check what UV your phone can handle when your battery is nearly empty. Again I say: Because of the high likelyhood and massive battery drain that comes with a reboot, I highly recommend you DO NOT USE EXCESSIVE UV. Also remember, even with extreme UV, you will not increase battery life more than 2%
#8 - I found that with bluetooth or GPS preventing the TOP=OFF state, there was no additional power saving from Deep Idle, i.e. the TOP=ON state does not save power.
#9 - Kernels with the 65 fps hack will cause the screen to drain about 10% more power compared to the usual 56 fps.
#10 - Conservative does not save power! For further details and exceptions, refer to my new thread: here.
#11 - This is just general advice: if you are having very poor battery life, have you tried turning auto brightness off? And if you've got no reception, you might as well be in airplane mode, because searching for reception also eats battery.
#12 - If your phone can't handle OC (or UV for that matter) it's because components in general are built to cost, which means factoring in tolerances, and every chip is made as cheaply as possible within the specified tolerances. Outside of those tolerances, whether your chip can cope or not is unfortunately down to the whether you got lucky with the individual device that dropped off the manufacturing line.
ARM document on A8 fault tolerance: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0344k/Babhjhag.html
In fact I measured how UV in particular can cause errors, and saw in action the A8 using MORE power to correct the errors. From my spreadsheet:
At 100Mhz
mV 1500 4.92mA
mV 950 2.83mA (default mV)
mV 800 2.58mA (UV saves some power)
mV 750 2.96mA (Extreme UV uses MORE power)
Same test but with Deep Idle enabled:
mV 1500 1.91mA
mV 950 1.49mA
mV 800 1.29mA
mV 750 1.49mA (Same result again but with DI enabled)
Referenced from my spreadsheet starting row 41.
Recommended reading: http://everything2.com/title/wafer+yield
Stock voltages for reference:
ARM
1000MHz @1250mV
800 MHz @1200
400 MHz @1050
200 MHz @950
100 MHz @950
INT
1000MHz @1100
800 MHz @1100
400 MHz @1100
200 MHz @1100
100 MHz @1000
Summary of Power States by tchaari (thanks!)
After research, and some explanation from Steve Garon, it is clear that Deep Idle & CPU Idle are two completely different things:
1) Three main CPU states are implemented in the standard android kernel: NORMAL, IDLE and SLEEP
2) Ezekeel added an intermediate 4th state: Deep IDLE. This saves more power but only when the processor has a background task to run while screen is off. Bedalus proved here that it really saves a considerable amount of power in particular cases (e.g. music playing when screen is off). A minority of users are reporting some slight instabilities with it, but they may in fact be caused by things other than deep idle.
3) The CPU IDLE backport is a replacement of the standard android kernel drivers used to put the CPU in idle/sleep states by the new ARM methods integrated in the linux 3.2 kernel. This backport is theoretically supposed to improve battery life (with just the basic 3 CPU states). It is 100% stable but no power saving has been shown either in bedalus' amp meter measurements, or Harbb's overnight drain tests.
Where did the other benchmarks go?
All ICS ROM Benchmarks: this thread
Kernel Features and Benchmarks: this thread
CPU Governors and I/O Schedulers: this thread
Power Saving Governors: this thread
Thanks to all the developers, and a big shout out to: Harbb for his dedicated testing; tchaari for his motivation, great ideas and inspiration; jcolinzheng for the idea to test Deep Idle at fixed frequencies (genius); aLNG for links to interesting and useful articles; Steve Garon for demystifying esoteric kernel technicalities and his excellent kernel itself; everybody else who helped; and of course Ezekeel for making Deep Idle work, and for a stimulating debate!
Click to expand...
Click to collapse
here's a screen shot of my battery life in standby.
set up:
Governor and Scheduler: Ondemand/Noop
CPU Frequency: 200-1000
No OC/UV
No Didle
xtone said:
here's a screen shot of my battery life in standby.
set up:
Governor and Scheduler: Ondemand/Noop
CPU Frequency: 200-1000
No OC/UV
No Didle
Click to expand...
Click to collapse
OMG
Can you please share What kernel are you using and what are your settings buddy ??
amritpal2489 said:
OMG
Can you please share What kernel are you using and what are your settings buddy ??
Click to expand...
Click to collapse
I think you're getting your hopes up. Something tells me the radio isn't in use the whole time, extended battery might come into play, or a total of an hour's worth of screen on time. The vibrant has battery drain problems with normal use with aosp ROMs, nothing is gonna change that.
Sent from my Nexus S using xda app-developers app
xtone said:
here's a screen shot of my battery life in standby.
set up:
Governor and Scheduler: Ondemand/Noop
CPU Frequency: 200-1000
No OC/UV
No Didle
Click to expand...
Click to collapse
Dude! My phone on for 1d18h says 13% battery and i don't even use wireless or bluetooth.
amritpal2489 said:
OMG
Can you please share What kernel are you using and what are your settings buddy ??
Click to expand...
Click to collapse
He has not been using his phone see his screen drained only 5% battery. all phones will gives similar results if you just keep phone on table.
So, I futzed around with NStools, and setCPU, trying to find the ultimate governor combination.
With ondemand, no matter what my max clock was, I always had lag, because while it did scale fast, it sampled too slow, even at the lowest allowed.
A big issue was that governors would scale to high clocks, but took too long before it decided to scale up.
I noticed that smartassV2 was willing to scale at smaller intervals, but was WAY too jumpy for going up... after all, why have unused clock cycles. If you're at 75%, and you jump up a notch, you'll be at like 50-60%.
I came to an idea.
I originally tried init.d script to do this, but for some reason on swagged out stock, init.d scripts aren't working for me. Note, I stripped a lot of components from swagged out stock using titanium backup, or just simple uninstalls. It is SOS N running aggressive lionfish 1.8. The stripping of components lowered my memory usage significantly.
I took setCPU, set max to 998mhz, and min to 128mhz, set on smartassv2 with no profiles.
I took NStools, set as follows
scheduler to SIO
cpu to smartassv2
min freq 128
max freq 998
awake ideal freq, sleep ideal freq, and sleep awake freq to 100,000hz,
min cpu load to 85%
max cpu load to 100%
ramp down step to 38400hz
ramp up step to 38400hz
down rate to 10000
upr rate to 10000
Before I did this, I've never experienced this level of smoothness. The real kicker is what setCPU says my "time spent in" is
I wiped my battery stats last night, and let it run down till 10%
I'm at 97.98% of my time spent in 128mhz after over 24 hours, yet it feels perfectly smooth when I play with it. I think part of this is the fast sampling response time of Smartassv2, and also the fact that my rom is running light.
It clocks up, does what it needs to do, and rapidly clocks back down.
How are you guys doing on that chart?
If your phone spent 97.98 % of 24 hours on 128 mhz is not really good. When you don't use the phone, it should go into deep sleep. Download cpu spy from the playstore. If your phone doesn't go into deep sleep, it means you have wakelock issue.
Sent from my lair.
SetCPU was reporting some of the time as 128mhz when it was actually deep sleep.
I checked out CPUspy, and it reads at 51% 128mhz, and 43% deep sleep, with 1036 to 1228 unused, and 62:45:58 of recorded data time.
Out of that, 32:30:15 was in 128, 27:25:01 was in deep sleep, while most of the rest was between 245 and 449, with 00:26:28 on max speed
Does this mean something is waking me out of the 128hz range, while its asleep, and I need to figure it out? I read something about gtalk with video having a wakelock issue, and I have that.