I want to make sure I'm not trippin', I've searched all thru the dev forum, and I don't see a non overclocked kernel. everyone complains about battery life but they are using a kernel that wasn't geared for battery life. oc kernels are for performance and bragging rights. we need a stock kernel with uv and ram optimization along with battery optimization mods
Sent from my Desire HD using XDA App
boimarc89 said:
I want to make sure I'm not trippin', I've searched all thru the dev forum, and I don't see a non overclocked kernel. everyone complains about battery life but they are using a kernel that wasn't geared for battery life. oc kernels are for performance and bragging rights. we need a stock kernel with uv and ram optimization along with battery optimization mods
Sent from my Desire HD using XDA App
Click to expand...
Click to collapse
Why not just not overclock? Also, the kernel that comes in Inspired Ace isn't overclockable.
There are many battery saving options! If you have the Leedroid kernel, in setcpu you have the option of running your proccesor at Powersave, performance,smartass and so on...this is also in a few other kernels but I am not sure which ones at the moment.
And if you are really hyped up on saving battery, shutoff haptic feedback, turn of data when you are not using it, lower screen brightness, Use a task killer to kill stray apps(if you were playing angry birds kill it afterwards).
These are a few things you can do that will increase your battery life significantly...
With an overclock capable kernel, you can underclock. I run mine at 921 MHz and don't notice any performance hit. I've tweaked the undervolt to as low as I can get away with. I get pretty awesome battery life that way.
Before you ask, I'm using a kernel I compiled myself from HTC's latest linux source for the Inspire. It's essentially stock with only the addition of the frequency table and hooks for OC/UV.
Gene Poole said:
With an overclock capable kernel, you can underclock. I run mine at 921 MHz and don't notice any performance hit. I've tweaked the undervolt to as low as I can get away with. I get pretty awesome battery life that way.
Before you ask, I'm using a kernel I compiled myself from HTC's latest linux source for the Inspire. It's essentially stock with only the addition of the frequency table and hooks for OC/UV.
Click to expand...
Click to collapse
This.
Simply underclocking will solve your problems. I prefer to run @1.4 Ghz. I have everything optimized for speed & efficiency and still don't lose in battery performance.
Running CM7 with LordMod UE 2.6 kernel and smartass CPU governor, I can set the max speed to 768mhz with very little performance hit noticed. I might just keep it that way, haven't decided yet. Scrolling is still smooth, Angry Birds is still smooth. The cool thing about running max 768mhz with the pinky undervolt script is the CPU voltage never goes above 900mv.
I'm running CM7 with nightly 91 and on my Vibrant, they made a kernel that was stock uv no oc and u could use it all day, literally....
Sent from my Desire HD using XDA App
Is there any difference in battery life between BFS and CFS?
From the research I've done CFS seems to be better but I'm not 100% sure so I could be wrong.
Sent from my Nexus S 4G
CFS (completely fair scheduler) usually handles all tasks "equally" where as BFS (brain f*ck scheduler) dedicates all its processing power to whatever task you are currently doing. in theory, CFS should produce bettery battery life, but like the above poster said, that could be completely 100% wrong. it really depends on how you use your device and what tasks you use the most, etc....at least this is the understanding I have of the difference between CFS and BFS. i am currently running a CFS kernel build and have exceptional battery life, but then again I am a "conservative" user. as in I turn off things when not using it, don't use live wallpapers often, etc. best thing you can do is nandroid backup and test both out for a reasonable time and see which works best for you. also keep in mind every single device is different too. some handle OC better than others, so the same reasoning can be applied to other things.
Personally like BFS more
But some rom like MIUI rom prefer CFS. Haha.
window7 said:
Personally like BFS more
But some rom like MIUI rom prefer CFS. Haha.
Click to expand...
Click to collapse
Correct.
10chars
So I've been using Morfics Trinity kernels since I got my NS back because they are just awesome, but I once Ezekeel released a kernel I wanted to try something new, I just have a few questions, I am running Quadrant and hitting half the IO as morfics kernels, running Bionix 1.5 which has the IO patch in it so I'm wondering why it's so low.
I have it to Live OC to 110 which gives the same 220mhz bus as Morfics kernels unless I'm mistaken, why is the IO so low compared to morfics and as far as the ARM voltages and INT voltages, what do they control exactly and what is the lowest safest voltage for most NS'. I'm using NSTools for all these mods.
There is a thread on voltages in the dev section, but it will vary from device to device. The lowest safe voltage for yours may be stock, or may be much lower. You could pick one voltage at one freq and lower it by five. Run like that for a few hours. if problem free, pick the next freq and lower that by five... It'll take a while but you'll be more certain of the limits.
Sent from my SNES
Serious_Beans said:
So I've been using Morfics Trinity kernels since I got my NS back because they are just awesome, but I once Ezekeel released a kernel I wanted to try something new, I just have a few questions, I am running Quadrant and hitting half the IO as morfics kernels, running Bionix 1.5 which has the IO patch in it so I'm wondering why it's so low.
I have it to Live OC to 110 which gives the same 220mhz bus as Morfics kernels unless I'm mistaken, why is the IO so low compared to morfics and as far as the ARM voltages and INT voltages, what do they control exactly and what is the lowest safest voltage for most NS'. I'm using NSTools for all these mods.
Click to expand...
Click to collapse
its not only about cpu and bus/gpu speeds, otherwise all the kernels here would be at the same performance levels. each of our wonderful developers adds their own recipe of optimizations too. plus it matters how they are compiled(toolchains), kernel versions, and more.
What are the difference between matrix kernel bfs and matrix kernel cfs ?? Bfs and Cfs what is better and why?
Bfs seems to work with UI speed better. Meaning what you see directly on the screen will seem faster however when there alot of tasks the rom will lag alot as background tasks are not really concentrated on.
CFS is a completely fair scheduler and every process is treated equally. Everything will seem to be faster and even with lots of multitasking everything will remain smooth.
Its a choice. You choose.
I mighr\t be wrong, so everyone else correct me if i'm wrong
BFS works better when you are using mainly a single app like a game or the browser but CFS works better for most people as it is multitasking. Also BFS can be unstable at times.
Sent from my Nexus S using xda premium
BFS is for gamers. CFS is a more practical use. CFS saves battery, is more stable, and can run more than major apps without lag and choppyness.
Nexus S (GSM i9020a)
AOKP (Build 25)
Eugene's Kernel (Speedy 7)
OC 800/100 (Lionheart)
Live OC (105)
hi,
you will find the answer to your question in this post
http://forum.xda-developers.com/showpost.php?p=22134559&postcount=4
here is the entire thread if you want to read more about governors, etc.
http://forum.xda-developers.com/showthread.php?t=1369817
hope that helps
Welcome to decimalman's kernel playground!
As the name suggests, dkp is a hodgepodge of features and tweaks that I wanted to play with. It should get excellent battery life without feeling sluggish. It doesn't come with its own tuner app, so pick your favorite. Personally, I like Trickster MOD and Kernel Adiutor, so I go out of my way to make things work in them. Most other apps should work, too.
Features:
Overclocking up to 2.1 GHz, but you'll need to increase your voltages to get there (if you can get there at all)
Underclocking down to 54 MHz, with stability improvements
Undervolting compatible with most apps
Fast charge without unplugging first
Glorious animations for the notification and softkey LEDs
Well-integrated erandom means you don't need CrossBreeder or Seeder (recent AOSP builds use ISAAC instead)
freelunch and tierservative governors for optimal battery life without sacrificing responsiveness
Automatic mpdecision and auto-hotplug are only enabled when needed
Adjustable minimum voltage for stability on finicky processors
Optimized UKSM to free up some extra memory
Code optimizations for size and speed
Compiler optimizations (-O3, LTO, and more) because faster is better
Donors: Thanks, everyone! Your generosity is much appreciated. :good:
drpenguino, 0xScott, vmancini3 (twice! :good, Ch4m3l30n, rompnit, Mystique, ryandubbz, techdog, ElwOOd_CbGp, ScOULaris, ZipAddict
Remember:
Nandroid!
last_kmsg and/or logcat or it didn't happen.
Other kernels have their own threads or forums. Discuss them there.
Image dumps (settings, battery life, whatever) belong inside [HIDE][/HIDE] (that's HIDE, if you're on the mobile app) tags.
Be silly. We're here to have fun.
Installation:
Reboot to recovery. I recommend that one recovery...you know, the one that flashes zips? I forget what it's called.
Flash dkp. Optionally, rename and flash dkp-vmin-XXX.zip (see below).
Reboot.
Undervolting:
Undervolting on dkp is more complex than other kernels. Some processors get unstable at lower voltages, so (like the stock kernel) dkp keeps the processor voltage above 1150 mV by default. I refer to this limit as the minimum voltage. In order to undervolt, you'll need to lower the minimum voltage: if you use Trickster MOD or Kernel Adiutor, just disable "Override Minimum Voltage", otherwise rename dkp-vmin-XXX.zip to e.g. dkp-vmin-600.zip (which would apply a 600 mV minimum voltage) and flash it. If this causes instability (crashes, audio/video glitches, etc.), try using dkp-vmin-XXX.zip to apply a higher minimum voltage (somewhere between 950 and 1050 mV seems to work well for most people).
Downloads:
MediaFire:
All Downloads
dkp-vmin-XXX.zip
Solidfiles (Make sure you have an adblocker!):
All Downloads
dkp-vmin-XXX.zip
Source: I'm always happy to see my code used, so cherry-pick away. I'll even put together feature patches if you ask nicely.
Bugs:
Let me know.
Stable changelog:
3/3/13: Initial release for d2spr. Didn't get around to making threads for other carriers.
4/8/13 (3.0):
FauxSound support
Strip more useless stuff
A few bonus optimizations
4/8/13 (3.4):
Port everything except erandom from 3.0
Enhance cpufreq for easier configuration
4/24/13 (3.4):
Bugfixes: better support for tuner apps, fixed potential SOD bugs, automatic mpdecision fixups, etc.
Lots of CM/CAF/Linux updates
Working AssWax governor
Trinity colors support
sio, zen I/O schedulers
erandom is back!
Built with a super-fancy Linaro GCC 4.8.1-dev compiler toolchain for maximum -O3 goodness
Probably lots more, but there's hundreds of commits to sort through...
5/29/13 (3.4):
Bugfixes: better overclocking support, better hwrng support, etc.
Updates: new CM updates, Linux 3.4.47, updated FauxSound driver, added invisiblek's new panel colors interface
Automatic auto-hotplug
New optimizations, including link-time optimization and an updated GNU+Linaro GCC 4.8.1-dev toolchain
6/14/13 (3.4):
Bugfixes: fix several critical bugs in the 5/29 release.
9/7/13 (3.4):
Fixes for OC, UV, auto-hotplug.
A few new optimizations.
Synced up with CM.
9/20/13 (TW):
Ported everything from AOSP to TW.
9/20/13 (4.3):
Merged 4.3 from CM into the existing 4.2 code.
Current experimental branches:
Nothing interesting at the moment.
Goodies:
dkp doesn't come with its own splash screen. However, the dkp installer (i.e. the install zip) is smarter than you think, and can apply a custom splash screen for you. Here's how:
Create a folder on your internal storage named "dkp"
Copy a PNG image into the directory, and rename it "splash.png". Alternatively, copy an RLE image (i.e. from a flashable custom splash screen zip) and rename it "splash.rle". Ideally, the image should be roughly 1280x720 to begin with, since it won't be resized.
The image will be used as your splash screen whenever you flash dkp. Reflash to apply initially.
mikedavis120 has put together a how-to video that covers tweaking dkp for optimal battery life. If you're new to dkp, take a look! He also put together a zipped collection of apps that will come in handy while tuning dkp. It also includes a flashable zip, "dkp-debug_v1.zip". After flashing it, running
Code:
su
dkp
from a terminal emulator will collect lots of useful debug information that will make it much easier for me to track down the issue you're having. :good: mikedavis120 recommends installing SuperSU (included in the zip) instead of what's included in you ROM.
sysfs:
It's possible to adjust all the settings available in dkp without using apps. Because they show up as files, settings can be adjusted with file managers, terminal emulators, adb and initscripts. Here's the most interesting files inside sysfs:
/sys/devices/platform/mipi_samsung_oled.513/lcd/panel/panel_colors (not available on newer AOSP builds): display tint (0 = very red, 2 = default, 4 = trinity colors)
/sys/class/misc/gammacontrol (only available on newer AOSP builds): various color controls. See this post for details on enabling Trinity colors on builds that use these controls.
/sys/devices/system/cpu/cpu<N>/cpufreq/UV_mV_table: voltage table
/sys/devices/system/cpu/cpu<N>/cpufreq/scaling_...: scaling_governor is the governor, scaling_min_freq and scaling_max_freq are the minimum and maximum frequencies, scaling_available_governors and scaling_available_frequencies show the available governors and frequencies
/sys/kernel/dkp/force_fast_charge: fast charge
/sys/kernel/dkp/link_core_settings: when linked (the default), frequency settings and some governors are automatically copied to the other core
/sys/kernel/dkp/vmin: minimum processor voltage in mV
/sys/kernel/mm/uksm/run: activate UKSM
auto-hotplug tuners:
These show up in the governor settings for any governor that doesn't do its own hotplugging. They only take effect when using auto-hotplug, so you'll probably need to disable mpdecision in Trickster.
hotplug_intpulse: when set to 1, automatically turns core 2 on whenever the screen/buttons/whatever is pressed. Default is 0.
hotplug_sampling_periods: number of samples to use for average number of running tasks. Default is 15.
hotplug_sampling_rate: number of 'jiffies' (currently 1 jiffy = 10 ms) between each sample of running tasks. Default is 20 (0.2 sec).
hotplug_enable_one_threshold: the average number of running tasks required to turn core 2 on, multiplied by 100. Default is 125 (1.25 tasks on average).
hotplug_disable_one_threshold: the average number of running tasks required to keep core 2 on, multiplied by 100. Default is 250 (2.5 tasks on average).
freelunch/nanolunch tuners:
freelunch and nanolunch aren't materially based on other governors, so their configuration is quite different than other governors. There's lots of tuners, since I haven't really decided on an ideal tuning. I encourage experimentation! I'll explain a bit of how these governors work before actually listing the tuners.
Generally speaking, there are two modes: in "normal" mode, sampling is done occasionally and frequency is generally increased slowly; in "interactive" mode, sampling is done much more quickly, and frequency increases much more quickly. "Interactive" mode ends after several samples of very low usage. The idea of a "hispeed" frequency is used in lots of governors, and it refers to the frequency that the CPU will jump to when more CPU usage is needed; generally, it's a generous estimate of how much CPU will be needed. Here, the hispeed frequency is adjusted on-the-fly, increasing when more CPU is needed and gradually decreasing when the CPU is idle. In "interactive" mode, the hispeed frequency is kept fairly high so that everything will feel snappy.
Hotplugging is taken care of in the least complicated (and in my opinion, most reasonable) way possible: if core 1 is using lots of CPU, and there are several tasks running (in other words, if it's likely that core 2 will have something to do), core 2 is turned on; if either core isn't doing much except using power, core 2 is turned off.
sampling_rate: the usual
hotplug_up_cycles: number of consecutive heavily-loaded samples before core 2 is turned on
hotplug_down_cycles: number of consecutive lightly-loaded samples before core 2 is turned off
hotplug_up_load: number of running tasks required to bring core 2 online
hotplug_up_usage: number of used CPU cycles (in thousands per second) required to bring core 2 online
hotplug_down_usage: number of used CPU cycles (in thousands per second) required on both cores to keep core 2 online
overestimate_khz: number of CPU cycles to overshoot usage by in "normal" mode
hispeed_thresh: if CPU usage is within this many cycles (in thousands per second) of the maximum frequency, frequency will be increased to the hispeed frequency. Generally, hispeed is pretty low in "normal" mode, and fairly high in "interactive" mode.
hispeed_decrease: when the CPU is sitting idle, the hispeed frequency is decreased by this amount each sample (this isn't ideal, but it works)
interaction_hispeed: the initial hispeed frequency when switching to "interactive" mode
interaction_return_cycles: number of consecutive lightly-loaded samples before returning to "normal" mode
interaction_return_usage: number of used CPU cycles (in thousands per second) required to stay in "interactive" mode
interaction_panic (nanolunch only): when set to 1, allows aggressively jumping past the current hispeed frequency under some circumstances
interaction_sampling_rate/overestimate_khz: equivalent to the "normal" versions of the tuners, these take effect in "interactive" mode
This looks great - especially excited about your custom governor! Thanks!!
Sent from my SCH-I535 using xda app-developers app
Glad we have another kernel dev. But do you plan on releasing a tw kernel? I run tw 98% of the time and would love to try it out. Thanks for your work regardless
PsiPhiDan said:
This looks great - especially excited about your custom governor! Thanks!!
Sent from my SCH-I535 using xda app-developers app
Click to expand...
Click to collapse
freelunch is absurdly simple, but does its job well. Let me know what you think. Happy flashing!
aypeeootrek said:
Glad we have another kernel dev. But do you plan on releasing a tw kernel? I run tw 98% of the time and would love to try it out. Thanks for your work regardless
Click to expand...
Click to collapse
I don't run TW, so I don't have any plans to release a TW kernel. If there's enough interest, I suppose I could get to work on one though.
Interesting. Looks cool man, will check it out
Sent from my SCH-I535 using Tapatalk 2
I'm excited to give this a shot!
Sent from my SCH-I535 using xda app-developers app
flashaholic commencing flash!
Anyone using trickster mod with this kernel?
Sent from my SCH-I535 using Tapatalk 2
Love this kernel! Freelunch is amazing
Sent from my SCH-I535 using xda premium
This kernel run pretty good!!
Sent from my SCH-I535 using xda app-developers app
masri1987 said:
Anyone using trickster mod with this kernel?
Sent from my SCH-I535 using Tapatalk 2
Click to expand...
Click to collapse
It's the recommended tuner app, and plenty of people are using it (mostly on Sprint and AT&T). It shows some options that are completely bogus (like GPU governor), but I've added a few extras that only Trickster supports.
Thanks for the encouraging feedback, everyone! It's much appreciated. :good:
Kudos on this kernel. It has been perfect for me so far.
Running good on my d2usc! What scheduler do you recommend?
Sent from my SCH-R530U using Tapatalk 2
New 3.4 experimental builds are going up!
governors is building now, and has sio and zen. It'll eventually have a few new governors, but I haven't gotten everything ported yet.
gcc480 is up now, and is a test to make sure GCC 4.8.0 isn't causing any crazy bugs. It's also got sio and zen.
Edit: I forgot about you, trvbone. I don't have a preferred scheduler. I usually just use sio. I've never had a positive experience with ROW, but that might just be bad luck on my part.
More edit: I'm building a 3.0 kernel with trinity colors support and GCC 4.8.0 now. It should be up shortly.
decimalman said:
New 3.4 experimental builds are going up!
governors is building now, and has sio and zen. It'll eventually have a few new governors, but I haven't gotten everything ported yet.
gcc480 is up now, and is a test to make sure GCC 4.8.0 isn't causing any crazy bugs. It's also got sio and zen.
Edit: I forgot about you, trvbone. I don't have a preferred scheduler. I usually just use sio. I've never had a positive experience with ROW, but that might just be bad luck on my part.
Click to expand...
Click to collapse
I'm no noob when it comes to kernel lingo, but I'm not sure what the dif is here between the kernels listed as governors and gcc480. Are these two different kernels? I'm not aware of what gcc480 is I guess. Sorry until recently I was a dedicated lean kernel user and don't know all of the terminology since lk was pretty plain Jane.
I'm not a huge fan of row, but that's what I'm using right now cause it's quick just a little sketchy sometimes.
Sent from my SCH-R530U using Tapatalk 2
trvbone said:
I'm no noob when it comes to kernel lingo, but I'm not sure what the dif is here between the kernels listed as governors and gcc480. Are these two different kernels? I'm not aware of what gcc480 is I guess. Sorry until recently I was a dedicated lean kernel user and don't know all of the terminology since lk was pretty plain Jane.
I'm not a huge fan of row, but that's what I'm using right now cause it's quick just a little sketchy sometimes.
Sent from my SCH-R530U using Tapatalk 2
Click to expand...
Click to collapse
I have a tendency to describe things in the least understandable way possible. Sorry about that.
Hopefully, there's no noticeable differences between the two builds. I think the gcc480 build might benchmark a bit better, but I haven't really compared. The only actual difference is which compiler I used to build the kernel, which probably doesn't matter for 99% of users.
The governors build is built with the same ol' Linaro nightly toolchains that I've been using, so I expect it to be pretty stable.
The gcc480 build uses a newer, fancier compiler: GCC 4.8.0. I've found at least one new bug with the new compiler (it's fixed in the uploaded builds, don't worry ). I'm not ready to call the gcc480 build stable since it's gotten so little testing, but it's been running great for me all day. I'd love to hear feedback from anyone who flashes it.
Eventually, most other kernels will switch to GCC 4.8.0 (probably once Linaro releases a full-featured build). I think gideonx (of BMS fame) is planning to switch sometime soon, and I would expect ktoonsez to switch pretty soon too.
decimalman said:
I have a tendency to describe things in the least understandable way possible. Sorry about that.
Hopefully, there's no noticeable differences between the two builds. I think the gcc480 build might benchmark a bit better, but I haven't really compared. The only actual difference is which compiler I used to build the kernel, which probably doesn't matter for 99% of users.
The governors build is built with the same ol' Linaro nightly toolchains that I've been using, so I expect it to be pretty stable.
The gcc480 build uses a newer, fancier compiler: GCC 4.8.0. I've found at least one new bug with the new compiler (it's fixed in the uploaded builds, don't worry ). I'm not ready to call the gcc480 build stable since it's gotten so little testing, but it's been running great for me all day. I'd love to hear feedback from anyone who flashes it.
Eventually, most other kernels will switch to GCC 4.8.0 (probably once Linaro releases a full-featured build). I think gideonx (of BMS fame) is planning to switch sometime soon, and I would expect ktoonsez to switch pretty soon too.
Click to expand...
Click to collapse
Thanks for the expl I'll flash tomorrow morning and give it a whirl! Great job BTW. This is now my daily driver!
Sent from my SCH-R530U using Tapatalk 2
decimalman said:
I have a tendency to describe things in the least understandable way possible. Sorry about that.
Hopefully, there's no noticeable differences between the two builds. I think the gcc480 build might benchmark a bit better, but I haven't really compared. The only actual difference is which compiler I used to build the kernel, which probably doesn't matter for 99% of users.
The governors build is built with the same ol' Linaro nightly toolchains that I've been using, so I expect it to be pretty stable.
The gcc480 build uses a newer, fancier compiler: GCC 4.8.0. I've found at least one new bug with the new compiler (it's fixed in the uploaded builds, don't worry ). I'm not ready to call the gcc480 build stable since it's gotten so little testing, but it's been running great for me all day. I'd love to hear feedback from anyone who flashes it.
Eventually, most other kernels will switch to GCC 4.8.0 (probably once Linaro releases a full-featured build). I think gideonx (of BMS fame) is planning to switch sometime soon, and I would expect ktoonsez to switch pretty soon too.
Click to expand...
Click to collapse
Giving it a go now. Do you have any test methods you use to test the stability of a kernel other than the everyday use approach? Thanks for the support, looks sweet:good::good::good: