Database Info

[Q] How can I verify that Voltage Control worked?

Whenever I enter the app, it looks like all my settings have been reset, and it shows me running at 1000mhz (despite me setting the max to 800).
Here's how I'm using it, I change all the settings, click apply, then save profile, then save boot settings. Then I reboot my phone.
Additionally, all the menu items under I/O Scheduler and CPU Governor are tripled. What's going on?

I have problems with the boot settings...from what I understand you have to just reconfigure it every time your phone boots. Kinda sucks.
Also, you don't have to reboot to apply settings: it does it as soon as you hit save.

[GUIDE] Maximum Battery - Maximizing your battery life with CM7 ROM by NeoLojik

UPDATE [11th September 2011]
Modified the SetCPU profiles:
Removed AC-charging Overclock (subject to temperature warnings mentioned in replies)​Reduced some MAX values (has added 5 hours of real-world battery use and makes no noticable difference in performance)​Added an optional < 101% profile to default the maximum clock speed to 729MHz (does not reduce performance, adds 2 hours effective runtime)​Specified the Priority values (which I had forgotten to mention originally)​
Introduction - The Desire S Battery Problem
As a fellow Desire S owner, you no doubt agree that it is a lovely phone: sleek, thin, relatively light, feature-filled... almost everything anyone could ever want from a phone!
However...
As a fellow Desire S owner, you no doubt agree that the battery life (on the Stock Sense ROM, regardless of how strict your PWM settings) is rather pathetic.
I have two HTC Desire S phones (one for myself, one for my wife), and both of them have almost exactly the same runtime (give or take a few minutes) when run in identical test conditions... no more than 18 hours (almost all of which with the display turned off) between charges, and less than 8 hours average with light-to-moderate screen-time when in use.
Bottom line: it's rather pathetic, and unacceptable.
Thankfully, we have options now... and this guide provides you with the option I have chosen for my Desire S phones.
Introduction - The Sacrifice
HTC Sense is (to many) considered a very "pretty" GUI, with nice animated transitions, a rounded feel etc, however it comes at a price: it's a battery hog!
I have played with many Sense 2 and Sense 3 ROMs on the Desire S, all of which share the common result of dimished battery runtime...
Bottom line: The simplest way to get more battery life is to sacrifice Sense entirely!
Just to point out: HTC Sense is the only sacrifice this guide makes in the persuit of optimal battery life! Unlike other guides, this one doesn't compromise any other features, or ANY performance (in fact, I've found performance with the setup described here to be even better than the stock ROM... noticably so!)
DISCLAIMER
I cannot (and will not) be held responsible for any losses or damages resulting from your use of this guide or the materials it contains. If you brick your phone, you've done something wrong and the fault is your own.
You should follow this guide with a fully charged battery, and if possible perform all steps involving a PC from a Laptop, with your phone connected via USB to minimize the risks associated with sudden power loss on your mains supply.
Stage 1: S-OFF
Aside from a lucky few whose Desire S came with S-OFF as a factory default, most of us have S-ON handsets.
With S-ON, you cannot flash a custom ROM onto your Desire S... but fear not, as there is now a FREE (and insanely simple) way to unlock our handsets, giving us the precious S-OFF we require.
You will require the Android SDK to be installed on your system, as well as the USB drivers for the HTC Desire S (these are installed as part of HTC Sync, though you should close HTC Sync from the system tray before proceeding as the S-OFF process will refuse to run with HTC Sync running at the same time)
Head on over to http://revolutionary.io/ to download their tool. This guide presumes you are using Windows, though it should be easy enough - if you're a Linux user - to adapt this information for your Linux platform.
Once you press the link to download Revolutionary, you will notice that a form appears asking for certain information. You'll see a screenshot of this below, but before we get to that there's something you must do...
Open a Command Prompt window from the Platform-Tools directory of the Android SDK.
From that Command Prompt window, type adb devices. Presuming you have the HTC Desire S drivers installed correctly, and your handset connected to your PC via USB, you should something like this:
{
"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"
}
LEAVE THIS COMMAND PROMPT WINDOW OPEN, WE'LL NEED IT AGAIN SHORTLY
The third line of text begins with your handset's serial number.... you will need to enter this into the form on the Revolutionary website in order to generate your Beta key:
Once the Revolutionary zip file has downloaded, extract its contents into a folder on your PC (doesn't matter where, so long as you have access to that location).
Run revolutionary.exe following the instructions provided (it's a very quick and simple process... the automated portion of which shouldn't take more than 2 or 3 minutes to complete)
When it prompts you to install the Recovery mod, do it! You will need it for the next stage of this guide!
Your HTC Desire S now has S-OFF, is equipped with a version of ClockWork Recovery, and is ready to recieve the custom ROM! (All is good with the world).
Stage 2: The Custom ROM
IMPORTANT - THIS WILL FACTORY RESET YOUR PHONE (UNAVOIDABLE) SO DON'T FORGET TO BACK UP WHATEVER YOU NEED BEFORE YOU PROCEED WITH THIS GUIDE! YOU HAVE BEEN WARNED!
NOTE You will either need a spare MicroSD card, or to back up your existing MicroSD card and make it accessible to have files written to it from your PC (I use a card reader, but you can always use the USB Mass Storage feature of the phone itself to access the SD card in your phone from your PC)
The custom ROM of choice is NeoLojik's CyanogenMod 7, lovingly and paintakingly prepared especially for our HTC Desire S handsets, with quite probably the most prompt and spectactular support from NeoLojik himself.
I have chosen NeoLojik's CM7 ROM because it has proven (after exhastively testing other ROMs for the Desire S) to provide me with the very best battery performance, as well as all of the settings you will tweak as part of this guide.
Download (from the ROM's thread linked above):
The latest version of his ROM
The recommended Tiamat Kernel
The recommended version of the Google Apps package
To save time later, download The Android Market 3.1.3 APK
(You can download the APK from your phone directly after you've completed this portion of the guide, if you prefer)
Place the three ZIP files, as well as the Android Market APK, on the root folder of your MicroSD card (by "root" I mean the initial path of the SD card, which is whatever drive letter it mounts as on your Windows PC - e.g. "H:\")
Now, with your phone still connected to your PC via USB (and the SD card put back into your phone, if required), return to the Command Prompt window we used earlier and type adb reboot recovery
Now direct your attention to your phone
Once the Recovery Menu has loaded (should take about 30 seconds) we will follow some simple instructions below... but first, a few points on how to use Recovery:
Use the Volume Up and Down buttons on your handset to highlight one of the displayed options
Use the Power button to trigger the highlighted option.
wipe data/factory reset
wipe cache partition
apply update from sdcard
choose zip from sdcard
update-cm7.1.0-RC1-DesireS-Nexx-signed.zip (or whatever the ROM's filename is at your time of downloading... it will change as the ROM evolves)
apply update from sdcard
choose zip from sdcard
Tiamat_Saga-v1.1.2.zip (or whatever the filename is for the recommended Tiamat kernel at your time of downloading)
apply update from sdcard
choose zip from sdcard
gapps-gb-20110613.zip (again, filename might be slightly different for you)
Remembering with each selection to navigate to the "YES" option in the confirmation menu (this exists to prevent you from accidentally flashing the wrong file onto your phone)
Now, from your PC (or from the Recovery menu... doesn't matter which), you want to reboot your phone! To do this from the PC, you will just type adb reboot into the Command Line window we used previously.
Your phone will now boot with the new ROM (CyanogenMod), and has been factory reset (so you'll have to run through the first-run configuration wizard).
NOTE: Don't be scared if (after the boot animation disappears) the screen remains black for a minute or so! The first boot of the new ROM (especially with the Tiamat Kernel) does take a bit longer than every subsequent boot there-after. Just give the phone a few minutes, and press the Power button. You SHOULD see the Lock screen once the device is ready!
Run through the first-run wizard following instructions provided (fairly strait forward), though keep in mind that (at the time of writing) the wizard does not prompt for a WiFi connection until AFTER it attempts to log in to your Google account! Fear not, though, as when it fails to connect to your Google account (presuming you don't have Mobile Data available to you), it'll then prompt for a WiFi network and repeat the Google account login afterwards.
Once you have completed the first run config, open the "File Manager" app included as part of the ROM.
Navigate to /sdcard and run the com.android.vending-3.1.3.apk file. You'll be prompted to allow unknown sources, you want to tick that box and click on the APK again.
Once you've installed this, you will be running the latest (and greatest) version of Android Market, which (amongst other things) enables you to use a different Google account for your Apps (very useful if you want to install your paid applications on your wife's phone, as I have)
Welcome to CyanogenMod!....
Stage 3: Battery-saving Mega Settings [Menu-by-Menu]
The Settings I'm providing you here are the results of countless hours of experimentation (as well as logic and common sense). They have proven to provide the best degree of battery runtime with absolutely no performance or feature sacrifice!
If a menu or entry within a menu isn't mentioned, it's because it has no bearing on power saving!
Wireless & networks
Wi-Fi settings
Network notification = OFF
Press the Menu button, then Advanced
Wi-Fi sleep policy = NEVER​
Call settings
Vibrate on answer = OFF
Vibrate every 45 seconds = OFF
Vibrate on hangup = OFF (NOTE: I leave this ON as my one concession as it's the only way you will know if a call drops out on you unexpectedly!)
Vibrate call waiting = OFF
Always use proximity = OFF
Enable sensor rotation = OFF
Voicemail notifications = ON (it doesn't save power, but seriously... you want it on!)​
CyanogenMod settings
Display
Automatic backlight
Light sensor filter > Enabled = OFF (If enabled, unnecessarily drains more battery life! The feature itself is pointless as there is no difference to the UX with it Enabled or Disabled!)​Light levels
Use custom = ON
Screen dim level = 14
Allow light decrease = ON
Edit other levels...
This is what I consider to be the most optimal set of levels:
Lower | Screen | Buttons
0 | 21 | 2
160 | 31 | 2
255 | 35 | 2
320 | 40 | 0
640 | 50 | 0
1280 | 75 | 0
2600 | 90 | 0
5800 | 130 | 0
8000 | 200 | 0
10000 | 255 | 0
Press Save & apply (scroll to the top to find the button)
NOTE: You may want to play around with some of the values in this table, as screen brightness is not a "one size fits all" affair, and what I can see clearly might not be so clear for you (or vice-versa). Basically, use those levels as a starting point, and tweak them from there until you find the best settings for you in various lighting conditions.
I will say this, you don't want to set the Buttons value above 0 if you can see the buttons even faintly at a given light level. The backlighting for the buttons is a surprising battery drain (it's calculated as part of the Screen's power consumption in the Battery Usage menu). Bottom line: if you don't need any lighting on the hardware buttons in order to use them even in pitch blackness, then set the value of Buttons for each set in the table to 0 and squeeze more life out of your battery!​
Performance (press OK when the warning is displayed)
CPU settings
Available governors = SMARTASS ("SMARTASS" has been designed specifically [and brilliantly] to scale the CPU frequency with such a perfect balance of performance-on-demand versus power saving... it's the perfect choice!)
Min CPU frequency = 192
Max CPU frequency = 1036 (We'll be using SetCPU [full version, bought from the Market] to set up some magical CPU profiles later in this guide, saving us LOTS more battery life!)
Set on boot = ON​
Sound
Haptic feedback = OFF (Remember: The phone's vibrator consumes more power than playing a beep or other short tone through the speaker at even the highest volume!)​
Accounts and sync
Auto-sync = OFF (Auto-sync being disabled saves both battery power, as well as bandwidth on your Mobile Data tarif [2G and/or 3G dependant on carrier]. Really, you should just "sync on demand" as and when you want/need to!)​
This concludes the Settings portion of the guide!
Stage 4: SetCPU (for ROOT users) configuration
SetCPU for ROOT Users is available for on the Android Market for just £1.25 (or $1.99 USD). Not only does this program enable you to overclock/underclock your phone's CPU, but more importantly it enables you to provide Profiles, to scale the CPU based on the operational status of your phone.
This is well worth the infintismal pricetag, as the potential power savings (at no performance cost) is more than significant!
Open SetCPU, go to the Profiles tab:
Enable = ON
Notifications = ON (Really this is up to you! I like to have notifications for when the profile is changing to ensure that the CPU is scaling properly, and to ensure that my profiles are the best they can be for performance/battery balance)
Add Profile
Profile = Charging AC
Max = 1036800 (Potentially, you could set it up to 2GHz, but I have stability (and heat) concerns, and I can't possibly see any circumstance where 2GHz would be remotely useful! If you do elect to overclock (particularly whilst charging), you will need to add a profile (with 100% priority) to drop the Max value if the temperature exceeds 45 C)
Min = 192000
Scaling = smartass
Press Save​
Add Profile
Profile = Charging USB
Max = 1036800 (Basically 1GHz [original] CPU clock. We don't want to bleed into the minimal input of power provided by USB, so this is the best setting to use)
Min = 192000
Scaling = smartass
Press Save​
Add Profile
Profile = Battery <
Battery < = 75%
Max = 652800
Min = 192000
Scaling = smartass
Press Save​
Add Profile
Profile = Battery <
Battery < = 50%
Max = 576000
Min = 192000
Scaling = smartass
Press Save​
B]Add Profile[/B]
Profile = Battery <
Battery < = 30%
Max = 422400
Min = 192000
Scaling = smartass
Priority = 80
Press Save​
Add Profile
Profile = Screen Off
Max = 345600
Min = 192000
Scaling = smartass
Priority = 60
Press Save​
Add Profile
Profile = Time
Time = 01:00 - 08:00 (NOTE: Substitute the given range with whatever your daily sleeping hours are!)
Max = 345600
Min = 192000
Scaling = smartass
Priority = 70
Press Save​
The following profile is optional... and (if used) would specify your default clock speed
Add Profile
Profile = Battery <
Battery < = 101%
Max = 729600
Min = 192000
Scaling = smartass
Press Save​
Feel free to experiment with other profiles as well! Perhaps you may want to procedurally reduce your CPU speed based on Battery % in a more gentle way... this is certainly possible, and would squeeze even more life out of your battery.
You should also feel free to use lower MAX values for each setting (I would strongly advise against higher values) if you feel that the lower clock speed makes little-to-no noticable difference in performance as you use your phone.
Personally, I notice no difference between 729600 and 1038600!​
Stage 4: Recalibrating your Battery
Install the Battery Calibration app (FREE on the Android Market).
If your phone isn't charged, charge it up so that it is showing 100% (with the Green LED lit).
Run Battery Calibration and press the Battery Calibration button. Immediately unplug the power/USB cable from your phone, and allow it to run (as normal) until fully discharged.
Once the phone has switched itself off, plug it into the AC cable (using the mains charger).... and LEAVE YOUR PHONE SWITCHED OFF until the LED indicator is lit green!
You may want to repeat the discharge/recharge cycle one or two more times (as many people claim that this provides a better calibration)... though really that just entails running your phone on the battery until it is fully discharged, then allowing it (whilst switched off) to fully recharge on the mains adapter (AC)... which is not what most people would normally do as a routine.
Potential Stage 5: Tasker
Tasker (£3.99 on the Android Market) enables you to create profiles which automatically change various settings based on one or more given criteria. This even includes the ability to switch on and off features of your phone such as WiFi, Bluetooth, GPS, GSM, Mobile Data and Airplane Mode.
By creating suitable Tasker profiles, you can squeeze even more battery life out of your phone!
If it's of benefit to people (let me know in the comments) I can expand this guide to include step-by-step instructions on creating the various profiles I would recommend in order to squeeze more battery runtime out of your phone without sacrifising features/functionality.
General Battery Storage/Maintenance Advice (Applies to all Lithium-Ion Batteries, including those used in Laptops)
To prolong the operational lifespan of your battery, you should not really allow your battery to run for very long below 50% charge, as "topping up" a half-charged battery generates less wear and tear on the battery, prolonging its overall lifespan.
NEVER leave your phone fully discharged for more than an hour, or the LiIon cells will begin to degrade, meaning your battery will never be able to physically hold as much charge. Indeed, the longer you leave a discharged battery, the less overall capacity your battery will retain.
NEVER store your battery (even if the phone is running at the time) in cold conditions! As a general rule of thumb, if it's "a little chilly" for you, it's unhealthy for the battery!
Both of the above tips form respectively the Number 1 and 2 causes of battery death! Don't let your battery become another statistic!
If - like me - you have one or more "spare batteries", you will likely be tempted to store them when they are fully charged (100%). This sounds like a good thing to do, but actually it can have (to a slightly lesser degree) the same damaging effect on the battery as leaving it fully discharged for any prolonged period of time!
The absolute best level of charge at which you should store a battery is at 50%, or as close there-to as possible!
Dependant on how often you find yourself recharging your battery, you should recalibrate it between every 3 to 6 months (the more often you discharge/recharge, the less often you should recalibrate).
Also, you should ALWAYS recalibrate after having flashed a new (or updated) ROM and/or Kernel!
My results using the exact configuration [excluding Tasker] detailed in this guide...
As I stated above, with the way I use my Desire S, I was lucky to get 8 hours of what I would call "light-to-moderate" use whilst running on the battery!
With the configuration detailed in this guide, I have now had a successful "100% to discharged" usage of 46 hours (under the exact same usage conditions as when I was using the stock ROM factory-installed on the phone (and updated OTA ~ a week ago).
This is a VERY significant improvement, though I must stress that results will vary heavily based on how much (or what) software you're running on the phone, how often you're interacting with it, how long you spend in calls etc.
Basically, every phone is different, and every operator (me, you, everyone) is different.
Please also keep in mind that your phone won't "settle in" to the new settings in terms of battery runtime until you've done 2 or 3 discharge/recharge cycles (as explained in the Battery Calibration portion of this guide)
Conclusion
There are plenty of third-party ROMs out there, and (obviously) I can't physically test them all! I have tested what I believe anyone would consider to be a perfectly suitable number (more than a dozen now), and have found the exact combination detailed in this guide to provide the very best battery runtime for me.
I understand that some of you will likely have your own ROM preference (for various reasons), but I hope that at least some sections of this guide will be useful to you.
If you just want to get the very best battery performance out of your Desire S, and either don't particularly care what ROM you use, or (like me) happen to love Cyanogen anyway... this guide will fit you like a glove!
Need any more advice?
No problem... post your comments and questions as a reply to this guide, and I'll answer anything I can, as promptly as possible (please consider that I have a company to run, and a life beyond the Internet... so replies might not always be "instant")
I hope you like this guide, and more importantly... I hope you enjoy your new-found battery runtime!

Unfortunately, I'm a Sense fan. ...so will take persuding to move away from the interface, as been using it for many years, but, I still appreciate a piece full of insight and advice written for the communities benefit. Well done and thanks for sharing.
I'll reference this in the development INDEX next to CM7 ROMS

ben_pyett said:
Unfortunately, I'm a Sense fan. ...so will take persuding to move away from the interface, as been using it for many years, but, I still appreciate a piece full of insight and advice written for the communities benefit. Well done and thanks for sharing.
I'll reference this in the development INDEX next to CM7 ROMS
Click to expand...
Click to collapse
Yeah, I can understand why so many people strictly adhere to Sense ROMs... for me the "slight prettiness" of Sense doesn't justify the hammering of the battery... especially as I actually preffer the L&F of Cyanogen anyway

If I have gotten 18 hours with almost always screen off I returned the phone. With nomal usage my phone last more than one day. Keeping the screen almost always off last almost 2 days with wifi and sync turned on (to be honest, never reached that again). ROM is whether LBC or rooted stock whith stock HTC kernel. So I can find any problem there. Nevertheless, this is a smartphone, and I always have a charger with me
I will try CM and what the battery life is like.

Profile = Charging AC
Max = 157440 (Potentially, you could set it up to 2GHz, but I have stability concerns, and I can't possibly see any circumstance where 2GHz would be remotely useful!)
Min = 192000
Scaling = smartass
Press Save
Fried CPU kgo. Overclock + Charging = Excessive heat being generated.

zeekiz said:
Profile = Charging AC
Max = 157440 (Potentially, you could set it up to 2GHz, but I have stability concerns, and I can't possibly see any circumstance where 2GHz would be remotely useful!)
Min = 192000
Scaling = smartass
Press Save
Fried CPU kgo. Overclock + Charging = Excessive heat being generated.
Click to expand...
Click to collapse
I have tested this setting with my own phone, and the heat increase was LESS than 1 Celcius (infintismal)... sure, if you wanted, you could use a lower value.

Its your call, your thread, I just feel that it isn't a good idea. At least even consider placing a warning adjacent to it.

LaKraven said:
I have tested this setting with my own phone, and the heat increase was LESS than 1 Celcius (infintismal)... sure, if you wanted, you could use a lower value.
Click to expand...
Click to collapse
You could add a setcpu profile for limitting the temperature. I dont overclock, but when im using my phone while charging, it gets hot, so I limit the temperature at 41.1 C , so 768mhz - 245mhz , on demand.
lbc ROM, stock kernel

zeekiz said:
Its your call, your thread, I just feel that it isn't a good idea. At least even consider placing a warning adjacent to it.
Click to expand...
Click to collapse
I've updated the guide (see the update notes at the very top of the post). The on-AC overclock setting has been removed, and I have placed a warning about overclocking next to it.

Updated the post to address a typo in one of the SetCPU profiles (I missed a 0 from the end of 345600).

I will have done this process by tomorrow, I'm sure - even bought Tasker. - Hoping I wont damage something in the process since I've never dealt with an HTC phone before. :/ Since my mom bought it to me as a present, she just peeks in from time to time to check wth am I doing with it - gotta keep a satisfied grin on my face all the time while I'm figuring how to fix this problem lolz

Really you just need to follow instructions (read everything through at least twice before you begin), be patient... and double-check everything you're abuot to do before you do it.
You can't do any more than that!
I've flashed both of these phones so many times now, and the only mistake I ever made was forgetting to clear the cache (Which results in an infinite boot loop or "soft brick", easily recovered by constantly typing "adb reboot recovery" in your Command Prompt, which will eventually make the phone re-enter recovery mode (exiting the infinite boot loop), at which point you can wipe, clear cache, reflash, and relax!

LaKraven said:
Really you just need to follow instructions (read everything through at least twice before you begin), be patient... and double-check everything you're abuot to do before you do it.
You can't do any more than that!
I've flashed both of these phones so many times now, and the only mistake I ever made was forgetting to clear the cache (Which results in an infinite boot loop or "soft brick", easily recovered by constantly typing "adb reboot recovery" in your Command Prompt, which will eventually make the phone re-enter recovery mode (exiting the infinite boot loop), at which point you can wipe, clear cache, reflash, and relax!
Click to expand...
Click to collapse
Funny, so true, in fact, did just that myself about two minutes ago while testing another ROM, meant trip to PC, plug in, power on, and then sorted adb reboot recovery
Swyped from HTC Desire S using XDA Premium

ben_pyett said:
Funny, so true, in fact, did just that myself about two minutes ago while testing another ROM, meant trip to PC, plug in, power on, and then sorted adb reboot recovery
Swyped from HTC Desire S using XDA Premium
Click to expand...
Click to collapse
Good to know I'm not the only one! It's such an easy step to overlock... just a good job it's also the least fatal mistake to make!

and then this
.. Ther is no Path in User, but there is in System...Geez, so tired..What do....:/ I'm all set to flash, just this thing I think...

You need to reinstall Java JDK.
This has happened to me before!

LaKraven said:
You need to reinstall Java JDK.
This has happened to me before!
Click to expand...
Click to collapse
Thx man I did that, I also don't have any command prompts in here :
C:\Program Files (x86)\Android\android-sdk\platform-tools

Bombastc said:
Thx man I did that, I also don't have any command prompts in here :
C:\Program Files (x86)\Android\android-sdk\platform-tools
Click to expand...
Click to collapse
Open Windows Explorer, navigate to C:\Program Files (x86)\Android\android-sdk\platform-tools
Hold down SHIFT and RIGHT-CLICK in on that folder
Click "Open command line window here"
You're then ready to start using ADB commands

LaKraven said:
UPDATE [11th September 2011]
Potential Stage 5: Tasker
By creating suitable Tasker profiles, you can squeeze even more battery life out of your phone!
If it's of benefit to people (let me know in the comments) I can expand this guide to include step-by-step instructions on creating the various profiles I would recommend in order to squeeze more battery runtime out of your phone without sacrifising features/functionality.
Click to expand...
Click to collapse
I would really like that. Yesterday followed your guide and learning new things as i went about the CyanogenMod. I'm curious now how far my battery will bring me :-D.
At the moment i'm using the trial version of phoneweaver and automateit, which are nice programs, but if tasker is more efficient although having a steeper learning curve, i will switch in an instant.

shizuku said:
I would really like that. Yesterday followed your guide and learning new things as i went about the CyanogenMod. I'm curious now how far my battery will bring me :-D.
At the moment i'm using the trial version of phoneweaver and automateit, which are nice programs, but if tasker is more efficient although having a steeper learning curve, i will switch in an instant.
Click to expand...
Click to collapse
As a tasker convert myself, I can also say that you'll read a great review of some of its functionality and a slightly biased review of the product by wnp_79 as part of his [GUIDE] Update 28/06/11: HTC Desire S Guide (V1.03) For Newcomers to Android which is in a sticky at the top of the forum.

[INFO] setCPU details

Here is a great resource where you can learn a lot about the setCPU app and what all the features actually do.
It is very informative and in particular, this is what appealed to me:
"The Advanced menu allows you to tweak the finer aspects of certain CPU governors. It is only activated when you choose the ondemand or conservative governors.
Sampling Rate - An interval (in microseconds) at which the governor will poll for updates. When this happens, the governor will decide whether to scale the CPU up or down.
Up Threshold - Defines a percentage from 1% to 100%. When the CPU load reaches this point, the governor will scale the CPU up.
Down Threshold (conservative only) - Defines a percentage from 1% to 100%. When the CPU load reaches this point, the governor will scale the CPU down.
Ignore Nice Load - If this value is "1," the system will ignore "Nice" processes when deciding to scale up or down.
Powersave Bias (ondemand only) - Setting this value higher will "bias" the governor toward lower frequencies. This is a percentage, where 1000 is 100%, 100 is 10%, and 0 is 0%. The ondemand governor will scale the CPU to a frequency lower than its "target" speed according to this value.
Freq Step (conservative only) - Defines how much (as a percentage of the maximum CPU speed) the conservative governor will increase the CPU speed by each time the CPU load reaches the Up Threshold.
Choose the "Set on Boot" checkbox to apply advanced settings when the phone boots. This option is completely independent of the similar option in the Main tab."
Thought i would post this to keep people informed.
Also, you can save battery with higher up thresholds ;D

I remember seeing this info at http://setcpu.com link mentioned in the about tab.
Higher up thresholds are not always good. It is better to have processor stay in 1200 state at 50% for 2 seconds compared to staying at 800 for 5 seconds at 100%.

diablo009 said:
I remember seeing this info at http://setcpu.com link mentioned in the about tab.
Higher up thresholds are not always good. It is better to have processor stay in 1200 state at 50% for 2 seconds compared to staying at 800 for 5 seconds at 100%.
Click to expand...
Click to collapse
WHOA theres a setCPU.com? wow

Mohammad_Adib said:
WHOA theres a setCPU.com? wow
Click to expand...
Click to collapse
Yes sir. It explains each and every option in the app, plus has a changelog too.
Edit: I saw the site u mentioned. It is a copy-paste from the setcpu.com site.

diablo009 said:
Yes sir. It explains each and every option in the app, plus has a changelog too.
Edit: I saw the site u mentioned. It is a copy-paste from the setcpu.com site.
Click to expand...
Click to collapse
wow....lolz

conservative cpu governor up/down thresholds, and their defaults

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.

[KERNEL][ATT][AOSP/TW/GE - 5.0/4.4/4.3/4.2][02/06/2015] KT-SGS4 - NAE - KTweaker

Ktoonsez presents:
{
"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"
}
​
KT-SGS4 Jellybean kernel features
•Must have a Touchwiz Rooted ROM
•Must have CWM or other custom recovery installed
•Linux kernel 3.4.106
•Samsung open source
•Optimized kernel configuration
•Updated USB driver
•unsecure root adb
•Voltage interface
•CPU Overclocking
•CPU Underclocking
•Boots on stock table (USE KTweaker app to enable OC steps all the way to 2322 Mhz. BE AWARE THAT I WAS VERY CONSERVATIVE ON THE LOW SIDE OF THE OC STEPS, SO THEY WILL NEED SOME TWEAKING!)
•KTweaker app for kernel control
•KTweaker Widget
•Schedulers (CFQ, BFQ, VR, SIO, NOOP, DEADLINE, ROW, FIFO, FIOPS)
•GOVERNORS (ktoonservativeq, intellidemand, msm-dcvs, wheatley, userspace, smartassh3, slp, powersave, pegasuq, nightmare, interactive, dancedance, conservative, badass, asswax, adaptive, abyssplug, performance, ondemand
•exFAT for Touchwiz and AOSP
•F2FS compatible with AOSP 4.4
Click to expand...
Click to collapse
Canadian users, DO NOT FLASH the kernel from this thread, flash the TMO version from the thread linked below:
http://forum.xda-developers.com/showthread.php?t=2289140
AOSP Lollipop 5.0 VERSION:
02.06.2015: http://ktoonsez.jonathanjsimon.com/sgs4/AOSP/KT-SGS4-LP5.0-AOSP-INTL-02.06.2015.zip
Click to expand...
Click to collapse
AOSP KITKAT 4.4 VERSION:
12.09.2014: http://goo.gl/ZPpZwn
Google Edition KITKAT 4.4 VERSION:
07.12.2014: http://goo.gl/bnhW1F
Touchwiz Kitkat 4.4 VERSION:
07.12.2014: http://goo.gl/MebJ4Z
To make wifi work when it wont turn on or connect, change this in the build.prop:
ro.securestorage.support=true TO ro.securestorage.support=false
Click to expand...
Click to collapse
******* END OF LIFE *******
AOSP JELLYBEAN 4.3 VERSION:
06.19.2014: http://goo.gl/GqNAUp
Touchwiz JELLYBEAN 4.3 VERSION:
06.19.2014: http://goo.gl/Vso846
Google Edition JELLYBEAN 4.3 VERSION:
06.19.2014: http://goo.gl/vtI0Tt
Click to expand...
Click to collapse
Touchwiz JELLYBEAN 4.2.2 VERSION:
http://ktoonsez.jonathanjsimon.com/sgs4/TW/KT-SGS4-JB4.2-TW-ATT-02.20.2014.zip
AOSP JELLYBEAN 4.2.2 VERSION:
http://ktoonsez.jonathanjsimon.com/sgs4/AOSP/KT-SGS4-JB4.2-AOSP-ATT-11.04.2013.zip
Click to expand...
Click to collapse
KTweaker Shop and previous versions can be seen here (thanks to LuigiBull23):
http://forum.xda-developers.com/showthread.php?t=2393708
Always do the following AFTER installing the kernel:
1. Clear cache
2. Clear dalvik
3. Fix Permissions
If you get this message after booting up the kernel:
"The device has detected an application attempting ..."
Go to the "/system/app/" folder and delete the files that begin with "knox"
Post #2 will be reserved for change logs
Post #3 will be reserved for MY Settings, Extras and FAQ's
Sources can be found here:
https://github.com/ktoonsez/KT-SGS4

Change Log 12.09.2014
1. Sync with CM code changes
2. Sync ramdisk updates in CM-12
3. Add back in f2fs support for AOSP 4.4 kernel
Change Log 11.30.2014
1. After hundreds of hours I finally gave up porting to new code so I had to start all over again.
2. Everything works except the Screen wake functions!!!!!!!
3. Sync with CM-11
4. Sync with CM-12
5. Enjoy
6. Unified the code so everybody willl use the INTL version
7. Thanks to all that were patient while I worked a million hours for work and good-bye to all the whiner/haters that said I abandoned this, you are now allowed to download this .
Change Log 07.12.2014
1. Linux 3.4.95.
2. Linux 3.4.96.
3. Linux 3.4.97.
4. Linux 3.4.98.
5. Modified KTMonitor to fit better with wider fonts.
6. New ktoonservativeq parameter named "cpu_load_adder_at_max_gpu"!!!!!!!!!!!! This is an awesome parameter you can use to boost your CPU while the GPU is at max level. Example: if you set cpu_load_adder_at_max_gpu = 30 and while playing a game and your GPU is at max Mhz, the CPU load is only 22%, this parameter will add the 30 thus making the CPU load a 52% which will bring up the Mhz and more cores according to your settings.
7. 4.3 kernels are now moved into ******* END OF LIFE ******* section
Change Log 06.19.2014
1. Linux 3.4.93.
2. Linux 3.4.94.
3. Couple KTweaker patches.
4. Updated compiler misc stuff.
Change Log 06.09.2014
1. Linux 3.4.92.
2. Merged in latest CM commits.
3. Ramdisk updates for AOSP.
4. 4.4.3 miscelanious stuff.
5. Fix IR for GE ROMs.
6. Merge in some more 4.4.3 stuff for GE.
7. Ktweaker update: AUTO HOTPLUG OPTION IS NOW A LIST SELECTION INSTEAD OF CHECK BOX, MAKE SURE YOU GO AND SET IT TO THE PROPER VALUE!!!!!!!!!!!!! So if you used to have the checkbox off, select "Disabled", if you had it checked, select "KT Auto Hotplug"
Change Log 05.28.2014
1. Linux 3.4.90
2. Linux 3.4.91
3. Upgraded to latest Linaro
4. Merged in the 1 commit from CM
Change Log 05.14.2014
1. KTweaker 7.1 (this is just an update for my S3 guys, nothing new for S4)
2. sched: set mc_power_savings=2 this feature packs tasks together and try to bind them to cpu0, which in theory will let cpu1 idle longer, thus improving battery life.
3. kernel:sched: LOAD_FREQ (4*HZ+61) avoids loadavg Moire
4. smp: patches from mainline 3.5 to hopefully help with hotplug efficiency
5. Linux 3.4.89
Change Log 05.05.2014
1. Mostly a TWRP update on todays release
2. Modified TWRP to do ext4 or F2FS on the fly based on "Settings" screen to reduce problems, no more need for flashing format zips like before, and no more rebooting in and out of recovery.
3. When you change the "Settings" you will notice that the name at the top will change according to your settings. EXT4 for ext4 formatting, F2FS for F2FS on data and cache, and F2FS+S for data, cache, and system.
4. Under "Settings" screen in TWRP you will see a new option called "Force data and cache wipe functions to use F2FS". When checked it will force wipes on the cache and data partitions to format it F2FS, unchecked forces to ext4.
5. Under "Settings" screen in TWRP you will see a new option called "Include system partition." When checked it will force wipes on system partitions to format it F2FS, unchecked forces to ext4.
6. KTweaker: New option under "Tools" screen called "Get Partition info" so you can check the format of the 3 partitions.
7. Since I made the new TWRP, I modified the ramdisk back to my original testing code to load the partitions based on there format. Since it does this, you will have to use KTweaker now to verify if you did indeed format everything properly using the new option from #6 above.
8. Link to newest TWRP-ALL-IN-1: http://goo.gl/xl5VwI
9. Link to newest F2FS folder (updated instructions in the folder, moved all the old stuff to the "OLD WAY" folder): http://goo.gl/HLz4al
Change Log 04.28.2014
1. Linux 3.4.88
2. Now compiling with Linaro 4.9.1 a-15 optimized from @Christopher83
3. Updated kernel flash routine to detect F2FS partitions and include the appropriate fstab so it works with /data and /cache or /data and /cache and /system
4. Updated KT-TWRP.F2FS and KT-TWRP.EXT4 to have one common recovery binary, during flash uses same algorythm as kernel flash zip to use the proper fstab.
5. KTweaker 7.0
6. Under "Tools" screen added "F2FS: Convert ROM ZIP option". To use it, click that option, it opens a KT File Explorer, navigate to the folder where your zip files is, click the ROM zip file that needs converting and it will create a second file with the same exact name except adds a -F2FS to the end. A little hint, instead of using the back button once you are done converting, press the menu button and select close and KTweaker will remember that folder and take you right back the next time you go back in. It takes around 1:45 to do it my phone running ktoonsified v6, other profiles may take longer and if you are converting from external SD it may take longer depending on the quality of your SD.
7. TWRP for normal EXT4 format link is here http://goo.gl/jwMSEn
8. TWRP for F2FS format link is here http://goo.gl/Zw1akJ
Change Log 04.19.2014
1. ktoonservativeq: Optimized new block_cycle code that was causing slow issues for some
2. Updated Ktoonserified v6, so be sure to redownload it to work with todays kernel
3. Updated KTGaming profi.e, so be sure to redownload it to work with todays kernel
4. Probably the fastest version of ktoonservativeq to date
5. Guys on 04.18 test kernel from yesterday, there is no change but might as well update so you are the newest dated file.
6. KTweaker 6.9
7. KTweaker: Added new sub screen when picking ktoonservativeq "Gov Adjustments" screen to give you the choice to show "All Parameters", "ONLY Screen ON parameters", "ONLY Screen OFF parameters" to make it easier to see only the parameters you want to see. Thanks @elesbb for the idea
8. Linux 3.4.87.
9. I was unable to reproduce the inability to download scripts, but I made a change and 2 people have told me it doesnt do that anymore with 6.9 so I think I got it fixed.
10. Updated TWRP for normal EXT4 format with 20 upstream updates and updated curtain image thanks to @9Lukas5, link is here http://goo.gl/jwMSEn
11. Updated TWRP for normal F2FS format with 20 upstream updates and updated curtain image thanks to @9Lukas5, link is here http://goo.gl/Zw1akJ
Change Log 04.17.2014
1. Ktoonsez CRAZY BIRTHDAY EDITION!!!!!!!!!!!!!!!!!!
2. KTweaker 6.8
3. Made Fast Charge Widget size based on left side alignment so people that want a 1x1 widget of FC can do that (by request from someone)
4. 20+ new parameteres for Ktoonservativeq. I went a little crazy with it but you are going to love it!!!!!!!!!!!
5. WARNING!!!!!!!!!!! All the rest of these are going to require you to check and maybe set some of your ktoonservativeq governor settings from scratch!!!!!!!!!!!!!! I did the best I can at converting them to the new names but can account for every old version of the Profile files. So write down your settings before flashing so you can manually set them up with the new names.
6. Ktoonservativeq: Renamed all up_threshold and down_threshold items to have a version for screen on and off. So all 8 items turned into 16 items no so you have total control for screen on and seperate control for screen off.
7. Ktoonservativeq: Changed all parameters that said hotplugging into hotplug to shorten the names.
8. Ktoonservativeq: Rename all the block parameters to more commonized names. New item names are as follows. block_cycles_online = blocking cycles before letting a CPU come online. block_cycles_offline = blocking cycles before letting a CPU go offline. block_cycles_raise = blocking cycles before letting the CPU raise the Mhz.
9. Ktoonservativeq: All of the block parameters from item 5 have a screen on and scree off option.
10. Ktoonservativeq: Renamed freq_step to have a screen on and off option plus seperate values for the raise and lowering of the CPU Mhz.
11. Ktoonservativeq: lockout_2nd_core_hotplug, lockout_3rd_core_hotplug and lockout_4th_core_hotplug all have a screen on and screen off option.
12. Ktoonservativeq: Renamed sync_extra_cores parameter to have screen on and off options
13. Ktoonservativeq: Renamed boost_2nd_core_on_button, boost_3rd_core_on_button and boost_4th_core_on_button to have screen on and off options.
14. KTweaker Shop: Now when you select Profiles or Scripts, it will come up with a sub screen that lets you choose from All Profiles/Scripts, ONLY Conservative Profiles/Scripts, ONLY Balanced Profiles/Scripts, or ONLY Performance Profiles/Scripts. Thanks to @CamFlawless for creating the type list for me.
15. Added Ktoonsified v6 to KTweaker Shop.
16. Update the server for KTweaker Shop to support the 3 types of profiles now.
17. Update a bunch of profiles to the server for KTweaker Shop, BIG thanks to @LuigiBull23 for helping me update all the files for the server.
18. LED: Boost cores on LED calls to help incoming calls and unplug-plug charger turn screen on quicker.
19. Make call_in_progress a global variable so we have access to its status in more places. Use the call_in_progress in ktoonservativeq to block super_conservative so phone calls r smoother
20. Remove loki on PC side and use loki scripting in flash zip
21. F2FS: add support for F2FS so people that want to run it can. THIS ONLY WORKS TO AOSP4.4 SO FAR!!!!!!!!! All kernels will come with standard ext4 as default, people that want F2FS will have to do the instructions from Post #3 !!!!!!!!!!!!!!!!
22. F2FS: See Post #3 for a download link and a set of instructions to move convert to F2FS.
23. Post #3 updated with my latest settings and fixed the screen names for each setting.
24. Flashable kernel zip now do the loki'ing when it is needed for ATT and VZW and also determine your file system to know whether to flash F2FS or ext4 ramdisk.
25. For those that use TWRP and want to try mine, you can download it here (Normal ext4 version, not for people that format to F2FS): http://goo.gl/jwMSEn. It seems to have gotten rid of the boot hang that some people get with official 2.7.0.1.
Change Log 04.07.2014
1. Applied battery drain fix to all versions
2. Shorten internal kernel name so Antutu does not crash
3. KTweaker 6.7.3
4. KTweaker: Couple of fixes for numeric entry
5. KTweaker: Fix CPU count error
6. Linux 3.4.86
7. Revert code from 04.02 release that was causing UI lag.
8. Added "booting" LED pattern, because its cool and tells me when kernel takes over from bootloader and when ROM takes over from kernel
Change Log 04.02.2014
1. Fix memset issue when moving to Linaro 4.8.3 (this fixes ROMs that Settings app was crashing and could not rename files/folders)
2. Major rewrite of random code ( this should make games perform even better)
3. Sched:fair: Tons of merges from stuff around the net and faux
Change Log 04.01.2014
1. Linux 3.4.85
2. Ktweaker 6.7.2
3. Modified Ktweaker OTA flashing options to work with CWM/Philz recoveries
4. Using newest Linaro 4.8.3 toolchain optimized for a15 cortex
5. Added -o3 optimizations to TW 4.4
Change Log 03.27.2014
1. Ktweaker 6.7.1
2. Modified Ktweaker Widget S2W toggle to include the S2W, DT2W... options
3. Fixed KTweaker issue with not saving "Vibration Strength" option.
4. Linux 3.4.84
5. Added @Fenny's code to let people charge while phone is power off on GE and TW 4.4 versions. Be sure to go thank Fenny for tracking that down!!!
6. Added ZCACHE to TWGE 4.4 and TW 4.4
7. Added FRONTSWAP v16 to all 4.4 versions, thanks to all the guys that tested yesterday.
8. Added back all standard screen on/off code for initialization to hopefully stop the no touch issue for the few people that get it here and there.
9. char:random: Some tweaks from around github.
10. For TW 4.4 merged in Linux 3.4.1 thru 3.4.84
11. cpufreq: Fix broken uevents for cpufreq governor and cpu devices from CM 11
12. Ramdisk updates for AOSP 4.4
Change Log 03.19.2014
1. Moved Double tap, sweep, etc... to its own screen in "Main Settings" called "Wake/Sleep Settings"
2. NEW item in "Wake/Sleep Settings"!!!!!!!!!!: Double tap to sleep. Double tap the top status bar area when the screen is on and it will to go sleep.
3. Made a duplicate item of "Prox Sensor Checker" in the "Wake/Sleep Settings" screen for easy access.
4. Made a duplicate item of "Charging Current" in the "Fast Charge" screen for easy access.
5. Remove all the main debug flags, zip files are about 2-3mbs smaller now
6. Sync with CM commits from a few days ago.
7. Remove DCVS flag to remove some unnecessary Samsung Mhz manipulation
8. Linux 3.4.83
9. Ondemand governor patches
10. Optimized ARM RWSEM algorithm from Ashwin Chaugule
11. Added 4 zram drives from TW 4.3 into 4.4.
Change Log 03.12.2014
1. Improved "on a phone call" code to make sure it is isnt executing the screen wake code while screen is off and you are on a call.
2. Increased speed for wake up on the screen wake functions, sensor wake functions wake a little quicker too but will always be limited by the 1 second timer.
3. Finally found a better spot to trigger and make the screen turn on way quicker when an incoming call is coming in.
4. KTweaker version 6.6.
5. NEW item under "Tools" screen called "Charging Current". You can click on the item and it will update the field with the current mA it is charging at.
6. NEW item under "Fast Charge" called "MTP while fast charging". Enabled will keep MTP on so you can still access the phone, disabled will disable MTP and you will not be able to access it, just simply charges. To take effect this option requires the cable to be unplugged and re-plugged in.
7. NEW item under "Fast Charge" called "Screen ON charging limit". BE VERY CAREFUL WITH THIS ITEM!!!!!!! When enabled it will keep the Samsung limit they imposed of 1200 mA while charging and the screen is on, if it is disabled it will allow you to charge at the full 1900 mA or whatever custom mA you have set for A/C. To take effect this option requires the cable to be unplugged and re-plugged in.
Change Log 03.10.2014
1. Improved Sweep 2 wake recognition.
2. Ignore double tap if more than 1 finger is used.
3. New option for "Hold Wake Lock for wake" called "Enabled ONLY while charging" so you can choose to only hold wake lock during charging.
4. Added wake lock montitor so wake locks can be kicked back on if they are killed prematurely.
5. New "Prox value when clear" added so you can specify the prox value to allow the screen wakes to still work when your prox is not functioning properly/dirty.
6. New item under "Tools" called "Prox Sensor Checker". Click it start/stop the monitor timer. Use this to see what you 100% clear prox value is, then add 20 to that number and use it for the "Prox value when clear" value mention in #5 above.
7. LEDs: Added some code that was needed on the TW version to catch all the notification scenerios.
8. Fix the issue where touch screen would become unresponsive on TW ROMs.
9. Thats all I can remember, ENJOY!!!!!
Change Log 03.06.2014
1. NEW!!!!!!! LED: 3 New options in KTweaker to select from, "Disable LED Start Hour", "Disable LED Stop Hour", "Disable LED Always". Start and Stop value are in 24 hour military time.
2. NEW!!!!!!! "Screen Wake Options" of: Sweep 2 Wake, Sweep 2 Wake ONLY on Charger, Double Tap 2 Wake, Double Tap 2 Wake ONLY on Charger, Both, Both ONLY on Charger.
3. Screen Wake Options: For Sweep 2 Wake, sweep the screen from left to right or right to left to turn on the screen.
4. Screen Wake Options: For Double Tap 2 Wake, double tap the screen if the bottom left corner to turn on the screen.
5. NEW!!!!!!! "Sensor Wake Options" of: Wave 2 Wake, Wave 2 Wake ONLY on Charger, Pocket 2 Wake, Pocket 2 Wake ONLY on Charger, Both, Both ONLY on Charger.
6. Sensor Wake Options: For Wave 2 Wake, hold your hand in from of the proximity sensor for about 1/2 second and then wave it back and forth to turn on the screen.
7. Sensor Wake Options: For Pocket 2 Wake, simply have the phone in your pocket for at least 10 seconds, take it out and the screen turns on.
8. NEW!!!!!!! "Hold Wake Lock for Wake" of: Check them out, there is freaking 18 of them, lol. By using any of these methods you will guarantee that the wake methods will work, without them its a crap shoot. My favorite is "Enabled ALWAYS on LED notif", this will turn on a wake lock when the LED is blinking for a notification and will obey your "Disable LED Start Hour" and "Disable LED Stop Hour" to block a wake lock when u dont want LED on. The name of the wake lock is "kt_wake_funcs" so you can track it when using them.
9. FastCharge: Completely re-did FastCharge interface adapted from Jean-Pierre and Paul Reioux. There are 3 options now for for the main selection (Enabled, Disabled, Custom mA)
10. FastCharge: When Custom mA is selected, it will obey the "Custom USB mA" and "Custom A/C mA".
11. FastCharge: Another new option is "Fail safe", when enabled it will use the lowest A/C or USB value when the cable type is UNKNOWN. When disabled it will allow you to use any custom mA instead of the predefined ones that you will see in Ktweaker when choosing the 2 Custom mA's.
12. Removed some more dmesg spam to keep logs clean and fast.
13. Linux 3.4.82
14. New ADB binary for wifi support.
15. Ramdisk merge from the CM changes for AOSP.
16. KTweaker: KTweaker update to 6.4 adding all the features from above for wake functions and new Fast Charge options.
17. KTweaker: Added menu item on main screen to quick toggle Fast Charge for Enabled/Disabled.
18. Date added to the OP links so everybody knows what the last date that particular kernel was updated last.
Change Log 02.24.2014
1. KTweaker: KTweaker update to 6.2.
2. KTweaker: New Widget by request from you guys, its a quick Profile chooser, simply click the text area left of the "Set" (if you see "-----" then it means you never did a restore profile) button and it will scroll thru all the profiles you have on your phone. Once you have the one you want, click the "Set" button . The widget is also sizable so you can size it from 1x1 all the way up to 4x1.
3. Merged in TW 4.4 into GE 4.4 version, sound is much crisper and louder
4. Added faux sound to TW 4.4
5. ktoonservativeq: New tunables called super_conservative_screen_on and super_conservative_screen_off (remove old super_conservative) so people can choose when they want to go super conservative. Be sure to go set these items if you used the old super_conservative item.
6. Added my newest settings to the KTShop as ktoonsified v5.
7. Linux 3.4.81
8. Changed upgrade routine to not try to upgrade files with .xml extention in the /ktweaker/ folder
9. Couple other general fixes in KTweaker and KTmonitor.
10. Added PPP protocol for people using USB network/modem devices.
11. BFQ-v7r2
Change Log 01.23.2014
1. Stop charging from obeying Fade mode by default
2. LEDs: Add tunable to set led fade mode while charging. Cycling cable to take effect is required.
3. AOSP 4.4: gcc-wrapper: force python version 2.
Change Log 01.17.2014
1. KTweaker: New feature by request from someone (can't remember who) to set a password to get into the UI (Under Extras - > UI Password). Feature is disabled by default leaving password blank.
2. KTweaker: New feature to control the LEDs for notifications derived from vladnosferatu and invano implementation + some extras (see next 9 items)
3. KTweaker: LED Fade Mode - lets you choose to use the fade effect of LED
4. KTweaker: LED Fade Intensity - lets you choose the light intensity of the LED
5. KTweaker: LED Time on - lets you override the ROMs setting for how long the the LED stays ON
6. KTweaker: LED Time off - lets you override the ROMs setting for how long the the LED stays OFF
7. KTweaker: LED Step Speed 1 - lets you control the steps it takes as it makes the LED brighter/dimmer when in fade mode, play around with it and have fun.
8. KTweaker: LED Step Speed 2 - lets you control the steps it takes as it makes the LED brighter/dimmer when in fade mode, play around with it and have fun.
9. KTweaker: LED Step Speed 3 - lets you control the steps it takes as it makes the LED brighter/dimmer when in fade mode, play around with it and have fun.
10. KTweaker: LED Step Speed 4 - lets you control the steps it takes as it makes the LED brighter/dimmer when in fade mode, play around with it and have fun.
11. KTweaker: LED Step Bit Shift - lets you control the main speed that the LEDs go brighter/dimmer when in fade mode, play around with it and have fun.
12. KTweaker: No all number and text inputs will automatically bring up the keyboard
13. KTweaker: New KTweakerWFC widget that is a 2x1 widget containing ONLY the Fast Charge toggle
14. Added BIC TCP Congestion control
15. Added HSTCP TCP Congestion control
16. Added HYBLA TCP Congestion control (I will be testing this one today as I heard a couple of reports that i really increases download speeds)
17. Added HTCP TCP Congestion control
18. Added VEGAS TCP Congestion control
19. Added RENO TCP Congestion control
20. Added SCALABLE TCP Congestion control
21. Added LP TCP Congestion control (I have been using this one for last 3 days with great speed increase)
22. Added YEAH TCP Congestion control
23. Added ILLINOIS TCP Congestion control
24. WiFi: filter multicast during sleep for AOSP 4.4 to help wifi wakelocks/better deep sleep. All other version already had it so dont ask to add it to other versions.
25. Linux 3.4.77
Change Log 01.13.2014
1. ktoonservativeq: Added new tunable called super_conservative. When enabled (enter a 1) this will dramitacally reduce the bouncing effect from Min Mhz and the amount of hotplugging. Performance may take a hit for the really picky user but 95% of the people that have been testing say its not enough to bother them.
2. Linux 3.4.76
3. Fix for TW 4.3 slow motion recording (thanks @elesbb for testing for me ).
4. Tweaked disable hotplugging while music/video is playing option.
5. Updated my setting in Post 3 so go check it out.
6. Added pac framework compatibility to AOSP 4.4
7. KTweaker 5.1 for all versions.
Change Log 01.05.2014
1. Upgraded Linaro to newest compiler for ALL versions.
2. Added about 200 ramdisk tweaks from my Nexus 10 kernel for ALL versions.
3. Wireless charging will now work with the Min Mhz option while charging, by request from @1Raiders (under extras).
4. ktoonservativeq: New option added to disable hotplugging while music/video is playing. Should help the few people that have trouble playing music with screen off.
Change Log 01.03.2014
1. Upgraded Linaro to newest compiler.
2. Massive amount of ramdisk updates from CM.
3. Added about 200 ramdisk tweaks from my Nexus 10 kernel to see how it goes.
4. Added dynamic fsync by request from you guys.
Change Log 01.01.2014
1. Happy NEW YEAR EDITION
2. Merged in more stock ramdisk to try and fix installing from external sd.
3. Linux 3.4.73
4. Linux 3.4.74
5. Linux 3.4.75
Change Log 12.30.2013
1. Made a BUNCH of adjustments for INTL Google Edition KITKAT 4.4 VERSION.
2. Hopefully reboots are gone, just left with PURE AWESOME!!!!!!!!
3. If you are already on the test kernel, this is the same, no need to redownload.
Change Log 12.22.2013
1. TW and TWGE: ktoonservativeq: Added "touch_boost_gpu" option. Be sure if you are using the max GPU frequency that if you adjust the max, also adjust the "touch_boost_gpu" option.
2. TW and TWGE: Linux 3.4.73
3. TW and TWGE: Linux 3.4.74
4. TW and TWGE: Linux 3.4.75
Change Log 12.21.2013
1. SUPER CRAZY WACK FUNKY SPEED EDITION!!!!!!!!!!!
2. cpufreq: Some general re-write to make freq changes smoother and more efficient
3. acpuclock-8960ab; Update from ML4
4. subsystem: Add extra checks to make sure subsys_domain and iommu_domain are NOT NULL
5. msm: msm_bus: More checks to insure pdata and bus driver vars are not in error and NO NULL
6. grp3d_low_vectors: Bump MBPS to 1700 for low vectors for better low speeds
7. gfx3d_fs_data: Change reset_rate 27000000 from 1800000. Remove 1800000 from clk_tbl_gfx3d. Increase log length for msm_rpm
8. dcvs: Set msm_dcvs_enabled = 0 when msm_dcvs_scm_init() fails adn be sure to return early when msm_dcvs_enabled == 0
9. perf_event_msm_krait_l2 sync with ML4
10. scm: Rewrite scm_call funcs and ML4 merges
11. Linux 3.4.75
Change Log 12.19.2013
1. ONLY USE THIS WITH CM 11 BUILT ON 12.18 OR NEWER!!!!!!!
2. Prox sensor
3. Fix for Battery issues on builds 12.18 and newer
4. ktoonservativeq: Added "touch_boost_gpu" option. Be sure if you are using the max GPU frequency that if you adjust the max, also adjust the "touch_boost_gpu" option.
Change Log 12.18.2013
1. ONLY USE THIS WITH CM 11 BUILT ON 12.18 OR NEWER!!!!!!!
2. Fix battery update for the 2nd day in a row!!!!!!!!!!!!!!!!!!!!!!!!!!
Change Log 12.17.2013
1. ONLY USE THIS WITH CM 11 BUILT ON 12.16 OR NEWER!!!!!!!
2. Upgrade camera to ML4 source from Samsung
3. Sync GPU/Display drivers from ML4
4. cpufreq: interactive: Allow 1 ms error in above_hispeed_delay
5. cpufreq: interactive: Reset floor_validate_time if busy at max for 100ms
6. cpufreq: interactive: Add a sampling_down_factor for max frequencies
7. Many msm: msm_fb updates
8. Many msm: msm_mdp updates
9. Many msm: msm_vidc updates
10. Updated healthd binary for charging routines for CM 11
11. ENJOY!!!!!!!!!!!!!!!!!!
Change Log 12.12.2013
1. Linux 3.4.72
2. Linux 3.4.73
3. Linux 3.4.74
4. Ramdisk sync for CM 11.
5. Use Google Edition wifi driver in AOSP 4.4.
6. Compatiblity for 4.4.2.
7. TMobile guys will use the INTL version for Google Edition
Change Log 11.28.2013
1. Release version of KITKAT for Google Edition
2. Add extsdCard to ramdisk so apps that have not been updated for Kitkat will work.
Change Log 11.16.2013
1. Updated ramdisk for CM11 to latest from http://sourceforge.net/projects/unofficial-cm/files/Nightlies/.
2. Above includes more sdcard pathes and radio/3G/4G patches
3. ONLY LOAD THIS WITH NEWEST 11/16 OR NEWER ROMs
Change Log 11.14.2013
1. Change ramdisk for CM11 for external SD mounting for todays release of ROMs for all versions.
2. Change File name to KK instead of JB for all versions.
3. Couple of minor fixups.
Change Log 11.13.2013
1. Change ramdisk for CM11 for external SD mounting for todays release of ROMs.
2. Change File name to KK instead of JB.
3. OTA will work with new KK version after flashing this new update.
Change Log 11.12.2013
1. Change ramdisk for I9505 phone to match I9505 version of CM11 for external SD mounting.
2. Change File name to KK instead of
Change Log 11.11.2013
1. Added Kitkat version
Change Log 11.08.2013
1. CM sync from late night 11.4 updates
2. Plus 1 update from CM on 11.5

My Settings, F2FS, Extras and faq's
My settings
Main Settings-> CPU Settings Screen
governor = ktoonservativeq
Min Mhz = 189
Max Mhz = 1998
Main Settings-> Scheduler/SD Settings Screen
scheduler = sio
Internal Read Ahead = 1024
External Read Ahead = 1024
Voltage Screen
UV'd 50mv across the board for CPU and 75 for GPU (use menu button for hidden menu option to globally subtract)
Main Settings-> CPU Settings->Screen OFF Settings Screen
Screen OFF Profile Mhz = 702
Disable Screen Off Mhz Call = Enabled
Main Settings-> GPU Settings Screen
GPU Max Mhz = 504
Screen OFF GPU Max Mhz = 128
GPU governor = simple
Main Settings-> TCP/IP Settings Screen
Congestion Control=hybla
Main Settings-> LED Settings Screen
LED Fade Mode = Enabled
LED Time on = 3000
LED Time off = 3000
Main Settings-> CPU Settings->Governor Adjustments Screen
block_cycles_offline_screen_off=1
block_cycles_online_screen_off=22
block_cycles_raise_screen_off=22
down_threshold_screen_off=72
down_threshold_screen_off_hotplug_1=73
down_threshold_screen_off_hotplug_2=74
down_threshold_screen_off_hotplug_3=75
freq_step_lower_screen_off=8
freq_step_raise_screen_off=1
super_conservative_screen_on=0
super_conservative_screen_off=1
sync_extra_cores_screen_on=1
touch_boost_cpu = 1242
touch_boost_cpu_all_cores=1
sampling_rate_screen_off = 90000
touch_boost_gpu = 504
up_threshold_screen_off=85
up_threshold_screen_off_hotplug_1=86
up_threshold_screen_off_hotplug_2=87
up_threshold_screen_off_hotplug_3=88
ALL THE REST ARE STOCK
__________________________________________________________________
F2FS Links for using F2FS with my AOSP 4.4 kernel
http://goo.gl/HLz4al
__________________________________________________________________
Governors
ktoonservative Governor
This governor is based on conservative, but added some tunable vars and made it a hotplugging governor unlike conservative. With the settings I included stock it is probably the most responsive gov and is pretty good at saving battery as well. Especially with my screen off option to limit the CPU top Mhz. Hope that answers all ur questions.
Governors and schedulers explained:
http://forum.xda-developers.com/showthread.php?t=1687578
http://forum.xda-developers.com/showthread.php?t=1369817
http://tinzdroid.blogspot.com/2012/07/android-kernel-governors-modules-io.html
http://forum.xda-developers.com/showpost.php?p=21638852&postcount=56
Enable ZRAM: Flashable zip
http://db.tt/8vssawIO

well that was quick lol.

Yay! Is this Loki'd?

:highfive: :victory:
I love you.

ChaosMinionX said:
Yay! Is this Loki'd?
Click to expand...
Click to collapse
Yes, as long as u have custom recovery you are good to go . I used TWRP. :good: :highfive:

I need this... And thus my hate for locked bootloaders increases threefold.
Sent from my SAMSUNG-SGH-I337 using xda premium

ktoonsez said:
Yes, as long as u have custom recovery you are good to go . I used TWRP. :good: :highfive:
Click to expand...
Click to collapse
You might want to add that its Loki in the op so people know its safe for att
Sent from my SAMSUNG-SGH-I337 using Tapatalk 2

Ktoonsez to save the day!!! Flashing!!

WOO!

Im somewhat new to kernels.
By flashing this is it going to make my phone automatically run better or does this just give me the option to tweak myself and figure out how to make the phone run better?
Sent from my SAMSUNG-SGH-I337 using Tapatalk 2

ktoonsez said:
ktoonservative Governor
This governor is based on conservative, but added some tunable vars and made it a hotplugging governor unlike conservative. With the settings I included stock it is probably the most responsive gov and is pretty good at saving battery as well. Especially with my screen off option to limit the CPU top Mhz. Hope that answers all ur questions.
Governors and schedulers explained:
http://forum.xda-developers.com/showthread.php?t=1687578
http://forum.xda-developers.com/showthread.php?t=1369817
http://tinzdroid.blogspot.com/2012/07/android-kernel-governors-modules-io.html
http://forum.xda-developers.com/showpost.php?p=21638852&postcount=56
Click to expand...
Click to collapse
Ktoonservative?
I dont see that on the governor list lol

awesome! must feel good to use your own kernel @ktoonsez!!
Sent from my SAMSUNG-SGH-I337 using Tapatalk 4 Beta

Thanks man! Running great. Can't wait for a CM compatible kernel.
Sent from my SAMSUNG-SGH-I337

jetlitheone said:
Ktoonservative?
I dont see that on the governor list lol
Click to expand...
Click to collapse
Not in there yet, thats the next step now that I can use the kernel :good:

And we're off!

ktoonsez said:
Yes, as long as u have custom recovery you are good to go . I used TWRP. :good: :highfive:
Click to expand...
Click to collapse
You are my hero. Haha its good to see you and Task650 over here!

ktoonsez said:
Not in there yet, thats the next step now that I can use the kernel :good:
Click to expand...
Click to collapse
Lol anyway to get rid of the message saying its detected an application doing blah blah blah lol and wants you to reboot..

jetlitheone said:
Lol anyway to get rid of the message saying its detected an application doing blah blah blah lol and wants you to reboot..
Click to expand...
Click to collapse
Delete the /system/app/Knox files.