Related
I have created this thread to focus on overclocking of the gpu, this is still very experimental and it would be great if you all can help test this feature.
There are allot of different settings that can be pushed to the gpu clock, I do not have access to the MSM7200 chip development guide and have no detailed information.
Non camera kernel with keyboard included:
http://tingstenen.dk/data/X1-kernel-modules-2011-03-18-1300457455.zip
How to activate overclocking
Code:
$ su
# cd /sys/module/clock_wince/parameters/
# echo 0xa99 > grp
The number 0xa99 can be replaced with other values to archive different results. See the following gpu overclocking discussion for more details, 0xa99 is the valued I have had positive results with on our x1 of the few options I have tried.
http://forum.xda-developers.com/showthread.php?t=697673
Our MSM7200A chip is default running with CPU 528Mhz and 256Mhz GPU.
I look forward to hear your feedback on this option and hopefully some of you manage to archive even bette results with other settings. It would alse be great if someone found out how to make an widget or app to easily change gpu clock settings.
Will add a non camera kernel with keyboard as modules later.
great job.
X1-kernel-modules-2011-03-18-1300457455 gives me 21.9 fps.
and just tried newest X1-kernel-modules-2011-03-19-1300544600 and its works, GPU overclock is applied automatically, gives me same result.
preston74 said:
great job.
X1-kernel-modules-2011-03-18-1300457455 gives me 21.9 fps.
and just tried newest X1-kernel-modules-2011-03-19-1300544600 and its works, GPU overclock is applied automatically, gives me same result.
Click to expand...
Click to collapse
Hi Preston, thanks for your feedback, I am glad to hear the auto gpu overclock is working. 0xa99 has been hardcoded in the last two kernels. 21.9 is more than I have been able to get, 21.5 with cpu at 614Mhz and 0xa99 applied
im reach 21.9 fps with cpu ovecloched to 672Mhz.
I reached 20.5 fps on Neocore (Sound off) with CPU overclocked to 672MHz and GPU overclocked using 0xa9a - using PureFroyo by Needo, an older build of his. Anything beyond 0xa9a for me, crashes my Xperia once I load apps which required 3D.
n00b3r said:
I reached 20.5 fps on Neocore (Sound off) with CPU overclocked to 672MHz and GPU overclocked using 0xa9a - using PureFroyo by Needo, an older build of his. Anything beyond 0xa9a for me, crashes my Xperia once I load apps which required 3D.
Click to expand...
Click to collapse
Could you try with 0xa99 once more with a slightly lower CPU clock? I have a theory that 0xa99 give us GPU clock half of our CPU clock. It could be the limit of the 3D chip are around 330-340.
duckly said:
Could you try with 0xa99 once more with a slightly lower CPU clock? I have a theory that 0xa99 give us GPU clock half of our CPU clock. It could be the limit of the 3D chip are around 330-340.
Click to expand...
Click to collapse
Sure. Should I try it with 633 MHz? I tried 0xa99 with 672MHz and I get 19.5 instead of 20.5 FPS.
more tests
build: a new F1 Froyo 2.2.2 V3
cpu oc: 692MHz
kernel: X1-kernel-modules-2011-03-19-1300544600
Neocore with sound off: 22.2fps
Can you try with 0xa92 and compare this with your results from 0xa99? It seems to be slightly faster on my 614MHz clocked cpu.
duckly said:
Can you try with 0xa92 and compare this with your results from 0xa99? It seems to be slightly faster on my 614MHz clocked cpu.
Click to expand...
Click to collapse
I just tried 0xa92 with 672 MHz and i got 21.4fps. Got an extra FPS with 0xa92 compared to 0xa9a.
I have done some testing with different values and here is my results so far. The clock calculations is obviously wrong but it is the best I can come up with.
10101 0010 001 0xa91 (614*2)/3 = ~409 neocore not starting
10101 0011 001 0xa99 (614*2)/4 = ~307 21.5 21.2 176(quadrant)
10101 0100 001 0xaa1 (614*2)/5 = ~245 19.5
10101 0001 010 0xa8a (614) /1 = ~614 neocore not starting
10101 0010 010 0xa92 (614) /2 = ~307 21.1 21.0 176(quadrant)
10101 0011 010 0xa9a (614) /3 = ~205 20.1
10101 0100 010 0xaa2 (614) /4 = ~154 17.9
10101 0010 011 0xa93 (614?)/2 = reboot
10101 0011 011 0xa9b (614?)/3 = reboot
10101 0000 100 0xa84 (614/2)/0 = neocore not starting
10101 0001 100 0xa8c (614/2)/1 = ~307 18.1 169(quadrant)
10101 0010 100 0xa94 (614/2)/2 = ~154 14.8 164(quadrant)
10101 0011 100 0xa9c (614/2)/3 =
The best options I have found so far is 0xa99 and 0xa92 being equal. There are still allot of other bits to play around with.
my cpu and gpu are not so lucky
i can daily use cpu at 614Mhz
tryed gpu oc with faryab V3 + 18 march kernel
0xa9b - restart
0xa99 - artifacts, neocore starts but artifacts and it stops
0xa92 - always artifacts and bad graphics
0xa9a - always artifacts but neocore bench finished ok, about 21 fps
without oc neocore is 17fps, quadrant about 270, linpack 2.8
just a curiosity, i remember in older kernels that quadrant much faster (4/500) and linpack was about 4/5, why newer kernels are slower at the same cpu speed?
pirlano said:
my cpu and gpu are not so lucky
i can daily use cpu at 614Mhz
tryed gpu oc with faryab V3 + 18 march kernel
0xa9b - restart
0xa99 - artifacts, neocore starts but artifacts and it stops
0xa92 - always artifacts and bad graphics
0xa9a - always artifacts but neocore bench finished ok, about 21 fps
without oc neocore is 17fps, quadrant about 270, linpack 2.8
just a curiosity, i remember in older kernels that quadrant much faster (4/500) and linpack was about 4/5, why newer kernels are slower at the same cpu speed?
Click to expand...
Click to collapse
The optimal clock for my CPU is also 614Mhz, it can run at 633 but will eventually crash.
Can you try to downclock you cpu one or two steps further and try with 0xa99? I am curious to know if the GPU overclock values are connected to the CPU overclocking, could be that you successfully could use 0xa99 with one CPU step lower and end up with better neocore results.
faryab V3 + 18 march kernel + custom startup.txt
(to change grp frequency i use clock_wince.grp=2713 on startup.txt (2713 = 0xa99 for example, to no OC just left blank, i think it's better manual setting than auto-OC))
tryed one time, and seems to be working with startup setting
neocore - always sound off
cpu: 633600 - reboot
cpu: 614400 - ok
gpu:
-no OC: 18,9
-0xa9a: 20,2
-0xa99: reboot
cpu: 595200
-no OC: 18,7
-0xa9a: 19,8
-0xa99: 21,4
EDIT: i can confirme that startup.txt setting works with gpu freq too with 18 march kernel
i tryed acpuclock.oc_freq_khz=614400 clock_wince.grp=2713 on startup.txt and this time phone doesn't reboot, and i got 21,4 too
One thing to note though..
The last 3 bits of the ns register are the clock source.
{0 => TCXO (19.2 MHz?), 1 => global PLL, 2 => backup pll 0, 3 => backup pll 1, 4 => modem pll, 5 => plltest_rcvr_out (whatever that is), 6 => usb xtal, 7 => plltest_core_in}
This is from msm7200 datasheets. it may be wrong for msm7200A though
afaict, modem pll (4) is pll0 in acpuclock.c (245 MHz), global pll is pll1 (768 MHz), backup pll0 is pll2 (1056 MHz). When the device is overclocked, then
The next 4 bits are the (divider - 1). That is, get those 4 bits, increment by one and you get the divider. During the overclock, pll2 is adjusted. So yes, until we have a proper clock calculation algo for arbitary frequencies, you cannot overclock both cpu and gpu.. But actually imho overclocking cpu gives no performance gain at all..
I'm just a newbie, so I want to know how to open Internal? I try to get it on Market, installed but not working? Could anyone show me the way?
Pardon my bad eng
sp3dev said:
One thing to note though..
The last 3 bits of the ns register are the clock source.
{0 => TCXO (19.2 MHz?), 1 => global PLL, 2 => backup pll 0, 3 => backup pll 1, 4 => modem pll, 5 => plltest_rcvr_out (whatever that is), 6 => usb xtal, 7 => plltest_core_in}
This is from msm7200 datasheets. it may be wrong for msm7200A though
afaict, modem pll (4) is pll0 in acpuclock.c (245 MHz), global pll is pll1 (768 MHz), backup pll0 is pll2 (1056 MHz). When the device is overclocked, then
The next 4 bits are the (divider - 1). That is, get those 4 bits, increment by one and you get the divider. During the overclock, pll2 is adjusted. So yes, until we have a proper clock calculation algo for arbitary frequencies, you cannot overclock both cpu and gpu.. But actually imho overclocking cpu gives no performance gain at all..
Click to expand...
Click to collapse
Thanks for the thorough explanation alex.I was confused at first about this when I saw the topic
luv116 said:
I'm just a newbie, so I want to know how to open Internal? I try to get it on Market, installed but not working? Could anyone show me the way?
Pardon my bad eng
Click to expand...
Click to collapse
Terminal Emulator works very bad with non-US keyboard layout (you have to use virtual keyboard for _ and > char, and it's very annoying).
It's faster (and works much better because of the fresh boot) to change settings from startup.txt, read my post
sp3dev said:
One thing to note though..
The last 3 bits of the ns register are the clock source.
{0 => TCXO (19.2 MHz?), 1 => global PLL, 2 => backup pll 0, 3 => backup pll 1, 4 => modem pll, 5 => plltest_rcvr_out (whatever that is), 6 => usb xtal, 7 => plltest_core_in}
This is from msm7200 datasheets. it may be wrong for msm7200A though
afaict, modem pll (4) is pll0 in acpuclock.c (245 MHz), global pll is pll1 (768 MHz), backup pll0 is pll2 (1056 MHz). When the device is overclocked, then
The next 4 bits are the (divider - 1). That is, get those 4 bits, increment by one and you get the divider. During the overclock, pll2 is adjusted. So yes, until we have a proper clock calculation algo for arbitary frequencies, you cannot overclock both cpu and gpu.. But actually imho overclocking cpu gives no performance gain at all..
Click to expand...
Click to collapse
Hi Alex, thanks allot for your description. It is nice to know what the different options means instead of blindly changing the values
Are the pll clock speeds different when you overclock the cpu?
yes, they are.
btw, i've played with overclocking a bit. changing gpu to 1056 mhz pll doesn't seem to do anything, but overclocking the 768 mhz pll to 960 mhz or more seems to increase performance linearly - my neocore went from 16.5 to 21.5.. but i needed to set mdp (panel) to another pll..
as for the panel, some tweaks allowed to raise score in fps2d from 27 to 34 fps. i hope we can get to somewhere 45 with a bit of overclocking.
all in all, i think we need to rewrite some clock code to allow to change pll speed at runtime and recalculate clocks on the fly
{
"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"
}
SysTune
Optimize under the hood of your system!
** Root Rights required!!! **
This is a system tuning and tweaking tool for advanced users with root access. It allows you to change various system settings to optimize your system.
This is my very first App on the Market. I am open for feedback and try at my best to solve any requests if possible.
It is very advised to properly inform yourself about those settings as i do not take any responsability for any damamge to your device.
NEW FEATURE
Changing priority of processes allows you to prevent lagging or other issues e.g. when a back ground process slow down your phone or you forground app has struggles to do its fluently.
See Help Tab for more informations before using this feature! More Informations and a small Guide will be available in the second or third post in the next days.
Note: The background service for monitoring processes to renice them causes no increased battery drain!
Features:
Changing min/max CPU frequency
Changing cpu governor
Changing advanced governor settings
Voltage Control (SVS and HAVS supported)
Block device settings like IO-Scheduler
Kernel (Scheduler) Tweaks
VM Tweaks
Changing priorities of active processes (renice)
Apply on Boot
Mulit-Core / -CPU support
Realtime CPU Clock Speed and "Time in State"-View of each Core/CPU
Save and load settings individually for each tab (press Menu).
Multi-Core/-CPU supporting CPU Stress Test (New)
Safe Mode ( see in-app Help for Informations )
..... more to come!
NOTE: The availability of the features depends on your system. E.g. if your installed kernel does not provide access to VDD Levels voltage control than it won't be available.
After installation take your time and read the informations on the Help-Tab.
Download on Market
************************************************
If somethings is not working as expected on your device
please post here or email me so that i can fix it for you!
I don't own every device out there
************************************************
The zip file for toggling Safe Mode that can be saved on your SD Card via the button in SysTune can also be found here attached to this post.
Thanks to...
Grzesiek Baran for the new Market Feature Image and his Status Bar Icons!
"The Unknown Noob" aka Daniel S. for his Status Bar Icons!
Download User Settings
This is a section with user contributed settings files for SysTune. Anyone can submit their settings via attachment to a post.
Though i beg to follow some basic rules:
Tell which device, rom (version) and Kernel used
IMPORTANT: Date (and optinal a version number) of your settings. So we now if there was a modification meanwhile!
Short but clear explenation why you use this values
What you did to come to the conclusion to use them
[OPTIONAL] What you changed over the default values of your rom/kernel. (note which were the default values before the change!)
Please follow the rules to make it easier for others to judge if your settings are usefull for them.
A user's settings for CM 10.1 for DHD rom:
Device: Desire HD, Rom: [ROM][UNOFFICIAL] CyanogenMod 10.1 Nightlies / M-Series - nightly from 20.02.2013
Date: Feb., 20, 2013
No renicing used anymore
Using stock clocks and ondemand governor.
Ondemand Governor settings
Misc settings
A user's settings:
Device: Desire HD, Rom: SCI MIUI 1.11.25v1.0, Kernel: lordmod 8.5 cfs
Date: Nov., 30, 2011
Smoother and more battery friendly then default values.
I am using several benchmark apps to test different aspects. Also i am testing overall daily usage. For reliable tests i have some things i repeat to see how the impact of changes of the settings is. Benchmarks used are: NenaMark 2, An3DBenchXL, Quadrant (not very good though), AnTuTu, TAP Benchmark (for internal flash memory), SD Tools (for sd card).
CPU Settings: ondemand
Governor settings
Misc settings
For BFS kernel version use set rr_interval=2 in the misc tab under kernel settings. But for my Rom i stick to CFS currently.
Renice Settings
Some general tips:
The priorities influence the behaviour when two processes that want to do some work at the same time. It influences which process will get more cpu time, thus it may cause lags for the lower priority process.
So in general the default priority of 0 is the one you should keep for most of the processes. But there are some processes that maybe you are not using all the time, but when you want them to use you want them fast and lag free.An example for this is the "phone" process but also the systemui process can improve the behaviour of your GUI in general.
On the other side there are processes that need to do some work in the background. Such process could slow down or cause lags on your currently used app / foreground process. An example for this is the media scanner "android.process.media". Think of reducing its priority to prevent slowing down other things. You won't care if the media scan in the background would need a minute longer to finish if you get a more fluent foreground app
I also got user reports for apps like media players that since they increased their priority now work flawless.
A User's Renice Settings 12 Dec. 2011 (see used rom etc. above!)
Notess:
I increased the the priority for processes that need to respond fast when they actually are needed, like the phone process.
I also increased the priority of my keyoard app to improve its pop upp in some seldom but annoying situations. If you use more than one keyboard app just set an increased value of all of them. As you never will use two at the same time you do not need to decrease the priority of one of them
Beside of other stuff i also increased the priority of my used launcher, adw ex. Add your launcher or replace my entry with one for your launcher. I think com.android.launcher is the process name for the standard launcher. But as you are using it you can see its process in the list of the "add" dialog.
strange, where has the reply of user sergeybrin gone?
anyway, am open for suggestions and reports of issues. if anybody has tried it found that something is not working for their phone i would be thankfull to know what so i am able to fix that.
Optimal settings for LordMod 7.2BFS kernel
Hi a user thanks for the great app.
I'm on Alienmod's CM7 (nightly 208) with LordMod's 7.2BFS kernel and was wondering what the optimum settings are in the "Governor" tab?
I looked at your MIUI thread and saw that you have:
suspend_freq @ 614400
down_differential @ 15
sampling_down_factor @ 50
ignore_nice_load @ 0
up_threshold @ 85
powersave_bias @ 50
sampling_rate @ 80,000
io_is_busy @ 1
so I am using these settings and everything seems ok.. (im using ondemandX 230400min and 1152000max).
Are these settings ok to use for my ROM or are there better settings?
Also i'm currently -50mV undervolted.
Thanks!!
this are still the settings i use and i think they pretty much optimal for aosp roms for the dhd. edit: except that my max fre is 1075MHz
regarding undervolting: carefull and you should only undervolt one freq at a time then test that extesively (e.g. by setting min and max freq to it and running something stressing the cpu for a longer time).
in general it is only needed to undervolt the freqs close to your set max freq as undervolting only makes a significant difference on consumption if there is high load. and on high load your phone switches to higher freqs
p.s. glad you are happy with the app.
I recently discovered due to a nice customer that despite googles license code documentation the licensing server do not provide validation timeout infos. hence some customers may observed that the app failed licensing on connection issues.
Google documentation on this claimed it should work as i expected but it doesn't. Hence i just fixed this now myself and want to apologise for any issues caused by this. I will improve this further in the near future.
Great App
thank you!
@all: There are many roms out there with broken busybox installations. i already have some workaround built in to handle that. i just discovered that one of my workaround had a typo. so if someone tried the app and saw it not working as it should it probably got fixed with the most recent update to 1.2.6.
i would like to see why some people are cancelling the purchase as it is already possible to see exactly what it does on the screen shots. If something is not working as it should i can't fix it without feedback. too many roms and devices out there to have them all and being able to test against.
I've tested unsuccessfully on the tmo g2x running EaglesBlood latest (cm7 based) and the dragon kernal. By testing I mean the drop downs for CPU Max and min show a thin white bar with nothing selectable.
Edit: tested with another kernal, and my guess is they don't support your method for accessing the processors... but I've been wrong before.
thank you for the feedback. But i need the info provided by the feedback button. Please use the feedback button on the help tab to collect some information and send it via email.
if you do not want to send me an email you canstill use that button. it will collect some infos and save them on your sdcard as "systune.inf". cancel the email that opens up. the file will still remain on your sdcard.
attach it here to your next post (maybe you need to rename its extension to .txt). without that info there is nothing i could do.
p.s. you can look into that file to verify that nothing confidential is collected. it is plain text.
EDIT: i saw your edit. does this mean with the other kernel it worked? basically your guessing seems right. but the thing is that my method to acces this values is the ONLY one possible. it is done through the kernel exported values in the sysfs. this is basically the only way to access kernel values at runtime. this custom kernel(s) you are using are either not exporting these stuff or they are doing wrong (by convention).
in the latter case at least i could do a workaround to compensate for their wrong placement of the stuff.
The Load Settings dialog box is not working on BlackIce, same problem as I had on Hydr0g3nmod before. Box just displays Cancel and nowhere to select a file to load. Not critical but would be nice to have. Probably due to the super dark theme. Thanks!
Sent from my Desire HD using Tapatalk
cold y verify that it is indeed only due to the theme? i mean try pressing in the middle of the box where normally the entry of a file to load is located and see if it loads.
if it is just a theme issue, dark text on dark background, then you should inform paradoxx or alienmind about this as this is a bug on their rom. i am simpy using system default theme.
usefull for them to know is that the items to load are listed in a ListView using "android.R.layout.simple_list_item_1" for the items. With these infos they should be able to fix their theme.
p.s. new version with new features coming very soon.
a user said:
cold y verify that it is indeed only due to the theme? i mean try pressing in the middle of the box where normally the entry of a file to load is located and see if it loads.
if it is just a theme issue, dark text on dark background, then you should inform paradoxx or alienmind about this as this is a bug on their rom. i am simpy using system default theme.
usefull for them to know is that the items to load are listed in a ListView using "android.R.layout.simple_list_item_1" for the items. With these infos they should be able to fix their theme.
p.s. new version with new features coming very soon.
Click to expand...
Click to collapse
Thanks, no luck in finding the hidden dialog box but no big deal.I'll wait until the BlackIce theme fix is done, or who knows perhaps I'll be back on sci miui by then
Sent from my Desire HD using Tapatalk
New version with new features available.
Now it supports various kernel tweaks (cfs scheduler tweaks) and vm tweaks. You can find them in the Misc Tab. Also saving/loading is now available for the Misc Tab.
Hi my8,
Do you think that it could be useful to discuss our findings about the tuning of some parameters here or in another section?
Thanks for your VERY useful app.
normally i would say this should be in a device specific thread. but because i wont be allowed to open up a systune thread in each device subforum i think we could do it here.
so feel free to be the first.
as basic rules i think one should always include infos about device/rom/kernel to make the post actually usefull.
new version 1.3.2:
added tunable paramter for BFS kernels in the Kernel settings section under the Misc tab.
a user said:
normally i would say this should be in a device specific thread. but because i wont be allowed to open up a systune thread in each device subforum i think we could do it here.
so feel free to be the first.
as basic rules i think one should always include infos about device/rom/kernel to make the post actually usefull.
Click to expand...
Click to collapse
Ok thanks for that and also for v1.3.2.
I think also that here could be a good place for the discussion of some of the tunable parameters via systune app. Indeed, I think that there should be no such big difference from ROM to ROM (but probably more from device to device...).
This offers also the possibility to give (and get) some information about the parameters that are tunable via Systune.
Among the different group of parameters, due to personal interest, I want to focus on scheduler ones (CFS and now BFS (since v1.3.2)).
And first of all, some theory, because before tuning anything, it is EXTREEMELY IMPORTANT TO UNDERSTAND the meaning of these parameters: here below is a partial copy of http://doc.opensuse.org/products/opensuse/openSUSE/opensuse-tuning/cha.tuning.taskscheduler.html about CFS in opensuse distribution.
NB: I am not an expert in Android, but IMHO I thing that even if Android runs on linux, it must be a lot of difference between running a phone and a desktop. It is why, it is interesting to have this kind of discussion here.
The comment are personal and are there just to start the discussion....
My phone is a HTC Desire HD, with blackIce ROM with LordMod UE kernel v8 CFS.
sched_child_runs_first
A freshly forked child runs before the parent continues execution. Setting this parameter to 1 is beneficial for an application in which the child performs an execution after fork. For example make -j<NO_CPUS> performs better when sched_child_runs_first is turned off. The default value is 0.
OK default value seems logical for me.
sched_compat_yield
Enables the aggressive yield behavior of the old 0(1) scheduler. Java applications that use synchronization extensively perform better with this value set to 1. Only use it when you see a drop in performance. The default value is 0.
OK default value seems logical for me, but Dalvik being a Java VM, 1 could also be logical ?????
Expect applications that depend on the sched_yield() syscall behavior to perform better with the value set to 1.
sched_migration_cost
Amount of time after the last execution that a task is considered to be “cache hot” in migration decisions. A “hot” task is less likely to be migrated, so increasing this variable reduces task migrations. The default value is 500000 (ns).
If the CPU idle time is higher than expected when there are runnable processes, try reducing this value. If tasks bounce between CPUs or nodes too often, try increasing it.
In case of single core processor, IMHO I think that this value must be set high....
sched_latency_ns
Targeted preemption latency for CPU bound tasks. Increasing this variable increases a CPU bound task's timeslice. A task's timeslice is its weighted fair share of the scheduling period:
timeslice = scheduling period * (task's weight/total weight of tasks in the run queue)
The task's weight depends on the task's nice level and the scheduling policy. Minimum task weight for a SCHED_OTHER task is 15, corresponding to nice 19. The maximum task weight is 88761, corresponding to nice -20.
Timeslices become smaller as the load increases. When the number of runnable tasks exceeds sched_latency_ns/sched_min_granularity_ns, the slice becomes number_of_running_tasks * sched_min_granularity_ns. Prior to that, the slice is equal to sched_latency_ns.
This value also specifies the maximum amount of time during which a sleeping task is considered to be running for entitlement calculations. Increasing this variable increases the amount of time a waking task may consume before being preempted, thus increasing scheduler latency for CPU bound tasks. The default value is 20000000 (ns).
For a phone running with a processor > 1GHz I thing that 5000000 is a good value (to be discussed further)
sched_min_granularity_ns
Minimal preemption granularity for CPU bound tasks. See sched_latency_ns for details. The default value is 4000000 (ns).
Same as above with a suggested value of 1000000
sched_wakeup_granularity_ns
The wake-up preemption granularity. Increasing this variable reduces wake-up preemption, reducing disturbance of compute bound tasks. Lowering it improves wake-up latency and throughput for latency critical tasks, particularly when a short duty cycle load component must compete with CPU bound components. The default value is 5000000 (ns).
Same as above with a suggested value of 1000000
sched_nr_migrate
Controls how many tasks can be moved across processors through migration software interrupts (softirq). If a large number of tasks is created by SCHED_OTHER policy, they will all be run on the same processor. The default value is 32. Increasing this value gives a performance boost to large SCHED_OTHER threads at the expense of increased latencies for real-time tasks.
IMHO must be sed = 0 for single core processor....
[To be continued later.....]
I know this article already but good you posted it here.
Based on my understanding an tests i have the following suggestions:
Sched_compat_yield set to 0 seems to improve performance. Note this is not a java virtual machine. This is only based on my tests
Sched_latency_ns : I recently am testing very low values. Currently using 390000 and 130000 for the two granularity parameters.
It seems smoother without losing raw throughoutput performance.
Regarding the migration parameters.... we are running a single core device. hence I think it simply doesn't matter what values we have set there as no task will ever switch the CPU it is bound to.
But a test if set to 0 can reduce some overhead could be a worth try.
Sent from my HTC Desire HD using XDA App
a user said:
I know this article already but good you posted it here.
Based on my understanding an tests i have the following suggestions:
Sched_compat_yield set to 0 seems to improve performance. Note this is not a java virtual machine. This is only based on my tests
Sched_latency_ns : I recently am testing very low values. Currently using 390000 and 130000 for the two granularity parameters.
It seems smoother without losing raw throughoutput performance.
Regarding the migration parameters.... we are running a single core device. hence I think it simply doesn't matter what values we have set there as no task will ever switch the CPU it is bound to.
But a test if set to 0 can reduce some overhead could be a worth try.
Sent from my HTC Desire HD using XDA App
Click to expand...
Click to collapse
Ok and thanks for your answer even if I don't totally agree with your proposal.
Indeed, I think that going down to so small value could be a little bit risky in term of CPU load and throughput for processor bounded task (I know that they are quite unimportant in a phone). Nevertheless, I am now testing Sched_latency_ns 1000000 and 250000 for the two granularity parameters...
Now some words about BFS ( Brain **** Scheduler) introduced recently by M. Kolivas (see article here: http://ck.kolivas.org/patches/bfs/sched-BFS.txt).
"It was designed to be forward looking only, make the most of lower spec machines, and not scale to massive hardware. ie it is a desktop orientated scheduler, with extremely low latencies for excellent interactivity by design rather than "calculated", with rigid fairness, nice priority distribution and extreme scalability within normal load levels."
Here the only tunable parameter is rr_interval that is roughly equivalent to the latency [in ms]. The default value = 6 [ms] that seems ok for me (possible values 1 -> 1000).
[to be continued...]
m_plus kernel for Nexus 4 (mako)!
Hi all, since _motley has been MIA of late and his work was my favorite kernel for the Nexus 4, I have decided to continue his work in his absense. As a result much of this thread will look very similar to _motley's original thread here: http://forum.xda-developers.com/showthread.php?t=2021437. I would like to personally thank _motley for his work and dedication to this project, I only hope I can keep his loyal users happy in his absence.
Disclaimer: As usual, I am not responsible for anything that may or may not happen to your device as a result of using this kernel or any other flashable zips posted by me in this thread.
Features
Highly customizable with scripts. See post #2 for all the tuning options.
Google 3.4 base. All stock features are of course supported (camera, NFC etc.)
Compiler optimizations (-O2 + others) - using 2012.12 Linaro toolchain
Full ramdisk install with init.d support for stock/AOSP (CM already has support, for stock you must install busybox!)
CPU Overclock steps 1.56, 1.62, and 1.67GHz (default freq is still stock on boot, OC is optional)
304MHz lowest CPU freq step added with lower voltage than stock, since the device spends a lot of time at this frequency.
Safe UV by default for nominal, fast, and faster binned chips.
Voltage control - be careful to not save the setting on boot until you are 100% sure it is stable! (thanks faux123! + my tweaks)
In-kernel auto_hotplug (thanks to thalamus). I have added and exposed all the tuning parameters and a debug mode to userspace.
Customized in-kernel thermal solution smart scaling, dynamic polling, and configurable throttle temp.
Custom PowerHAL module (spam-free Android log from PowerHAL events)
Controllable touchboost frequency and duration
Gamma and Sound control (thanks faux123!)
Fsync control (3 modes)
USB Force Fast Charge
I/O schedulers - SIO(optimized), deadline (optimized), row, cfq, noop, and fiops
TCP Congestion Control (several choices available) - veno is the default
Governors - Interactive (default), OnDemand, PowerSave, Conservative
CIFS, NFS, NTFS r/w, TUN - built-in, no need for any kernel modules
Other misc patches and tweaks (see github link at the bottom of this post)
GPL compliant - source is kept up to date at github.com and released at the time the kernel is released to the public via this post. Demand that other devs do the same!
Requirements (please read carefully and visit the other dev threads as necessary)
Boot-loader must be unlocked and you must have a custom recovery installed (CWM or TWRP).
Have your ROM zip on your /sdcard so you can restore your whole ROM if necessary.
Do a complete backup using custom recovery so you can restore your boot.img and ROM if necessary!
System Tuner is recommended for monitoring/tuning the CPU, especially for voltage control. Other kernel apps like faux123's will likely work as well, but they have not been tested.
AOSP ROMs including stock - for init.d support, you must have a working busybox install in /system/xbin.
Installation
Check the requirements above and read release notes below for the build # you are installing for any extra instructions!
If coming from another kernel, read the instructions in red below and follow them before flashing.
Flash the the kernel zip using your custom recovery.
Optional: if you want to revert back to what you had, restore your backup of your boot.img in recovery. Another option for reset back to stock is to flash the stock reset zip above. For other custom ROMs, dirty flash your custom ROM in recovery to get your default kernel and ramdisk back.
If you have issues and are coming from another custom kernel or ROM, follow these instructions first before the install. Many custom kernels are changing the ramdisk or other binaries that require a reset before moving back to stock or another kernel.
Reset for Stock ROM - flash this reset package that includes the stock kernel, ramdisk, thermald, mpdecision, and PowerHAL binary. This can also be used if you are using the stock ROM and want to go back to stock.
Download - N4_422_stock_kernel_and_components.zip
MD5 - f801fc7702e29d85447e9b6fdc880549
Reset for any non-stock ROMs like CM, AOKP etc - dirty flash your current ROM or nightly zip then your gapps in recovery (just flash, no wiping). This will give you back your original ramdisk, kernel, and other binaries that other kernel devs may have tweaked, renamed, replaced etc.
Builds
Personal Request: If you plan to make unofficial builds with features not included in the builds posted by me, please don't link them in the thread, all this does is result in confusion especially if someone has a problem with something you have added, it is much easier for me to provide support if I know that everyone in the thread is running the same builds I am. If you want to make a kernel with these features, feel free to start another thread so that they can be discussed and supported as appropriate.
Current Buildbot Status:
Source: https://github.com/thracemerin/kernel-Nexus4
As with _motley's builds, the stable version will be a base build which includes the ramdisk and other component binaries to make the kernel work as expected, you will need to flash the stable version prior to flashing any experimental versions or something may not work as expected.
All files are now available from goo.im: http://goo.im/devs/thracemerin/mako/m_plus
Note: Due to goo.im file naming rules I had to change the name of the zip to m_plus from m+, this has no effect on the content, the ones on goo.im are identical to those that were on dev-host other than the names.
Change Logs
Note: The builds below are for 4.2.2 only, for the latest 4.3 alpha builds check the last few pages of the thread. *4.3 builds will appear on goo.im when they are closer to being official production builds.
This thread is for 4.2.X versions only, use the following threads for 4.3:
JW Builds: Thread not available yet, Alpha 3 is still here: http://forum.xda-developers.com/showpost.php?p=43993185&postcount=860
JS Builds: http://forum.xda-developers.com/showthread.php?t=2385840
Build 10 (Exp) - July 15, 2013
Note: You must be on Build 1 or later. (Build 8 if you are on MIUI)
Various patches to the kernel to prevent out of bounds access to memory (see github for details)
Added sweep2wake, it is disabled by default, see post 2 for info (thanks to show-p1984)
Added a patch to fix some unusual behavior with the LEDs (thanks to CM)
Build 9 (Exp) - July 3, 2013
Note: You must be on Build 1 or later. (Build 8 if you are on MIUI)
Added the simple GPU governor for Qualcomm Adreno GPUs thanks to Faux123 (set as default, no need for the script required in the Alpha). Tunables explained in Post 2.
Build 8.1 (Exp) - June 20, 2013
Note: You must be on Build 1 or later. (Build 8 if you are on MIUI)
Actually reverted some of the msm_hsic patches because they seem to cause data drops (I only pretended I did in Build 8, oops )
Build 8 (Exp) - June 18, 2013
Note: You must be on Build 1 or later.
Reverted some of the msm_hsic patches because they seem to cause data drops
Now build with the Linaro 4.8.2.2013.06 toolchain
Switched the allocator from SLUB to SLAB because SLUB wouldn't boot when compiled with 4.8
Various fixes to allow building with 4.8
Build 7 (Exp) - May 26, 2013
Note: You must be on Build 1 or later.
goo.im seems to be a little flaky this afternoon, alternative downloads here: http://forum.xda-developers.com/showpost.php?p=41865828&postcount=416
Patches to freezer from Colin Cross
More patches to workqueue from CAF
Patches to the cpufreq driver from CAF
Reverted lowest frequency step to 384MHz (See Post 3 for why)
Fixed board-mako-regulator.c to allow for UV to work (Warning: Reset your UV settings if you have UV below 850mV, if you flashed the previous alphas this is probably not necessary.)
Reset undervolting to stock from Google, just in case the above causes problems for new adopters (You still have full access to undervolt to 600mV if your chip can handle it)
Added the change pointed out by veyka here: http://forum.xda-developers.com/showpost.php?p=41730297&postcount=380
Some more patches to the hsic controller that were in my other project but not this one.
Build 6 (Exp) - May 19, 2013
Note: You must be on Build 1 or later.
CAF changes to cpufreq
CAF changes to workqueues
Build 5 (Exp) - May 12, 2013
Note: You must be on Build 1 or later.
CAF patches to block.
CAF patches to the charging and battery management system.
CAF patches to the video driver.
Build 4 (Exp) - May 5, 2013
Note: You must be on Build 1 or later.
A few more sched patches from CAF
Patches to android lowmemory killer from CAF
Headphone poweramp controls (thanks to Faux123)
Build 3 (Exp) - May 3, 2013
Note: You must be on Build 1 or later.
Various sched patches that were in _motley's 4.2.1 kernel and not his 4.2.2 kernel
FIOPS i/o scheduler is back
192mhz frequency step added (thanks to showp1984)
Note: The ramdisk currently forces the minimum to 304mhz so i added an init.d script to force it to 192mhz so I didn't have to redo the ramdisk.
I'll fix this in the next base build.
If you still want to use 304mhz as your lowest step, see post 3 for details on how to do this.
Note 2: The voltage is the same as the one _motley used for 304mhz for stability reasons, it will still use less power, but feel free to uV it if you like.
Build 2 (Exp) - April 30, 2013
Note: You must be on Build 1 or later.
Update ROW i/o scheduler to the latest from CAF, now default i/o scheduler
FIOPS i/o scheduler was removed because _motley added FIOPS and ROW as 1 commit and messing with ROW screwed it up.
Hardcode ROW magic values (thanks to franciscofranco & osm0sis)
Update interactive governor to the latest from CAF (it may be a little less aggressive)
Krait Retention (thanks to CAF, faux123)
Build 1 (Base) - April 29, 2013
Everything from _motley's b49 build up to this point.
Built with the linaro 2013.04 gcc-4.7 toolchain
Thanks
Google - For AOSP sources
LG - for building the N4
Qualcomm/CAF - for their updates to the N4 kernel
_motley - for all his work on this kernel
faux123 - patches included that were initially written by him
franciscofranco - patches included that were initially written by him
showp-1984 - patches included that were initially written by him
anyone else i've neglected to include, if you feel you deserve to be thanked by name by all means PM me
Tunables should be the same as _motley's kernel so I'm quoting him here:
(All the tunables that are discussed in _motley's thread http://forum.xda-developers.com/showthread.php?t=2021437 should work the same way on this kernel)
_motley said:
Setting custom RGB color settings via sysfs
This can be done from the adb shell on your PC, or any terminal app. If you change them, they will not persist after a reboot. However, you can set them in an init.d script if you found another color combination that you like better than the one I have used.
Code:
echo "255 255 255" > /sys/devices/platform/kcal_ctrl.0/kcal
echo 1 > /sys/devices/platform/kcal_ctrl.0/kcal_ctrl
Command 1 sets the color and Command 2 commits them. Stock is 255 255 255.
Setting custom Gamma settings via sysfs - Exp kernel build 31+ only - thanks to faux for sharing his code
Warning: changing these values can be potentially be dangerous to your display if you make a mistake. For those that feel comfortable with what they are doing and want to experiment, please report back and share your findings.
Important, please read!
There are ten digits in the string separated by one space
First digit is a checksum and is never stored. The checksum is simply the sum of the other 9 numbers. This is to make it harder to so the interface is respected and you are forced to think about what you are doing.
There are 3 sysfs interfaces for gamma, one for each color:
Code:
#!/system/bin/sh
# Show the current configuration and the checksum
cat /sys/devices/platform/mipi_lgit.1537/kgamma_red
cat /sys/devices/platform/mipi_lgit.1537/kgamma_green
cat /sys/devices/platform/mipi_lgit.1537/kgamma_blue
Update:
Recently molesarecoming started opening this up and showing us what the values can be used to adjust. Franco then suggested that the white and grays should be swapped in moles original work. So, for init.d values using this interface, we have the following "banks" if values if we agree with Franco on the swap of the whites and grays.
Code:
R: checksum, g_white, g_mids, g_black, 0, g_contrast, g_brightness, g_saturation, g_grey, 2
G: checksum, g_white, g_mids, g_black, 0, g_contrast, g_brightness, g_saturation, g_grey, 2
B: checksum, g_white, g_mids, g_black, 0, g_contrast, g_brightness, g_saturation, g_grey, 2
(the zero in position 5's and the 2's in position 10 are recommended to be left alone since they are currently unknowns)
Minus the checksum, the 27 values mirror the 3 color arrays (3 x 9 = 27) in the actual LG LCD driver. Minus the unknowns, we are left with 21 values. Note that every one of the variables can have their value tweaked by color (saturation for red, saturation for green etc.), however, it is recommended that you start with all the values of one type being the same and then tweak from there if you really want to fine tune.
You have a lot of power in your hands even without fine tuning. Many will argue that fine tuning isn't required. If you look at the stock settings by Google in post 2, they took advantage of fine tuning for whatever reason. Even though many don't like these settings by Google, it shows how flexible the interface can be.
Instructions:
1) Start with a preset config (LG or Google) as shown further below. This is a set of 3 lines, 10 numbers for each line.
2) Tweak columns for their values as above. For example, we tweak contrast and brightness as in faux's original app. We could also do the same for saturation, blacks, whites, grays etc.
Example: start with LG presets with numbers to adjust:
383 114 21 118 0 10 4 80 48 2
383 114 21 118 0 7 4 80 48 2
383 114 21 118 0 5 1 80 48 2
3) Now update the checksum in column 1 (first digit = sum of last 9 digits)
397 114 21 118 0 10 4 80 48 2
394 114 21 118 0 7 4 80 48 2
389 114 21 118 0 5 1 80 48 2
4) Create a script inside a text file - my recommendation for your first test
Code:
#!/system/bin/sh
# Set data color pro presets from shared Google spreadsheet (thanks user acer73!)
# Use LG presents as your starting values and then adjust columns 6 & 7 from the spreadsheet
echo "397 114 21 118 0 10 4 80 48 2" > /sys/devices/platform/mipi_lgit.1537/kgamma_red
echo "394 114 21 118 0 7 4 80 48 2" > /sys/devices/platform/mipi_lgit.1537/kgamma_green
echo "389 114 21 118 0 5 1 80 48 2" > /sys/devices/platform/mipi_lgit.1537/kgamma_blue
#Set the complimentary RGB values for this calibration
echo "248 248 248" > /sys/devices/platform/kcal_ctrl.0/kcal
echo 1 > /sys/devices/platform/kcal_ctrl.0/kcal_ctrl
5) Run the script (or you can echo each line manually to test from adb if you prefer).
6) Turn the screen off and on for the gamma change to take effect.
7) Check the dmesg output for any clues and to see the output of the result.
8) Place the script into your /system/etc/init.d/ folder (or equivalent) for a permanent color change!
Screen refresh (added in b37) - this should only be called by apps or scripts while adjusting and testing colors "live" with the motley or faux sysfs interface. It should NOT be implemented on startup via init.d or by apps since it will compete with the normal power on process.
Code:
echo 1 > /sys/devices/platform/mipi_lgit.1537/refresh_screen
Presets:
Code:
#!/system/bin/sh
# Set LG presets (motley stock) - i.e. popular partial revert of Google's tweaks just before release
echo "383 114 21 118 0 0 0 80 48 2" > /sys/devices/platform/mipi_lgit.1537/kgamma_red
echo "383 114 21 118 0 0 0 80 48 2" > /sys/devices/platform/mipi_lgit.1537/kgamma_green
echo "383 114 21 118 0 0 0 80 48 2" > /sys/devices/platform/mipi_lgit.1537/kgamma_blue
Code:
#!/system/bin/sh
# Set stock Google presets (from kernel source code)
echo "332 64 68 118 1 0 0 48 32 1" > /sys/devices/platform/mipi_lgit.1537/kgamma_red
echo "332 64 68 118 1 0 0 48 32 1" > /sys/devices/platform/mipi_lgit.1537/kgamma_green
echo "364 32 35 116 0 31 16 80 51 3" > /sys/devices/platform/mipi_lgit.1537/kgamma_blue
Spreadsheet with shared settings
https://docs.google.com/spreadsheet/ccc?key=0AoDp2qRui0u0dGE4T2gtSDBTRHVFSldPS2RrX1Rya0E#gid=0
FSYNC Control
Notes: I thought about combining these options, but many kernel apps already support these two options. So, I have them both and they can be controlled in combination to give us the 3 modes. If you set fsync_enabled = 0 it will be OFF regardless of how Dyn_fsync_active is set.
3 Modes:
Dynamic (default in b35 and higher)- fsync is asynchronous when screen is on, when screen is off it is committed synchronously
dynamic fsync ON
fsync ON
Code:
echo 1 > /sys/kernel/dyn_fsync/Dyn_fsync_active
echo 1 > /sys/class/misc/fsynccontrol/fsync_enabled
Off (best performance, less safe) - fsync is always asynchronous (b32 and prior builds)
dynamic fsync OFF
fsync OFF
Code:
echo 0 > /sys/kernel/dyn_fsync/Dyn_fsync_active
echo 0 > /sys/class/misc/fsynccontrol/fsync_enabled
Stock (safest) - fsync is always committed synchronously
dynamic fsync OFF
fsync ON
Code:
echo 0 > /sys/kernel/dyn_fsync/Dyn_fsync_active
echo 1 > /sys/class/misc/fsynccontrol/fsync_enabled
There is a lot of info out there on fsync, that will not be discussed here. I have run fsync off on several devices for awhile now and haven't experienced any issues. If you are using a device that is not stable and crashes alot, I recommend enabling it via init.d or script manager on boot. Hopefully your N4 is as stable as is mine.
USB Force Fast Charge
You can turn it on with popular apps (like Trickster MOD) that support the common sysfs toggle as shown below.
If you don't like it or don't want to use it, it is off by default.
Turn ON:
Code:
echo 1 > /sys/kernel/fast_charge/force_fast_charge
Turn OFF:
Code:
echo 0 > /sys/kernel/fast_charge/force_fast_charge
Notes:
When it is ON, you will not be able to connect your phone to your PC (adb, mtp etc.). This is expected behavior.
To start charging: turn fast charge ON, plug the USB cable into your PC, and charge up.
To stop charging: unplug the USB cable and turn fast charge OFF. Now you can plug back into your PC for normal trickle charging, adb/mtp etc.
Tip: if you see it connect to your PC (media device or adb), it isn't working. Unplug the cable, wait a couple seconds and plug it in again.
Boostpulse control - Experimental build only
Trickster MOD works great to play with these.
How long does it boost when Android senses touch? (in b10 and b14 it is above_hispeed_delay)
Code:
/sys/devices/system/cpu/cpufreq/interactive/boostpulse_duration
What freq does it boost to?
Code:
/sys/devices/system/cpu/cpufreq/interactive/hispeed_freq
Turn touchboost OFF/ON (in b10 and b14 only)
Code:
/sys/devices/system/cpu/cpufreq/interactive/input_boost
Thermal Throttling and Hotplug Control - Experimental build only
Warning: these do not have to be changed from the defaults and could potentially be dangerous if you make a mistake. For those that know what they are doing and want to experiment with settings, scripts etc. please report back your findings.
msm_thermal:
Throttle temp in C. Default is 70, valid range is 45 to 80 (recommend to not go over 75):
Code:
/sys/module/msm_thermal/parameters/throttle_temp
Minimum freq used in throttle down before returning to max, default is 7 = 1.13GHz. Range is 4 to 8 (810Mhz to 1.24GHz)
This is the index in the frequency table as seen in Trickster MOD, System Tuner etc. It is zero based (i.e. 304MHz is zero).
Code:
/sys/module/msm_thermal/parameters/min_freq_index
Turn on thermal debugging so you can see what is happening in the kernel log:
Code:
/sys/module/msm_thermal/parameters/thermal_debug
auto_hotplug:
Load based hotplugging parameters. I have taken _thalamus' base (thanks!) and have exposed most of the tuning parameters to userspace.
Turn off/on hot_plug debugging Y/N, default N, this spams the kernel log like crazy, turn on only when troubleshooting/testing
Code:
/sys/module/auto_hotplug/parameters/debug
Load at which a CPU is taken offline, 40-125, default 80:
Code:
/sys/module/auto_hotplug/parameters/disable_load_threshold
Load at which an extra CPU is put online, 130-250, default 200:
Code:
/sys/module/auto_hotplug/parameters/enable_load_threshold
Load at which all CPU's are enabled, 270-550, default is 400 (or 100 x number of cores):
Code:
/sys/module/auto_hotplug/parameters/enable_all_load_threshold
Sample rate in milliseconds, converted to jiffies at runtime, 10-50ms, default 20:
Code:
/sys/module/auto_hotplug/parameters/min_sampling_rate
Number of samples in the circular buffer, 5-50, default 10 (more samples = less aggressive; less samples = more aggressive):
Code:
/sys/module/auto_hotplug/parameters/sampling_periods
Maximum number of cores online (regardless of load) when screen is on, 1-4, default 4 (tune down for battery savings):
Code:
/sys/module/auto_hotplug/parameters/max_online_cpus
Minimum number of cores online (regardless of load) when screen is on, 1-4, default 1 (tune up for performance/bench-marking):
Code:
/sys/module/auto_hotplug/parameters/min_online_cpus
Vibration Intensity
You can also use Trickster MOD to set this.
Example increase intensity:
Code:
echo "90" > /sys/class/timed_output/vibrator/amp
To go back to stock:
Code:
echo "70" > /sys/class/timed_output/vibrator/amp
Why are the base voltage tables different on some phones
What CPU do you have? Nominal, Fast, Faster ...or Slow
The phones with the lower default voltage values use the "fast" or "faster" frequency table, consider yourself lucky. This explains why some can't UV as much as others since they are starting with lower mV's to start. These are built in factory tolerances that depend upon the binning of your chip. I am familiar with the same thing in the tegra3 world where I have had more experience. So, don't worry as this is commonly done in this industry. Hopefully folks don't go freaking out because they have a nominal chip like I do. It's probably good for a dev to have a nominal chip so we can better honor the limits.
http://en.wikipedia.org/wiki/Product_binning
How do I tell what I have?
If you boot up your phone fresh and look at the dmesg output (kernel log) while the messages are still there, you will find one of the following output messages where it selects it's frequency plan depending on the binning of the chip.
Code:
adb shell dmesg | grep PVS
acpuclk-8064 acpuclk-8064: ACPU PVS: Nominal
-or-
acpuclk-8064 acpuclk-8064: ACPU PVS: Fast
-or-
acpuclk-8064 acpuclk-8064: ACPU PVS: Faster
-or-
acpuclk-8064 acpuclk-8064: ACPU PVS: Slow
I have tweaked all the frequency tables nominal, fast, and faster (as well as slow to compensate for the lower freq) to keep them similarly scaled relative to stock. If you don't like the safe defaults (already UV'ed), then use voltage control and come up with your own preferred values.
Click to expand...
Click to collapse
C State Information
(thanks to faux123 - more info here: https://plus.google.com/109078966818501160423/posts/9R8fjQdHDXD)
faux123 recommends C0, C1 and C3 here: http://forum.xda-developers.com/showpost.php?p=40151528&postcount=9775
C0 (WFI) - Shallowest Sleep (default enabled)
Code:
enable: echo 1 > /sys/module/pm_8x60/modes/cpu0/wfi/idle_enabled
disable: echo 0 > /sys/module/pm_8x60/modes/cpu0/wfi/idle_enabled
C1 (Retention) - slightly deeper sleep
Code:
enable: echo 1 > /sys/module/pm_8x60/modes/cpu0/retention/idle_enabled
disable: echo 0 > /sys/module/pm_8x60/modes/cpu0/retention/idle_enabled
C2 (Stand Alone Power Collapse) - deeper sleep
Code:
enable: echo 1 > /sys/module/pm_8x60/modes/cpu0/standalone_power_collapse/idle_enabled
disable: echo 0 > /sys/module/pm_8x60/modes/cpu0/standalone_power_collapse/idle_enabled
C3 (Power Collapse) - deepest sleep
Code:
enable: echo 1 > /sys/module/pm_8x60/modes/cpu0/power_collapse/idle_enabled
disable: echo 0 > /sys/module/pm_8x60/modes/cpu0/power_collapse/idle_enabled
Simple GPU Governor Tunables
Code:
/sys/module/msm_kgsl_core/parameters/simple_laziness
Laziness: Adjusts the number of times the governor skips ramp down requests. (Higher = better performance, higher battery drain)
Code:
/sys/module/msm_kgsl_core/parameters/simple_ramp_threshold
Threshold: Adjusts the threshold to ramp up or down the GPU frequencies. (Lower = better performance, higher battery drain)
To enable sweep2wake:
Code:
echo 1 > /sys/android_touch/sweep2wake
Frequently Asked Questions
Q: You gave us 192Mhz, now you removed it and set 304Mhz back to 384Mhz, why?
A: Good question, there had always been some speculation in this thread and others that frequencies below 384Mhz were not in fact being set correctly, show-p1984 managed to run his device at 27Mhz with no stability issues (this should be impossible) so we did some quick and rather unscientific benchmarking in this thread and found that there didn't seem to be any difference in CPU performance between 192Mhz and 304Mhz (and there should have been), I then speculated that 304Mhz was also not being set, after a little more unscientific benchmarking I determined that there was no difference in performance from 304Mhz to 384Mhz either, so based on this I don't see any reason to allow these frequencies.
Q: I don't want to use the 192mhz frequency, how can I disable it? (Build 3-6)
A: One of the four options below will fix it:
You can delete my script, it's located at /system/etc/init.d/01cpu and reboot, this will set you back to 304mhz minimum.
You can remove it from the zip file (same location in the zip hierarchy) before you flash.
You can use your favorite kernel tuner (trickster, fauxclock, etc...) to switch the minimum frequency back to 304mhz and set it on boot.
You can change the /system/etc/init.d/01cpu script to set whatever minimum frequency you want (it has to be a valid one from the table)
Q: If the 192mhz and 304mhz steps use the same undervolt settings, how can 192mhz use less power?
A: The formula for power consumption is: P = f * c * V ^ 2
Where: P = power consumption, f = frequency, c = capacitance and V = voltage
So: since c is constant in this case, and we'll assume you've used the lowest UV possible (600mV)
At 304mhz: P = 304 * c * 600 ^ 2
At 192mhz: P = 192 * c * 600 ^ 2
This means that 304mhz uses approximately 1.58 times more power than 192mhz over the same time.
Q: There are a bunch of fixes for the delayed notification issues in various threads, what should the settings be for this kernel?
A: The following values should be set in your /system/etc/wifi/WNCSS_qcom_cfg.ini (depending on your ROM you may have different values), these are the Google stock values and appropriate for this kernel.
Code:
McastBcastFilter=3
HostArpOffload=0
gEnableSuspend=3
You can set these values by flashing this: wlan_revert.zip - MD5 - 381013687035626bcb1cbaf609ea4311
Q: Does this kernel include the ARP offload patch?
A: No, and for those of you following my other thread here: http://forum.xda-developers.com/showthread.php?t=2102986 you will know that there is an issue where our WiFi chip responds to ARP requests with a bad MAC address during deep sleep, this results in problems with direct connect (WiFi direct, AirDroid, etc...) and can cause issues with certain types of routers and networks that do not cache ARP addresses for long, as a result I no longer use it in my other kernel either. I am using a different solution which solves the problem for me and many others but has a slight battery life hit, I will post a flashable zip to modify the binaries to include this fix at a later time, but for now if you wish to include this fix do the following.
Code:
open /system/etc/wifi/WNCSS_qcom_cfg.ini in your favorite file editor
find the line that currently reads gEnableSuspend=3
change the line to read gEnableSuspend=2
save the file
reboot your device.
Q: I flashed this kernel and my battery life sucks! WTF?
A: Clearly I didn't design this kernel to drain your battery (nor did _motley) and in my experience most battery drain issues are app related and not kernel related. In order to help me help you solve the problem, please download Better Battery Stats either from the Play Store (costs money, but I strongly encourage supporting the dev) or the free version from XDA and provide me with a dump file for a few hours of use so I can see what is going on with your device, if you don't do this I will assume the battery drain is your fault and will ignore your complaint.
Q: Can you add feature x from kernel y?
A: Maybe, I'm not going to take this kernel and stuff it full of every single idea anyone has while lying in bed trying to fall asleep, but if the feature seems like something that most would use and it's in a reasonable state of working (ie. not something that someone else just started working on) then I will consider adding it, absolutely no promises in this regard.
Q: I got a random reboot, SOD, other bug that must be kernel related, what do I do?
A: Provide me with appropriate logs (dmesg, logcat, last_kmsg (see my sig)) and instructions on how you caused this if possible, if I can't reproduce the issue and I can't see it in the logs there is nothing I can do. Be as detailed about what you were doing at the time it happened, more information is always better than less.
Q: If _motley comes back what will happen with this project?
A: Well, I don't want to step on any toes here, this was originally _motley's work, what happens to it long term if he returns will ultimately be up to him. If he wants to continue from where he left off and merge his own changes beyond b49, I may keep going as a separate project, if he wants to fork me and continue from the point I'm at when he returns that's ok with me too and I'd probably stop if that were the case, but we're speaking in hypotheticals here, anything is possible.
Q: Touch control doesn't work! Why not?
A: Touch control requires a module that is compiled by the author and provided as a pre-compiled binary. I'm not specifically looking to break it's functionality, but changes I make may cause it to stop working at any time between releases, the only way to get this fixed is to speak to the author of the addon and have him recompile the module. If he needs my assistance with anything specific to this kernel, I will do my best to help him out.
Pre-release (Alpha) Builds
These builds are the latest builds produced by the buildbot from the wip branch.
WARNING: These builds should be considered alpha, may contain a lot of bugs, may be unstable, and may be partially or completely non-functional. That being said, I am usually running these builds so if they are really badly broken I'll remove them ASAP.
http://goo.im/devs/thracemerin/mako/m_plus/wip
Current Buildbot Status:
Current Alpha: None, use Build 10!
What's changed:
Thanks for continuing Motleys kernel, waiting for links to download and flash.
Build 1 is up, happy flashing :victory:
Thank you very much for the kernel, I'm glad to see the motley's great work doesn't get forgotten.
PS: a benchmark for the ones that like it, stock settings and sabermod rom.
{
"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"
}
I hope _motley is alright. Thank you for continuing to develop this great kernel in his absence.
Will you be including the new Prima drivers and retention patches introduced by kszaq to fix some of the wifi problems? I know it's not a solution for everyone, but I personally thought it worked well with no battery hit and some others seem to agree.
Anyway, thank you for your work and good luck with _m+ .
mko000 said:
I hope _motley is alright. Thank you for continuing to develop this great kernel in his absence.
Will you be including the new Prima drivers and retention patches introduced by kszaq to fix some of the wifi problems? I know it's not a solution for everyone, but I personally thought it worked well with no battery hit and some others seem to agree.
Anyway, thank you for your work and good luck with _m+ .
Click to expand...
Click to collapse
Krait retention, yes.
Prima/ARP Offload, not right now, there is a workaround and better explanation for why in post 3, I'll continue to work on it in my other thread, if I get to a fully working solution, then absolutely. The current issue with the Prima driver makes my phone unusable for something I do on a daily basis which is why I will not do it currently (I want to be able to use this kernel as my daily driver).
Flashed the CM build, all fine thanks! Felt the smoothness of Motleys kernel again.
Very nice! Um, I took a look at your git, but i couldn't work out what you added over b49 heh, mind giving a quick summery?
Sent via Nexus 4
veyka said:
Very nice! Um, I took a look at your git, but i couldn't work out what you added over b49 heh, mind giving a quick summery?
Sent via Nexus 4
Click to expand...
Click to collapse
Nothing atm, this release was just a stable start to move forward on and proof that I had the infrastructure set up to actually build with linaro gcc-4.7. I'll have another release in a day or two with some new stuff
Plus, it avoids having to get people to get b37 & b49 from _motley's thread before moving forward with builds here.
thracemerin said:
Nothing atm, this release was just a stable start to move forward on and proof that I had the infrastructure set up to actually build with linaro gcc-4.7. I'll have another release in a day or two with some new stuff
Plus, it avoids having to get people to get b37 & b49 from _motley's thread before moving forward with builds here.
Click to expand...
Click to collapse
Cheers! So i wasn't being a brainless derp then
Sent via Nexus 4
thracemerin said:
Krait retention, yes.
Prima/ARP Offload, not right now, there is a workaround and better explanation for why in post 3, I'll continue to work on it in my other thread, if I get to a fully working solution, then absolutely. The current issue with the Prima driver makes my phone unusable for something I do on a daily basis which is why I will not do it currently (I want to be able to use this kernel as my daily driver).
Click to expand...
Click to collapse
Hey fellow super android lol nice work with this kernel. I'm gonna give this a whirl and see how it performs. Thanks for continuing motley's kernel.
thracemerin said:
Nothing atm, this release was just a stable start to move forward on and proof that I had the infrastructure set up to actually build with linaro gcc-4.7. I'll have another release in a day or two with some new stuff
Plus, it avoids having to get people to get b37 & b49 from _motley's thread before moving forward with builds here.
Click to expand...
Click to collapse
I guess I'll wait a few more days then
Sent from my Nexus 4 using xda app-developers app
iamhacked said:
I guess I'll wait a few more days then
Sent from my Nexus 4 using xda app-developers app
Click to expand...
Click to collapse
I can push build 2, I just haven't tested it hardly at all and if it blows someone's device up I'd feel bad.
thracemerin said:
I can push build 2, I just haven't tested it hardly at all and if it blows someone's device up I'd feel bad.
Click to expand...
Click to collapse
take your time. dont rush. i know people are chomping at the bit for something new but ignore them.
or post a test build and let us blow up our phones haha :good:
Hi, if I may make a request, do you think it's possible to lower the minimum allowed voltage?
Sent from my Nexus 4 using xda app-developers app
Logi_Ca1 said:
Hi, if I may make a request, do you think it's possible to lower the minimum allowed voltage?
Sent from my Nexus 4 using xda app-developers app
Click to expand...
Click to collapse
It's 600mV right now, correct?
Yup, it's 600mv now. I was thinking that since the phone spends most of its time at 384mhz, and for me that frequency is totally stable at 600mv, it's probably possible that the voltage at 384mhz can go even lower. However I noticed that most of the other kernels have higher minimum allowed voltages, so there may be a reason for that that I'm not seeing here.
Sent from my Nexus 4 using xda app-developers app
I use the 900F version. For most of us, the phone is more asleep than it' s in operation. That's why choosing the correct ROM & Kernel is essential for your battery.
I wanted to figure out which ROM is best regarding battery life when the screen is off and how to reach the best result.
Calculation:
BetterBatteryStats Calculation.
If I look at my stats: View attachment BetterBatteryStats-2016-10-18_184154319.txt I can see the voltage went down from 4327 to 4143 (-184) in 1168 minutes. That's 60 x 184 / 1168 = 9.45%/hour, which is correctly showing in BBS. Now I translate this to percentages: 9.45% voltage decrease x 4% battery decrease / 184 = 0.205%/hour battery. This is again correct according to BBS. I guess this is a fair calculation. the voltages seem to go up and down all the time, so I don't understand how it's an exact calculation but ok.
A thing that doesn't make this calculation 100% right is the number of % decrease. I have a good example of 3 battery stats that I saved in the same period of time: 22hours and 58 min, then one a few hours after that, and then last one that's one hour after the last one.
Stage 1. View attachment 22h58.txt -------96% (60 x 126 / 1379 min = 5,48% voltage/hour x 4 % drain / 126 V drain = 0.17% /hour
Stage 2. View attachment 1d32min.txt ----96% ( 94 minutes later it reached Stage 2 = 0.16%/ hour. With the SAME % = 96% ! (Makes sense)
Stage 3. View attachment 1d2h.txt --------95% ( 130 min after Stage 2 I saved another log = 0.187% / hour. You see, it just turned 95% and it goes way up again.
Conclusion: Try to save the BBS as far as you can get to the end of the % to get the lowest %/hour calculation. You'd think: Try Battery History and calculate the exact time and use these minutes in your calculation. But then I realized that the voltage has to change as well, and as I do not know the voltage, the calculation would be messed up. So best is to do as shown above, try to save the BBS manually as far as you can get to the end of the %.
Settings:
Screen off all the time. Just try to peak once or twice a day for one second.
Disabled: NFC, wifi, BT, Location, screen settings: standard screen, double tap to sleep, no rotation, no color adaptation, balanced battery mode, no ambiant color but standard, no notification lights, no gestures.
Disable auto update Google Play Store, even on Wifi, disable all Sync on Googleaccount, disable Location Services
For Touchwiz I used the Barebone Cleaner.
General apps installed Section 3: Whatsapp (not logged in), Battery History, CNN, NOS, NU.nl, Line (not logged in), MyMail (not logged in)
Battery savers:
- Section 1: Amplify, Powernap, AppOpsXposed, BBS---------------------------------Terminated as of 16/10/2016
- Section 2: Greenify------------------------------------------------------------------------Terminated as of 15/10/2016
- Section 3: Amplify, Powernap, AppOpsXposed, BBS, Greenify --------------------In Progress since 17/10/2016
- Section 4: Amplify, Powernap, AppOpsXposed, BBS, Greenify, Forcedoze ------In Progress since 17/10/2016
Conclusion: (as of 01/11/2016)
CM13 is much more stable regarding battery life than Phoenix. At this moment I can suggest CM13 with the following settings:
Ondemandplus, internal + external IO = noop, undervolt -25, aggressive multicore saving, disabled greenify, enable other battery savers as shown above.
Section 4::
Phoenix ROM-------------------------------------0.8%/hr Enabled Greenify, forcedoze, uninstalled Kernel adiutor so default kernel settings.
CM13 + boefla 3.3 beta5-------------------------0.24%/hr. Enabled Greenify, Enabled forcedoze, multicore saving aggressive, 2 cores max, ondemandplus, noop, noop, undervolt light, rest same as below.
CM13 + boefla 3.3 beta5-------------------------0.42%/hr. Enabled Greenify, Enabled forcedoze, multicore saving ON, Interactive, bfq, bfq, no udnervolt, rest same as below.
CM13 + boefla 3.3 beta5-------------------------0.35%/hr. Enabled Greenify, Enabled forcedoze, multicore saving ON, Ondemand, rest same as below.
CM13 + boefla 3.3 beta5-------------------------0.30%/hr. Disabled Greenify, disabled forcedoze, aggressive multicore saving etc, same as below.
CM13 + boefla 3.3 beta5-------------------------0.21%/hour. Disabled Greenify, aggressive multicore saving , same as below.
CM13 + boefla 3.3 beta5-------------------------0.231%. View attachment 0111.txt Ondemandplus, internal + external IO = noop, undervolt -25, aggressive multicore saving, disabled greenify, zzmoove 2 cores max, GPU 320mhz max
CM13 + boefla 3.3 beta5-------------------------0.256%/hr. Governor: Ondemandplus, Internal IO = Noop, Undervolting -25, Installed ForceDoze and activated in Xposed, limited some more Wakelocks, and Activated Greenify again and selected all the options in Experimental.
CM13 + boefla 3.3 beta5-------------------------0.305%hour. View attachment 3920399 Governor: Ondemandplus, Greenify autohibernation disabled and deselected all the Xposed options and limited the cleaner service of greenify in Amplify that caused many alarms.
CM13 + boefla 3.3 beta5-------------------------0.24%/hour. View attachment 20h56.txt Boeffla config app: OnDemand Governor., Internal IO Noop. Can't say I' m excited. Greenify had a lot of wakelocks, I' ll stop the auto hibernate option in Greenify in the next test.
Section 3:: The BetterbatteryStats (BBS) are published from now on.
Phoenix ROM -------------------------------------0.26%/hour. View attachment 2710.txt The same settings as the 0,16%/hour but still a significant difference. I guess it's just different every freaking time. I' m done with Phoenix, next few tests will be on CM13 with boeffla to see a clear pattern on which is best. (with and without governors)
No Kernel auditor installed, no IO scheduler etc, just as it comes with the ROM. the Kernel auditor had some wakelocks so I blame the low score to this app. Changed in dev options: Limit background processes to : No background processes and Do not keep activities.
Phoenix ROM -------------------------------------0.38%/hour View attachment 2610.txt Basic settings as the 0,16%/hour. BBS show a perfect clean run. Seems like one day its lower than the other day.. I guess it's just random luck to get a low %/hour.
Phoenix ROM -------------------------------------0.545%/hour View attachment 26102.txt Governor: Interactive, io Internal: Noop. Rest same. Cant explain it, seems a huge difference to my record. Weird.
Phoenix ROM -------------------------------------0.227%/hour View attachment 2510.txt
Looks like changing the governor isn't helping, so I recommend to stick to Interactive (which was default anyways)
Governor CPU: Ondemand, rest is basic (IO = Cfq, aggressive multicore saving = Disabled - somehow it makes my phone reboot every time in combination with Ondemand and IO Noop, disabled touch boost)
Phoenix ROM -------------------------------------0.33%/hour View attachment 2410.txt
Kernel auditor app installed: Governor: interactive. IO governer: Noop for internal. No touchboost. Multicore Saving: Aggressive. Rest is same as below.
Phoenix ROM -------------------------------------0.16%/hour! View attachment BetterBatteryStats-2016-10-23_153051029.txt Calculation, see method above. When I look at the BBS log when it turned 95%, I see it went up to 0,18%/hour. View attachment BetterBatteryStats-2016-10-23_174102656.txt. I think it's best to let the Battery history app let you save the timestamps when it turned 95% to get the exact moment and calculate the exact % so it could have been lower if I knew the last second before it turned 95%.
CM14, Haggert Kernel ---------------------------0.48%/hour.........Couldnt install Amplify, AppOppsXposed and special features in Greenify cus there's no Xposed for CM14 yet.. Bummer, guess we have to wait. Installed Powernap and SuperDoze and DisabledServices.
CM13 + Boeffla 3.3 beta4 ------------------------0.5% and 0,4%/hour, okay that didn't work... View attachment 3910944 & View attachment 3910945
Boeffla config: GPU governor Powersave, CPu: Light undervolt, external IO to cfq. Governor Ondemandplus, uninstalled Screenoff app, batterymode: power save, battery optimization (settings android) for all battery savers. (were off)
CM13 + Boeffla 3.3 beta2 ------------------------0.205%/hour View attachment BetterBatteryStats-2016-10-18_184154319.txt. Calculation, see above.
Sweet. Could be higher when stopping the test at 95%.
When it reached 96% the average was 0.24%/hr = average 246 min.. (984 / 4%) (23:15 -> 15:39 timestamps 96% = 984 min. 60 x 4 / 984 = 0.24% per hour.
Amplify showed me more wakelocks in the past 19 hours so I limited those as well. Its like a learning process. I' ll tweak more and do a new test below. Exciting stuff! =)
I installed the boeffla config, and put the governor on: Ondemand and scheduler IO both on NOOP. No widgets on homescreen.
CM13 + Boeffla 3.3 beta4------------------------ Again 0.23%/hour. View attachment 3909923 . I saved another log a few hours before this one and it shows less voltage then the last log, how is that possible??? View attachment 3909924
I disabled the Keep awake function in Privacy Guard of Google Services Framework, disabled some other wakelocks that showed up. Clock was giving me many alarms so disabled the deskclock_on_quarter_hour alarm to 2400 secs. Deleted WakelockDetector (not using anyways). Added Greenify to Powernap. Boeffla config: CPU Voltage: Undervolting seems to work (initially it kept rebooting but I put the IO for external to default in boeffla config) The rest: Same settings as test above.
Section 1:
CM13 + Boeffla 3.3 beta2 ------------------------0.6%/hour View attachment 3907816
Phoenix ROM 14.2 ------------------------------- 0.4%/hour View attachment 3907818
Section 2: (TESTS TERMINATED)
Timestamp calculation: Write down the exact time when you take out the charger. Wait a few hours, open the battery history and write down the latest timestamp it saved.
If I look at the percentage in my battery history: 100% = 11:54:39 @ 17-10-2016. It turned 96% at 15:36:43 the same day. According to the real time stamps: This is 222 minutes for 4% = 1.08%/hour.
Greenify with Xposed settings: Agressive doze, Wakeup Time Coalescing, Dont remove Notifications, Deep Hibernation, GCMPush, Greenifying system apps, reveal hidden sync.
Phoenix ROM 14.2 ------------------------------- 329/89/91 minutes (No explanation on the 329min, looks like an error...)
CM13 + Boeffla 3.3 beta1------------------------ 192 minutes (whatsapp not logged in)
OMEGA ROM------------------------------------- 172 minutes
CM13, ROM Kernel------------------------------- 161 minutes (whatsapp not logged in)
Alexander Rom, ROM Kernel------------------- 141 minutes
CM14 (11-10-2016) + ROM Kernel haggertk--- 140 minutes
Resurrection Remix------------------------------ 129 minutes
CM13, Boeffla 3.2---------------------------------- 74 minutes
Specification tests
Test 1: CM13, Boeffla 3.2 - 100, 99 (31 min), 98 (30 min), 97 (13 min), 96 (13 min), 95, (26 min), 94 (26 min), 93 (63 min), 92, (240 min), 91 (168 min). Average: 68 min.
Test 2: CM13, Boeffla 3.2 - 100, 99 (119 min), 98 (35 min), 97 (64 min), 96 (79 min). Average: 74 min.
Test 3: Alexander Rom, ROM Kernel - 100, 99 (27 min), 98 (21 min), 97 (30 min), 96 (53 min), 95 (106 min, 94 (192 min), 93 (513 min!!), 92 (189 min). Average: 141 min.
Test 4: CM13, ROM Kernel, Screen on for nearly 2 minutes, so could have been higher. - 100, 99 (56min), 98 (34 min), 97 (96 min), 96 (111 min), 95 (178 min), 94 (150) min), 93 (419 min), 92 (240 min). Average: 161 min.
Test 5: Resurrection Remix: 99 (32 min), 98 (12 min), 97 (29 min). 96 (86 min). 95 (91 min), 94 (522 min). Average: 129 min[/U][/B]
Test 6: Omega, 99 (44 min), 98 (27 min), 97 (80 min), 96 (123 min), 95 (126 min), 94 (157 min), 93 (520 min). Average: 172 min
Test 7: CM14 (cm-14.0-20161006-UNOFFICIAL-klte, HaggertK kernel): 100, 99 (103 min), 98 (120 min), 97 (150 min), 96 (141 min). Average 128 min.
Test 8: Phoenix Rom, I had my screen on for 1 second for 5 times in these 3 days. No whatsapp logged in, just installed. Okay, this is starting to mindblow me.. So I started with 100% and took out the charger at @ 19:48 on 08-10-2016. I stopped at 19:02 (it turned 87% on this moment) on the 11/10. that's an average of... 329min..
Specification: 99 (161 min), 98 (152 min), 97 (209 min), 96 (238 min), 95 (242 min), 94 (284 min), 93 (898 min), 92 (438 min), 91 (307 min), 90 (360 min), 89 (324 min), 88 (336 min), 87 (326 min)
Total wakelocks in those 3 days are very few! System UI 4x, SCPM Client 9x, Samsung Keyboard 1x. That must explain it.
Test 9: CM13 + Updated Boeffla 3.3[/SIZE][/B] (beta 3.3). Took the charger out on 11-10-2016 @ 23:11. On 13-10-2016 at 16:33 it turned 87%. That's an average of.. 192 min Wakelocks: System UI 4x, Greenify 1x, Clock 5x, Phone 1x. Even less than the Phoenix, so it's surprising that it drains more battery.. Results are better than before the update, but not anywhere near Phoenix.
Test 10. CM14 (11-10-2016) + ROM Kernel haggertk + Android 7 Gapps 9.8.77 + No Greenify + No Xposed. Started on 20:38 13/10. Ended on 14-10-2016, it turned 91% on 17:35. This is an average of.. 140 min.. Not anywhere near Phoenix.
Test 11. Phoenix ROM, Surprising, started on 15-10-2016 on 00:55. Now at 12:49 it's 91%. That's an average of 89 minutes! Thats way worse than the first test. No differences in settings between the Phoenix Rom tests.. The 329 Min must be an error.
The 2nd and 3rd test show 89 and 91 minutes. HUGE Difference. I can't explain the difference so I did a 4th test:
Test 4 - Phoenix: Installed: Betterbatterystats, Amplifying, Greenify etc according to this thread: http://forum.xda-developers.com/android/general/guide-extreme-battery-life-t3095884. Then let the screen off for a few hours. Limit the highest wakelocks. RILJ0 seemed to be a high wakelock, so limit it to 800 seconds. And the ContextManager to 99999 seconds. I put in another Simcard, charged to 100%, reboot. Let it charge for 10 min, Reset Amplify, take out charger. Started on 16/10/2016 @ 16:45:00. At 17/10 at 05:09 it turned 95%. Average: 148 minutes....
I'm starting to wonder how I got to 329 min in the first test after amplifying wakelocks, alarms, services, greenifying, powernap etc.
Test 13. CM13 + Boeffla 3.3 beta2. No widgets on homescreen, everything disabled. Installed Amplify and limited most used wakelocks, alarms and services. Powernap enhanced mode, appsxposed disabled Google Services. In Progress, started at 11:54.
Update Phoenix Rom in first Post!
Looks nice, thanks for testing this. Boeffla got updated yesterday, so it would be nice to see CM13 updated, as it was broken.
Wysłane z mojego SM-G900F
Are you open to request? for what roms and kernel to use?
BrX91 said:
Looks nice, thanks for testing this. Boeffla got updated yesterday, so it would be nice to see CM13 updated, as it was broken.
Wysłane z mojego SM-G900F
Click to expand...
Click to collapse
Thanks, I'll install CM13 and install Boeffla now, and let screen off untill 87% because that's what the current percentage is. I updated the Phoenix Rom, this is the final conclusion.
The CM13 will then probably take 3 days to get a final result, but that's okay, it's worth it to conclude so please have patience
Yes, You can also do it yourself and install the basic Rom without apps, install greenify and Xposed and post the results here. (Its tempting to put the screen on but do it just for 1 second. I did it 5 times in 3 days. Make sure u put another working Simcard in your S5, otherwise it wouldn't be fair for comparison
Could you do a test of cm13 and 14 but with updated play services. People are reporting that play services from 9683 are the cauz effect battery drains.
Allright, will update my final results of CM13 in 3 hours. The new playservice is what version, 9877? On phoenix I had the same version as on Cm13 so.. and I always greenify all Google system apps including play services and disable auto update. I'll flash CM14 with newest Play services and test it
ikzouhetnietweten said:
Allright, will update my final results of CM13 in 3 hours. The new playservice is what version, 9877? On phoenix I had the same version as on Cm13 so.. and I always greenify all Google system apps including play services and disable auto update. I'll flash CM14 with newest Play services and test it
Click to expand...
Click to collapse
Yeah thats the one. But could you try without greenify. Just the rom and Gapps so we could see what real life battery people could expect to get if they don't use any tweaks or apps.
This could also help to show the difference between a bare system and one with battery saving apps to see if they even work or just placebos.
I did use the last Play Service version in the test CM14 by the way. This is because Android 7 Gapps has already the latest version 9877. But Ok, I'll test CM14 without Greenify and Xposed installed now, and flash the gapps pico Android 7 like I did before. I doubt it's gna be anything different but sure it shows the difference between Greenify and without sure.
I Updated new tests, I now use the Amplify + Powernap + AppopsXposed + BBS. New tests on the way
ikzouhetnietweten said:
I Updated new tests, I now use the Amplify + Powernap + AppopsXposed + BBS. New tests on the way
Click to expand...
Click to collapse
Cool. Could you make another section at the top mentioning the most battery full? Roms in like 1st 2nd and 3rd please.
ikzouhetnietweten said:
I Updated new tests, I now use the Amplify + Powernap + AppopsXposed + BBS. New tests on the way
Click to expand...
Click to collapse
Hi. Very nice with this tests.
Can you make test with 100% to 0% with Antutu Tester (or other app like this?)
Keep up
Sent from my SM-G903F using XDA-Developers mobile app
htb2050 said:
Cool. Could you make another section at the top mentioning the most battery full? Roms in like 1st 2nd and 3rd please.
Click to expand...
Click to collapse
I' m not sure what you mean by the most battery full?
il3gal said:
Hi. Very nice with this tests.
Can you make test with 100% to 0% with Antutu Tester (or other app like this?)
Keep up
Sent from my SM-G903F using XDA-Developers mobile app
Click to expand...
Click to collapse
Thanks! I'll keep on testing and testing untill I reach the limit of the S5
Well, that's gna be really bad for my battery I' m affraid And it gets super hot too, I already did it once with my S3. I am curious about the off screen, but you can always do the test yourself with a basic phone and debloat it and do the test and publish it here. I could put it in the thread.
By the way, I have a new update on the last test, 0,2% per hour.
Are you using the last nightly of CM? Or snapshot?
Arthur King said:
Are you using the last nightly of CM? Or snapshot?
Click to expand...
Click to collapse
Yeah Use the last nightly, I dont know what Snapshot is
You should look to doing something like this, http://forum.xda-developers.com/showthread.php?t=3269557
Sent from my SM-G900F using Tapatalk
I get 0.2/hr (according to gsam battery) *most* of the time. This with xXx No Limits rom (v1.6 LP).
f0xy said:
You should look to doing something like this, http://forum.xda-developers.com/showthread.php?t=3269557
Sent from my SM-G900F using Tapatalk
Click to expand...
Click to collapse
Tnx, Had a lookat it, it's mostlysettings and kernels for the nexus but tnx for info, I' ll try to do the Min freq and highest freq setting on the boeffla config app, but I think this is already in the CPU Ondemand Governor. First I' ll try the current Phoenix Kernel and use a governor with the Kernel audiator app.
taco9 said:
I get 0.2/hr (according to gsam battery) *most* of the time. This with xXx No Limits rom (v1.6 LP).
Click to expand...
Click to collapse
Okay interesting, could you try to install the BBS app, and upload a log here and tell me your settings? Tnx.
I'll update the phoenix login a bit, it's gna be near or lower than the 0.2%/hr record that I currently have.
New update, 0,16% battery per hour. We still haven't found our limit lol. Going strong....
Hey there,
so with all that Amplify and other Battery optimization apps and stuff you're using, is your phone actually still working? I mean are you receiving messages of any sort while the Screen is off, or only after you turn the screen back on?
And how is the signal strength/mobile connection at your place? Cause I can tell from living in what seems like a bunker to radio waves that poor or frequently fluctuating signal strength does increase battery drain. Also don't worry about those misleading results you get, Androids battery usage isn't as constant as one would like it to be.
Collecting multiple results would increase your battery usages accuracy at this point, but nonetheless your test results are giving a nice hint into the direction which things go. Keep up!
Hey guys and girls,
I don´t have time to maintain 2 threads. Look in the Pixel XL forums.
Link is here: https://forum.xda-developers.com/pi...kernel-0-1-t3554330/post70974321#post70974321
So this post will be dedicated to information about EAS in general.
here is a good summary which also goes into detail regarding sched and schedutil.
Another amazing write up about alucardsched by a talented new dev @joshuous:
This is what I understand from tracing the Alucardsched code. I apologise if my understanding is incorrect.
Firstly, next frequency selection with Schedutil (very simple):
Code:
next_freq = 1.25 * Max_freq * current_util / max_util;
Now, here's a quick overview of one cycle of frequency selection in Alucardsched:
1. You have two key extra tunables: PUMP_INC_STEP and PUMP_DEC_STEP
2. Current utilisation here refers to the system's current demand. It is calculated using:
Code:
curr_util = (util * (100 + tunables->boost_perc)) / max_utilisation
The "util" is a value determined by the EAS scheduler.
3. Target load here refers to what processor is currently supplying. It is calculated using:
Code:
target_load = (current_freq * 100) / max_freq;
4. The key idea is to ensure that supply satisfies demand. That is, target load ≈ current load.
5. If target_load <= current_load (too little supply), then we want to increase frequencies to match the system’s load. For Alucardsched, frequency is increased by jumping up PUMP_INC_STEP number of steps in the OPP table. (By OPP table, I refer to the available frequencies that you can switch to)
6. If target_load > current_load (too much supply), then we want to decrease frequencies to match the system’s load. For Alucardsched, frequency is decreased by jumping down PUMP_DEC_STEP number of steps in the OPP table.
7. Do note that Alucardsched jumps several frequency steps, compared to Schedutil and Interactive which try to jump immediately to a calculated next frequency. In this way, Alucardsched doesn't care about the specific value of the next speed. It's like driving a car, and deciding to increase gears by several steps instead of deciding to jump immediately to a specific gear.
Extra Tunables
FREQ_RESPONSIVENESS
PUMP_INC_STEP_AT_MIN_FREQ
PUMP_DEC_STEP_AT_MIN_FREQ
Sometimes you want the "pumping" behaviour to behave differently at lower and higher frequencies. FREQ_RESPONSIVENESS can be seen as the mark that divides the low and high frequencies. If the current frequency is less than FREQ_RESPONSIVENESS, the number of frequency skips will be PUMP_INC_STEP_AT_MIN_FREQ and PUMP_DEC_STEP_AT_MIN_FREQ instead of the usual PUMP_INC_STEP and PUMP_DEC_STEP.
How is it used? If your frequency is low (lower than FREQ_RESPONSIVENESS) and your system demand is high, you ideally want to boost frequency speeds quickly. This is when PUMP_INC_STEP_AT_MIN_FREQ kicks in. PUMP_INC_STEP_AT_MIN_FREQ is usually (and should be) a larger value than PUMP_INC_STEP. When your frequency is high (higher than FREQ_RESPONSIVENESS) and your system demand is high, you don't want to be jumping so many steps up otherwise you will hit max frequencies too quickly (overkill). I'm pretty sure you can figure out how PUMP_DEC_STEP and PUMP_DEC_STEP_AT_MIN_FREQ works after having read this paragraph
Tldr;
Schedutil: simpler
Alucardsched: more tunable
Code:
IF CURRENT_FREQ < FREQ_RESPONSIVENESS:
PUMP_INC_STEP_AT_MIN_FREQ and PUMP_DEC_STEP_AT_MIN_FREQ are used
ELSE:
PUMP_INC_STEP and PUMP_DEC_STEP are used
PUMP_INC_STEP_AT_MIN_FREQ should be larger than PUMP_INC_STEP.
Note: There is however a potential problem (if you may call it one) with Alucardsched: just like Interactive you rely almost entirely on heuristics (trial and error) to control your frequency jumps instead of letting the system choose it for you, like in Schedutil. In that way, Alucardsched detracts from the goal of Schedutil to provide a simple frequency choosing mechanism. Without the proper tuning to meet your specific usage, it is likely that your frequencies will overshoot or undershoot past the needed load on Alucardsched (just like in Interactive). I would recommend that you play with the tunables to see what works best for you.
Here is information about energy-dcfc (Dynamic Capacity and Frequency Capping):
This new governor is based on schedutil. It uses target_load variables as thresholds to let the governor decide when to cap the frequencies for both clusters. These variables are called "load1_cap" and "load2_cap". Load1_cap corresponds to target_load1 meaning anything that is below target_load1, it caps using load1_cap. Anything above target_load1 and below target_load2, use load2_cap. Anything above target_load 2 and the maximum frequency will be used.
As a result of this behaviour, bit shift value must be set to 1. Anything higher than 1 and frequency scaling will be extremely slow. This is because the lower the maximum frequency, the lower the next frequency target is because the frequency range is being limited.
AS OF V009: The governor has now incorporated @Kyuubi10 's schedutil dynamic formula change. When load is below target_load1 it will use add bitshift in the formula. If load is above target_load1 but below target_load2, it won't use any bit shifting at all. If load is more than target_load2, it will subtract bitshift in the formula. This has proven to be very efficient with a touchboost-like behaviour when scrolling (Up to the capped frequency of this governor), then steady performance in between, and on heavy workloads it will not just stay on maximum frequency, in fact it will hover around 1.3-1.9GHz to ensure thermals are good as well as battery endurance.
This governor is aimed with maximum efficiency in mind. Do not expect outstanding performance with this governor.
helix_schedutil explained by @Kyuubi10
To understand Helix_schedutil you must first understand the original schedutil algorithm.
Here it is:
next_freq = maxfreq + (maxfreq >> bitshift) * util/maxcapacity
Explanation:
The most obvious difference of this algorithm is that it moves away from the idea of scaling frequencies up or down which were used in previous generations of governors.
Instead the aim of the above algorithm is to calculate the most appropriate frequency for the TOTAL CPU load.
NOTE: This is TOTAL load on CPU, not just load for the current frequency step as Interactive used to calculate with.
Now, for you numberphiles like myself that like understanding algorithms... Let's break it down:
"util/maxcapacity = Load."
The above creates a percentage value in decimal format (80% = 0.8) which represents the TOTAL load on CPU.
the algorithm now reads the following way:
next_freq = maxfreq + (maxfreq >> bitshift) * load
"maxfreq + (maxfreq >> bitshift)"
Essentially the aim of the above is to ensure that next_freq is always a little higher than the exact value needed to cover the load.
Bitshift: (paraphrasing @ZeroInfinity) in programming the ">>" mathematical function allows for shifting the binary values towards the direction of the arrows by "N" times.
In this case it is towards the right.
The relationship between "N" and the calculation in the "()" is as follows:
Bitshift = 1 = maxfreq/2
Bitshift = 2 = maxfreq/4
Bitshift = 3 = maxfreq/8
If the "+()" didn't exist in the algorithm, the chosen frequency would be exactly enough to cover the load.
If load is 0.6, aka 60%, all you need is a frequency = 60% of max frequency.
This would be bad since it doesn't leave any capacity/bandwidth leftover for inevitable bumps in load, nor space for EAS itself to run. Thus inevitably creating lags.
To keep a bit of free bandwidth you add "(maxfreq >> bitshift)".
Finally the problem I encountered, if bitshift = 2, then the result of the algorithm is that any load above 0.8 will result in a next_freq HIGHER than maxfreq. - This is your tipping point. As any load higher than 80% will wake up a new CPU.
Which means you have still about 20% of the CPU's max capacity being unused. Such a CPU is only 80% efficient.
Therefore by increasing bitshift to 3, the algorithm reads:
"maxfreq+(maxfreq/8)*load = next_freq"
This way you can use 89% of capacity before reaching max frequency of the CPU.
With bitshift=4 it reads:
"maxfreq+(maxfreq/16)*load = next_freq"
This allows you to use up to 94% total CPU load before reaching max frequency.
While this is great for improving efficiency at the higher frequencies, it doesn't leave enough bandwidth when calculating lower frequencies, and creates lag when load spikes at lower frequencies.
Update to the explanation:
After being inspired by the concept of @ZeroInfinity's new governor - Energy-DCFC, I decided to carry out a couple of tests on HTC 10 using variations of Helix_Schedutil.
The focus was stress-testing by increasing the current frequency load above 100%. (AKA Use up all of the bandwidth of the current frequency step.)
After the testing me and Zero worked on this new version of Helix_Schedutil.
The current behaviour of the governor is the following:
- Boost frequencies when load is below Target_Load1. (Boost can be increased by DECREASING bit_shift1 value.)
- Between Target_Loads there is no bit_shift at all. The governor just uses the following algorithm instead - (max_freq*util/max = next_freq)
- Loads higher than Target_Load2 will be THROTTLED. Bit_Shift2 here is subtracted rather than added. (Throttle effect can be increased by DECREASING bit_shift2 value.)
The result is that low freqs have spare bandwidth to avoid lags, middle frequencies leave no extra bandwidth at all, while higher frequencies are throttled to save battery.
Another focus of the governor update is to reduce overhead as much as possible. This results in a very responsive governor which isn't overly demanding on battery life.
Schedtune.boost values recommended for use with this governor:
Top_App: 5
Foreground: -50
Background: -50
Global: -50
Energy-DCFC is still recommended for those who prefer battery life over performance, but if you prefer greater performance then this governor can be used without making you feel guilty about wasting battery.
correction a misconception:
Some people describe tipping point as the load threshold which the governor uses to decide whether to ramp up or down.
While if you look into the behaviour of the governor it may appear that it behaves in such a way, it is technically incorrect.
As I mentioned previously this new algorithm moves away from the behaviour of legacy governor algorithms which focus on the current frequency load.
This governor does no ramping up or down.
It isn't even aware of the current frequency load, as it only knows the load relative to max capacity.
The misconception appears based on a property of the algorithm that results in a consistent load at any chosen frequency. This is a coincidental result of the algorithm, even though the algorithm is completely unaware of it.
Tipping point is in fact the load percentage at which the CPU reaches max frequency and any increase in load forces it to wake up a new core
here is some Information about pwrutil governor:
This new governor is based on schedutil.
A much simpler yet very effective governor based on schedutil. All this changes is the calculation to get the next frequency. Rather than using bit shift to calculate tipping point and what not, we don't use it at all. This is much much more efficient if you use my program called "schedutilCalculator" to calculate what the next frequency is. For example, a load of 25% with a max freq of 2150400 will get 500MHz as next frequency. A load of 50% will get 1GHz as next frequency. A load of 75% will get 1.5-1.6GHz as next frequency. A load of 100% will get 2.15GHz as next frequency. You can see the lower the load, the much lower the frequency selection will be, but the higher the load and the higher the frequency selection is. So it can go from a very low powered state with 50% load and under, to a high performance state from 75% load and above.
Includes a tunable called "utilboost" which is basically a load multiplier - it makes load higher than it is perceived by the governor, thus making next frequency selection higher. Remember utilisation does not equal load. The equation of calculating load is util / max capacity of a CPU (which should be 1024). So 512 / 1024 = 0.5 (50% load).
UTIL BOOST IS NOT MEANT TO BE USED WITH SCHEDTUNE.BOOST AT THE SAME TIME! EITHER USE ONE OR THE OTHER OR ELSE PERFORMANCE WILL BE OVERKILL AND BATTERY LIFE WILL DRAIN MUCH FASTER!!!
Util boost is supposed to be a replacement of schedtune.boost. schedtune.boost applies boosting to both clusters, whereas util boost allows boosting per-cluster so users can have much more control.
how to gather logs:
There are several apps that can do this process for you, Here is one: PlayStore: SysLog
And here is another: PlayStore: Andy Log (ROOT)
ramopps: is an oops/panic logger that writes its logs to RAM before the system
crashes. It works by logging oopses and panics in a circular buffer. Ramoops
needs a system with persistent RAM so that the content of that area can
survive after a restart.
logcat: the logoutput of the Android system
kernel log: (kmsg / dmesg): the kernel messages
Additionally there's the last_kmsg which is a dump of the kernel log until the last shutdown.
radio log: the log outpur ot your System / BB / RIL communication
4
ramopps:Some Documentation on Ramopps
Normal Logcat:
Radio Logcat:
Ramoops:
Via adb:
adb shell su -c cat /sys/fs/pstore/console-ramoops > kmsg.txt
Via terminal on phone:
su
cat /sys/fs/pstore/console-ramoops > /sdcard/kmsg.txt
Kernel Log:
Kernel Log:
adb shell su -c dmesg > dmesg.log
Last_Kmsg:NOTE:
New location of last_kmsg on Android 6.0 and above: /sys/fs/pstore/console-ramoops
adb shell su -c "cat /proc/last_kmsg" > last_kmsg.log
NOTES:
-v time will include timestamps in the logcats
-d will export the complete log.
If you want to save a continuous log you can remove the -d parameter - then you need to cancel the logging process via CTRL+C.
To export a continuous kernel log use adb shell su -c "cat /proc/kmsg" > dmesg.log (and cancel it via CTRL+C again).
PS: This Document was taked from another XDA Thread Called: [Reference] How to get useful logs
URL: http://forum.xda-developers.com/showthread.php?t=2185929
Also check this one out: [Tutorial] How To Logcat
I only Revived it a bit for ramopps.
I will update this more at a later time..
Attemped install on Pixel, ended up with black screen after white "unlocked booloader screen" had to reinstall system and custom rom.
Well it was confirmed working before.
Did anybody else flashed it successfully? And please follow my instructions in the op.
Freak07 said:
Well it was confirmed working before.
Did anybody else flashed it successfully? And please follow my instructions in the op.
Click to expand...
Click to collapse
It worked for me by following instructions in the OP
Followed the instructions from OP, works fine for me!
Thanks for your works, try it out now
ne0ns4l4m4nder said:
Attemped install on Pixel, ended up with black screen after white "unlocked booloader screen" had to reinstall system and custom rom.
Click to expand...
Click to collapse
Working fine here following OP, thanks for another Kernel brotha!!
so idoes this kernal work better in lineage ROMS like hexa and Resurrection Remix v5.8.1 Roms ???
abunhyan said:
so idoes this kernal work better in lineage ROMS like hexa and Resurrection Remix v5.8.1 Roms ???
Click to expand...
Click to collapse
Make sure to use supersu and not the inbuilt lineage superuser.
On rr it should run without an issue. At least it was reported in the xl thread.
Currently rooted on 7.1.1 and haven't ventured away from stock. It should be good just to follow instructions and flash?
TheBurgh said:
Currently rooted on 7.1.1 and haven't ventured away from stock. It should be good just to follow instructions and flash?
Click to expand...
Click to collapse
yes. Make a backup just in case. And use the latest supersu zip.
abunhyan said:
so idoes this kernal work better in lineage ROMS like hexa and Resurrection Remix v5.8.1 Roms ???
Click to expand...
Click to collapse
Running great on RR with latest SU ?
Running great in RR here also with 10% battery drain in 10 hour !!! thats great result
one thing tho double tap to weak function not working from lock screen at all!!!!
abunhyan said:
Running great in RR here also with 10% battery drain in 10 hour !!! thats great result
one thing tho double tap to weak function not working from lock screen at all!!!!
Click to expand...
Click to collapse
What exactly is your problem?
You can enable dt2w in exkm. But the one that is in the rom will be overwritten as the kernel one works more reliable.
Freak07 said:
What exactly is your problem?
You can enable dt2w in exkm. But the one that is in the rom will be overwritten as the kernel one works more reliable.
Click to expand...
Click to collapse
its Dt2w not functioning after installing the kernal and its was working well before that
can u explain how i can enable it?
and regard the sound control app can u advice which app i can use to enhance sound quilty by using Bluetooth headset
Thanks for ur great help:good:
abunhyan said:
its Dt2w not functioning after installing the kernal and its was working well before that
can u explain how i can enable it?
and regard the sound control app can u advice which app i can use to enhance sound quilty by using Bluetooth headset
Thanks for ur great help:good:
Click to expand...
Click to collapse
For controlling dt2w use this app.
https://play.google.com/store/apps/details?id=flar2.exkernelmanager
You can find the option in the sector gestures. Just enable it and you are set.
Audio options are under sound.
The sound for bluetooth can only be altered via software mods like viper4android.
If you really care about sound quality you should use wired headphones. But the quality for bluetooth may be enhanced by default.
hey guys and girls,
I have a new kernel now in testing. If I have no Issues I will post it in a few hours.
I added the possibility to use sdcardfs. big thanks to @DespairFactor here, he provided some help.
you just have to add ro.sys.sdcardfs=true to your build.prop
I tested it for two days now and encountered no issue. Using it may improve I/O performance.
here is some reading, in case you are interested:
https://www.xda-developers.com/divi...les-fuse-replacement-will-reduce-io-overhead/
I also added two new governors developed by @alucard_24, called alucardsched and darknesssched.
They are both based of on EAS. You may use them as an alternative to sched and schedutil.
I think alucardsched is more battery friendly. But I had quite a few stutters with it. Maybe you guys can give feedback on this.
shindiggity said:
Running great on RR with latest SU ?
Click to expand...
Click to collapse
Do you have I/0 options in your kernel manager? And are you using supersu, or the SU baked into the ROM?
Freak07 said:
For controlling dt2w use this app.
https://play.google.com/store/apps/details?id=flar2.exkernelmanager
You can find the option in the sector gestures. Just enable it and you are set.
Audio options are under sound.
The sound for bluetooth can only be altered via software mods like viper4android.
If you really care about sound quality you should use wired headphones. But the quality for bluetooth may be enhanced by default.
Click to expand...
Click to collapse
by dt2w, he means the stock android implementation where you double tap into the ambient display I think