Database Develop

[DEV] YACS - Yet Another Configuration Script for Nova ROM

Hello everyone!
Here is a little script I wrote for setting frequencies, voltages, governor and I/O scheduler in your phone running Nova ROM. Largely inspired by knzo's own script I decided to write my own for two reasons: understand the black magic behind it and teach myself the basics of shell scripting. To achieve this I got rid of the overhead and rewrote the remaining as shortly as possible. Since I've been the only one to test it so far I'd be really glad if anyone else gives it a try as well.
However, if you decide to go forward and give it a try, I'm going to assume that you're already advanced enough to know what you're doing. It doesn't hurt to backup your /data partition first and only then start experimenting. It's not unheard of to make a mesh of your data because services and applications crashed due to too much over-clocking or under-volting. If you're already familiar with knzo's and Huexxx's work then it's not going to kill you (or your phone). Anyway, be careful!
With that out of the way I'll say few words about the script itself. Here is how the main menu looks like:
Code:
MAIN MENU
1. Set frequency and voltage
[1100/54(54),800/44(44),600/34(35),300/20(24)]
2. Set governor [SmartassV2]
3. Set I/O scheduler [vr]
4. Set current values at boot
5. Reboot
0. Quit
The menu items speak mostly for themselves. Current values are fetched from corresponding system files and are shown in square brackets (with calibrated voltages in parentheses). The current values are there for you and visible inside sub-menus as well. After changing the values you have an option to set these values to be loaded at boot time and tell the phone to reboot as well to see if your choices are bootable.
Keep in mind that the choices you have made here may look stable while running the script and doing parallel stress testing perhaps but they may not be bootable! I've added a watchdog to guard you and if it so happens that your phone hangs while booting then the script will not apply your settings next time. Take out your battery and try again. If you're lucky then your /data partition is unaffected and you can go on unharmed. If you push it too hard then it is very likely you'll have to lean on your backups.
Back to introducing the script. What I did differently from knzo was the method how the settings are applied. No matter where and what you change, all the values are dynamically written to a separate script and then this script gets executed. The same script is used inside init.d and I had to add a condition there which checks if we are running from init.d or not. This has to do with the "stubborn" governor which gets overwritten by some process at boot. Therefore I added 15 second sleep there to set it just a little bit later.
Also different from knzo's script is the way how governor and scheduler choices are shown. Namely, these lists are created dynamically from available values.
The script also checks if you are root or not and tells you a friendly message if you need to su first.
About installing it. I haven't yet learned anything about how to install this script with as few hassles as possible and you'll have to get this script into your phone manually for now. Just copy this on your sdcard over the USB or bluetooth or any way you like, move it to /system/xbin for example, set execute permissions and run it. I'll definitely teach myself the ways of APK next. And will write a standalone application afterwards
And now for something technical. As this is my very first shell script ever then there are couple of things that might not be done most elegantly.
1) Boot detection relies solely on the existence of ANDROID_SOCKET_zygote environment variable which is empty now at boot and gets initialized sometimes later. Things will not work as intended any more if the Zygote decides to do something differently in the future. What would be better indicator here?
2) User detection uses stderr output from whoami which seems to be 'unknown uid 0' for root now and 'unknown uid 10008' for ordinary user. Is it OK to rely on that or is there a change that it'll say something else on other phones?
Well, that's it. The script itself is attached here and I tried to write some comments there as well to help you read it better.
I hope this is of some use to anybody besides me and thanks for reading so far. All your comments are very welcome!
Regards,
Aprold

Hi,
I'm not going to use it at least for now because I'm doing a battery marathon... and I dont' want to reboot my phone.
I'll take a look at the script to extract some useful knowledges for sure.
In order to make a flashable zip, it's so easy! Download my Huexxx's Nova v8 Stuff, decompress the zip and look inside. The most important thing is the update script, but is very easy.
You only have to modify the script, add or remove things to the folder structure and compress it with you favorite compressor into a zip. Thats all.
Regards and good work!

Another theme... Do you manually set your voltajes from the script?
Take a depp look at my UV posts (disasembling the Myth, UV script, Nova v8 Stuff) and you will learn some useful info regarding the fact that impose certain voltage values it useles taking into account that Smartreflex subsystem will set the values it wants!
Regards.

Setting voltages is manual job right now because there is really not much you can do automatically. This Smartreflex behaviour is quite limiting indeed. If you use higher voltages then calibrated voltages will be higher as well. If you try to go lower then you'll hit the wall somewhere where SR thinks it can't go lower any more. It would be possible to detect this "wall" automatically by decrementing vsel values and staying with values where calibrated voltages don't want to go any lower and I might just add this as a menu option to my script this evening and test if it is reliable with different voltages. I also tried to go outside the SR "window" and ended up hanging my phone every time. It seems to hold on to entered voltages only so far and if the difference grows too big it lets go. My "wall" values are around 54, 44, 34, and 24 (Huexxx's values were a little bit lower) and I fly out of the "window" with ~15 % lower values and the phone hangs.
EDIT:As Huexxx has corrected me below there is no way one can affect calibrated voltages when SR is active. Therefore I'm not going to modify my script, too.

aprold said:
If you use higher voltages then calibrated voltages will be higher as well.
Click to expand...
Click to collapse
I am in disagree with you... In my case, using different voltage values (from very high to ultra low according to the frevolt table supplied with nova) ended in the same calibrated values.
Regards.

I stand corrected. It is indeed so and then there is really nothing one can do to affect current voltages

aprold said:
I stand corrected. It is indeed so and then there is really nothing one can do to affect current voltages
Click to expand...
Click to collapse
This isn't entirely true... you can affect to current voltages in order to UV a little bit. If suggested voltaje by SR is 34, wou can push 33 or 32 without problems and SR effectively takes the value. This is what I've implemented with my Nova v8 Stuff, UV and AUV to set it on boot.
Regards.

Sadly this is not the case with my phone. The "wall" that I mentioned is around 54, 44, 34, 24 for me and I even if I try to lower the calibrated values are still the same ±1 depending on how the calibration went.

aprold said:
Sadly this is not the case with my phone. The "wall" that I mentioned is around 54, 44, 34, 24 for me and I even if I try to lower the calibrated values are still the same ±1 depending on how the calibration went.
Click to expand...
Click to collapse
Are 54, 44, 34 and 24 the calibrated values when you push stock voltages?
Then, if you try 53, 43, 33 and 23, it should take 53, 43, 33 and 23 with calibrated at least with some value... In my case sometimes one of the values stucks on stock calibrated one, but the rest do the job.
Regards.

Huexxx said:
Then, if you try 53, 43, 33 and 23, it should take 53, 43, 33 and 23 with calibrated at least with some value
Click to expand...
Click to collapse
Nope. I did a few measurements today and this is how it looks on my phone:
Code:
1100 800 600 300
1 [COLOR="Red"]66[/COLOR] [COLOR="Green"]55[/COLOR] [COLOR="Red"]56[/COLOR] [COLOR="Green"]45[/COLOR] [COLOR="Red"]46[/COLOR] [COLOR="Green"]35[/COLOR] [COLOR="Red"]36[/COLOR] [COLOR="Green"]25[/COLOR]
2 [COLOR="Red"]65[/COLOR] [COLOR="Green"]54[/COLOR] [COLOR="Red"]55[/COLOR] [COLOR="Green"]45[/COLOR] [COLOR="Red"]45[/COLOR] [COLOR="Green"]35[/COLOR] [COLOR="Red"]35[/COLOR] [COLOR="Green"]25[/COLOR]
3 [COLOR="Red"]64[/COLOR] [COLOR="Green"]54[/COLOR] [COLOR="Red"]54[/COLOR] [COLOR="Green"]45[/COLOR] [COLOR="Red"]44[/COLOR] [COLOR="Green"]35[/COLOR] [COLOR="Red"]34[/COLOR] [COLOR="Green"]25[/COLOR]
4 [COLOR="Red"]63[/COLOR] [COLOR="Green"]55[/COLOR] [COLOR="Red"]53[/COLOR] [COLOR="Green"]45[/COLOR] [COLOR="Red"]43[/COLOR] [COLOR="Green"]35[/COLOR] [COLOR="Red"]33[/COLOR] [COLOR="Green"]25[/COLOR]
5 [COLOR="Red"]62[/COLOR] [COLOR="Green"]55[/COLOR] [COLOR="Red"]52[/COLOR] [COLOR="Green"]45[/COLOR] [COLOR="Red"]42[/COLOR] [COLOR="Green"]35[/COLOR] [COLOR="Red"]32[/COLOR] [COLOR="Green"]25[/COLOR]
6 [COLOR="Red"]61[/COLOR] [COLOR="Green"]55[/COLOR] [COLOR="Red"]51[/COLOR] [COLOR="Green"]45[/COLOR] [COLOR="Red"]41[/COLOR] [COLOR="Green"]35[/COLOR] [COLOR="Red"]31[/COLOR] [COLOR="Green"]25[/COLOR]
7 [COLOR="Red"]60[/COLOR] [COLOR="Green"]54[/COLOR] [COLOR="Red"]50[/COLOR] [COLOR="Green"]45[/COLOR] [COLOR="Red"]40[/COLOR] [COLOR="Green"]35[/COLOR] [COLOR="Red"]30[/COLOR] [COLOR="Green"]25[/COLOR]
8 [COLOR="Red"]59[/COLOR] [COLOR="Green"]55[/COLOR] [COLOR="Red"]49[/COLOR] [COLOR="Green"]45[/COLOR] [COLOR="Red"]39[/COLOR] [COLOR="Green"]35[/COLOR] [COLOR="Red"]29[/COLOR] [COLOR="Green"]25[/COLOR]
9 [COLOR="Red"]58[/COLOR] [COLOR="Green"]54[/COLOR] [COLOR="Red"]48[/COLOR] [COLOR="Green"]44[/COLOR] [COLOR="Red"]38[/COLOR] [COLOR="Green"]34[/COLOR] [COLOR="Red"]28[/COLOR] [COLOR="Green"]25[/COLOR]
10 [COLOR="Red"]57[/COLOR] [COLOR="Green"]54[/COLOR] [COLOR="Red"]47[/COLOR] [COLOR="Green"]44[/COLOR] [COLOR="Red"]37[/COLOR] [COLOR="Green"]35[/COLOR] [COLOR="Red"]27[/COLOR] [COLOR="Green"]24[/COLOR]
11 [COLOR="Red"]56[/COLOR] [COLOR="Green"]53[/COLOR] [COLOR="Red"]46[/COLOR] [COLOR="Green"]44[/COLOR] [COLOR="Red"]36[/COLOR] [COLOR="Green"]35[/COLOR] [COLOR="Red"]26[/COLOR] [COLOR="Green"]24[/COLOR]
12 [COLOR="Red"]55[/COLOR] [COLOR="Green"]54[/COLOR] [COLOR="Red"]45[/COLOR] [COLOR="Green"]44[/COLOR] [COLOR="Red"]35[/COLOR] [COLOR="Green"]35[/COLOR] [COLOR="Red"]25[/COLOR] [COLOR="Green"]25[/COLOR]
13 [COLOR="Red"]54[/COLOR] [COLOR="Green"]54[/COLOR] [COLOR="Red"]44[/COLOR] [COLOR="Green"]44[/COLOR] [COLOR="Red"]34[/COLOR] [COLOR="Green"]35[/COLOR] [COLOR="Red"]24[/COLOR] [COLOR="Green"]25[/COLOR]
14 [COLOR="Red"]53[/COLOR] [COLOR="Green"]54[/COLOR] [COLOR="Red"]43[/COLOR] [COLOR="Green"]44[/COLOR] [COLOR="Red"]33[/COLOR] [COLOR="Green"]35[/COLOR] [COLOR="Red"]23[/COLOR] [COLOR="Green"]24[/COLOR]
15 [COLOR="Red"]52[/COLOR] [COLOR="Green"]54[/COLOR] [COLOR="Red"]42[/COLOR] [COLOR="Green"]44[/COLOR] [COLOR="Red"]32[/COLOR] [COLOR="Green"]35[/COLOR] [COLOR="Red"]22[/COLOR] [COLOR="Green"]24[/COLOR]
16 [COLOR="Red"]51[/COLOR] [COLOR="Green"]54[/COLOR] [COLOR="Red"]41[/COLOR] [COLOR="Green"]44[/COLOR] [COLOR="Red"]31[/COLOR] [COLOR="Green"]35[/COLOR] [COLOR="Red"]21[/COLOR] [COLOR="Green"]24[/COLOR]
17 [COLOR="Red"]50[/COLOR] [COLOR="Green"]54[/COLOR] [COLOR="Red"]40[/COLOR] [COLOR="Green"]44[/COLOR] [COLOR="Red"]30[/COLOR] [COLOR="Green"]35[/COLOR] [COLOR="Red"]20[/COLOR] [COLOR="Green"]24[/COLOR]
Reds are entered and greens are calibrated voltages.
And here is a small visual aid too:
{
"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"
}

aprold said:
Click to expand...
Click to collapse
You guys have too much free time!
Anyway, I do enjoy these statistics so keep them coming.
Seems that after all UV doesn't even work?

Look at this:
This is the result of my script into oscarbg13's OB from HtcMania. (Spanish forum). It seems to be working flawlessly.
Look at the data:
- In Current Calibrated Values you can see the calibrated Nova v8 voltages; the calibrateed voltages before my script. Look at the 4th value... it seems to be bad calibrated because 32 is the nominal value.
- In Current Recalibrated Values you can see the values after a recalibration. At this specific case, 1st and 2nd value are higher than previous, while 4th value has reached the correct value.
- With the last version of my script, I take the min walues between both calibrations for each frequency: 1st and 2nd from initial calibration, and 4th from recalibration.
- In New Calibrated Values we have the final values, and as you can see all of them are a unit lower than the minimal value for that frequency.
I'm going to do the last modification to my script in order to add a 'UV depth' and then get a custom UV. Then, setting the 'UV depth' to 0, what we gain is a syste to ensure:
- All the values are well calibrated.
- All the values use the minimal value suggested by smartreflex system without any UV.
Aprold, to say that in my case, when the phone is not recently booted, recalibration seems to don't properly work. The best time to recalibrate is at boot time.
Regards.

Huexxx, yes I have read your script and I understand what you're doing there. You simply take two sets of calibrated values and then try to set new voltages which are 1 less than minimum of these two. Perhaps this has some effect on some devices but as you can see from the graph above it doesn't really matter which values you set - the outcome is generally the same for me. The values I took for the graph were all from boot-time calibration. And I should say that drawing this graph in Excel 2010 brought up a lot of @%$%#'s and (%#&(^%'s because the last time I was using Excel 2003 for that kind of a job. Who came up with an idea of ribbon menu anyway?!?

aprold said:
Huexxx, yes I have read your script and I understand what you're doing there. You simply take two sets of calibrated values and then try to set new voltages which are 1 less than minimum of these two. Perhaps this has some effect on some devices but as you can see from the graph above it doesn't really matter which values you set - the outcome is generally the same for me. The values I took for the graph were all from boot-time calibration. And I should say that drawing this graph in Excel 2010 brought up a lot of @%$%#'s and (%#&(^%'s because the last time I was using Excel 2003 for that kind of a job. Who came up with an idea of ribbon menu anyway?!?
Click to expand...
Click to collapse
Once used to 2010 style, I like it so much!
Your case seems to be a aislated case, because I've probed my script on some OBs.
Can you try my script, with depth equal to 1 and post /data/nova/auto/avdlog here?
Regards!

Huexxx said:
Can you try my script, with depth equal to 1 and post /data/nova/auto/avdlog here?
Click to expand...
Click to collapse
Kind of dull result:
Code:
Current frequency values: 1100 800 500 300
Current calibrated values: 54 44 34 24
Current recalibrated values: 54 44 34 24
New calibrated values: 54 44 34 24
Tried it several times, once I saw 23 instead of 24 and once 43 instead of 44 there, but it really seems to be the limit for my phone

I'm sorry, your phone seems effectively to have a wall.
All I can say is that the situation is not the same for everybody, and your phone is the first I've seen with this behaviour.
Maybe the best feature of my script apart from apply or not a certain ammount of UV is the possibility to ensure that the four voltages are well calibrated.
I've seen some OBs (including mine) that at certain startup leave some uncalibrated voltages, and this can be the reason why some people report a excesive waste of battery in standby; maybe at the latest boot the voltage for min freq. was bad calibrated.
I'll enjoy a lot with Gingerbread, I think!

my /data/nova/auto/avdlog
Code:
Current frequency values: 1100 800 500 300
Current calibrated values: 53 43 32 23
Current recalibrated values: 53 43 32 23
Auto UV Depth: 1
New calibrated values: 53 42 31 22
And what does it mean?

redy2006 said:
my /data/nova/auto/avdlog
Code:
Current frequency values: 1100 800 500 300
Current calibrated values: 53 43 32 23
Current recalibrated values: 53 43 32 23
Auto UV Depth: 1
New calibrated values: 53 42 31 22
And what does it mean?
Click to expand...
Click to collapse
This mean:
- Your values seems to be well calibrated at startup, before my script, because the calibrated and recalibrated values are the same.
- When applying the UV, all goes well, because your 1100 max freq disables the UV over it (remains at 53) while the other values decrease one unit.
If all goes well and you don't experience any problems, you will be saving a bit at standby and at intermediate freqs too if your governor uses them. Of course don't expect so much, but everything help.
Look at my last boot:
Code:
Current frequency values: 900 700 500 300
Current calibrated values: 50 41 32 22
Current recalibrated values: 50 41 32 21
Auto UV Depth: 1
New calibrated values: 49 41 31 20
In my case look at min freq voltage, recalibrating it I've obtained 21, then the UV applied decrements it one unit to 20. In my case UV is applied to max freq too because is lower than 1 GHz.
Regards.
---------- Post added at 03:57 PM ---------- Previous post was at 03:56 PM ----------
Maybe this discussion would be moved to my thread... We are flooding aprold's thread!

[ICSbeta] finally a responsive touchscreen + battery life *try this* : UPDATE 4/28/12

ok, nothing seemed to be making the touchscreen responsive with the ICS beta n its derivatives.
except one thing just did.
i changed the sampling rate from 200000(2 lak) to 20000 (20 hazar), n of course i had to change the up-threshold so i changed that to 95 (i did all these in rom-toolbox's kernel tweaks settings)
now everything is super-responsive (app startups, physical buttons, onscreen buttons, switching, yo name it) N while you are just lets say reading stuff on the screen, the cpu is generally at its lowest
what that means is : both responsiveness and higher battery.
please comment.
UPDATE : check the 7th post on this forum for more tweaks for snappy app launching n switching here http://forum.xda-developers.com/showthread.php?t=1570374#post24186676
UPDATE : ADDITIONAL TWEAK (more battery life) : in rom-toolbox change powersave bias to 35 (in rom toolbox) : saves a lot more battery by preventing the cpu from rushing to full-frequency while you are doing simple tasks like flicking the screen.
UPDATE : 3/31/12 : an interesting observation about "force gpu" 's causing poor performance on my post here : http://forum.xda-developers.com/showthread.php?t=1570374&page=2#post24266342
UPDATE : 4/7/12 : want even more battery life n smoothness?
add these to your build.prop save , reboot into recovery, clean dalvik-cache and /cache partition then reboot into system. things should be faster. and oh, underclock it.
ro.kernel.android.checkjni=0
dalvik.vm.execution-mode=int:jit
ro.ril.disable.power.collapse=0
ro.mot.buttonlight.timeout=1
dalvik.vm.verify-bytecode=false
dalvik.vm.dexopt-flags=v=n,o=v
you can also do a semi-odex using titanium backup's integrate system dalvik into rom thing, but then you won't be able to change any file in the rom (like applying patches, mods etc until you've either done undo integration thing in titanium backup or just used adb shell to delete *.odex from /system/apps n rebooted)
UPDATE : 4/28/12 : if you are using a derivative of the .562 ICS then you can change the kernel tweaks/sysctl settings to dirty_ratio = 80 dirty_background_ratio = 20 and vfs_cache_pressure = 20 to get snappy app startups up_threshold and powersave_bias can both be set to 90 and select ignore_nice_load. if you use lots of apps then raise the dirty background ratio and dirty ratio both by 15 points and reduce vfs_cache_pressure by 15 for low cpu usage while the apps are running. i've noticed that many of the custom roms have started getting my tweaks or similars preincluded , plus the official ics is much better than icsbeta in memory management. and oh, use arcknight kernel. its super awesome for both features and battery life. i switch my governor to interactivex or smartassv2 when i am recording using the 14mbps camcorder mod, and then back.
the android backup & restore under person in settings should be turned off. it takes a lot of cpu, battery, data n memory. its aweful.
if this works for you, press the thanks button.

How can this be done?

Duvel999 said:
How can this be done?
Click to expand...
Click to collapse
i used rom toolbox pro, its free version is available here - https://play.google.com/store/apps/details?id=com.jrummy.liberty.toolbox
anything else that can edit sysctl.conf (e.g. https://play.google.com/store/apps/details?id=com.jrummy.sysctl.config and https://play.google.com/store/apps/details?id=scd.atools ) will also work.

Gonna try it

system seems to be a bit snappier
thx mate

thnx mate.

for snappy app switching i discovered another bunch of settings
in rom toolbox's kernel tweaks under performance, change min free kbytes to [CORRECTION]8192[not 8096] (or [UPDATE] 6144 - whichever one you like), dirty ratio to 95, dirty background ratio to 70 and vfs cache pressure to 5 (n of course check the apply on boot option)
let me know how you like this additional tweak
UPDATE: some observations ; high dirty ratio causes lower cpu usage n faster app-switching, low dirty background ratio causes faster app startups but uses too much cpu, vfs cache pressure above 5 or 10 causes high cpu usage n lags. (i use lots of apps)
UPDATE #2 FURTHER IMPROVEMENTS (fast all around with acceptable cpu usage, super app switching, n decently fast launcher without sacrificing cpu-speed n battery life)
Kernel Tweaks :
reduce dirty background ratio to 50
check the OOM kill allocating task (if your device crashes after this, uncheck this, it may kill the android system n android os processes as well in some cases)
Auto Memory Manager :
foreground 6
visible 8
secondary 32
hidden 40
content 48
empty 120

Thnks
[white10char]

The up-threshold and powersave bias settings do not stick for some reason. They return to default values after a reboot even though Apply on boot is checked.
Sent from my LT15i (Xperia arc) on KA ICSony

sunbriel said:
The up-threshold and powersave bias settings do not stick for some reason. They return to default values after a reboot even though Apply on boot is checked.
Sent from my LT15i (Xperia arc) on KA ICSony
Click to expand...
Click to collapse
It is the same for me. I guess we'll have to review each init.d script to see what is the one that is changing these values on restart.

estuardo4 said:
It is the same for me. I guess we'll have to review each init.d script to see what is the one that is changing these values on restart.
Click to expand...
Click to collapse
perhaps kickass kernel script

sunbriel said:
The up-threshold and powersave bias settings do not stick for some reason. They return to default values after a reboot even though Apply on boot is checked.
Sent from my LT15i (Xperia arc) on KA ICSony
Click to expand...
Click to collapse
estuardo4 said:
It is the same for me. I guess we'll have to review each init.d script to see what is the one that is changing these values on restart.
Click to expand...
Click to collapse
check the 98kickasskernelizer (i'd find the respective values - especially min-free n change them in the script itself), there are two other not so popular scripts out there too that you may be using.
please share with us whatever was causing the overriding of rom toolbox's (or sysctl etc)'s settings.

Hey there thanks for the tip. Already tried it but I don't think there's any major improvement. In fact, antutu graphic score is down a bit. But don't know why. Maybe just my phone.
sent from my white ray using XDA App

hansip87 said:
Hey there thanks for the tip. Already tried it but I don't think there's any major improvement. In fact, antutu graphic score is down a bit. But don't know why. Maybe just my phone.
sent from my white ray using XDA App
Click to expand...
Click to collapse
the benchmarks dont tell you about usability. better responsiveness is due to faster cpu response to situations.
antutu's benchmark tests for continuous high performance (battery hogging w/lags) while running just one app.
my settings are for giving great experience (touch, app switching and app launching as well)
think of it as antutu being a mr. universe test, while mine are a gymnastics olympics tournament.

Well thanks. A lot less sluggish when scrooling..
Sent from my LT18i using XDA

darth5zaft said:
Well thanks. A lot less sluggish when scrooling..
Sent from my LT18i using XDA
Click to expand...
Click to collapse
thank you.
i just posted another slight tweak for higher battery life. its in the first post.

sunbriel said:
The up-threshold and powersave bias settings do not stick for some reason. They return to default values after a reboot even though Apply on boot is checked.
Sent from my LT15i (Xperia arc) on KA ICSony
Click to expand...
Click to collapse
estuardo4 said:
It is the same for me. I guess we'll have to review each init.d script to see what is the one that is changing these values on restart.
Click to expand...
Click to collapse
i tried 6144, restarted n it sticks. try 8192 (i haven't tried restarting after that) : my 8096 was a mistake - i accidently doubled 1024 to 2048 n that to 4096 and then stupidly to 8096.
it is possible that numbers that are not multiples of 1024 are ignored if set on boot.
that occurred to me since init.d scripts are loaded much before rom-toolbox gets a chance to do its magic.

estuardo4 said:
It is the same for me. I guess we'll have to review each init.d script to see what is the one that is changing these values on restart.
Click to expand...
Click to collapse
Could it be that these settings are conflicting with Supercharger?
Sent from my LT15i (Xperia arc) on KA ICSony

hootnath said:
i tried 6144, restarted n it sticks. try 8192 (i haven't tried restarting after that) : my 8096 was a mistake - i accidently doubled 1024 to 2048 n that to 4096 and then stupidly to 8096.
it is possible that numbers that are not multiples of 1024 are ignored if set on boot.
that occurred to me since init.d scripts are loaded much before rom-toolbox gets a chance to do its magic.
Click to expand...
Click to collapse
I tried and it stuck after a reboot. It is working fine now. My battery is lasting more indeed, but wifi is always on, even after I made the suggested changes. I guess I'll have to reinstall Doomkernel v04 and JJ's ROM from scratch. But even with wifi always on, I'm having better battery life and less lag.
Thank you again.

estuardo4 said:
I tried and it stuck after a reboot. It is working fine now. My battery is lasting more indeed, but wifi is always on, even after I made the suggested changes. I guess I'll have to reinstall Doomkernel v04 and JJ's ROM from scratch. But even with wifi always on, I'm having better battery life and less lag.
Thank you again.
Click to expand...
Click to collapse
i found another interesting thing today.
the force GPU for 3d in the settings -> developer options actually uses a lot of the cpu and causes lags. i turned it off and have instead done the following
Get rid of CPU rendering:
Navigate to /system/lib/egl/
Open the file named "egl.cfg"
Delete the first line. It should say "0 0 android" or something similar
Go back into the egl folder and delete libGLES_android.so
What this does is remove the entire soft-rendering pathway from the OS.
source : http://www.ifans.com/forums/threads/ics-performance-tweaks.369959/ ;
now, i have changed the powersave bias in teh romtoolbox's kernel tweaks to 95 instead of {correcton}35{not]95. the cpu is spending more time @ 122mhz and deep sleep now without lags (which means more battery)
if this thing works for you, please press thanks.

[KERNEL][3.10.71][KCAL] Velocity v1.1

*** Disclaimer
I am not responsible for any kind of damage to your device,
or in case it explodes, your surroundings.
Please use it at your own risk!
Click to expand...
Click to collapse
Features :
-O3, Cortex-A53, NEON, VFPv4 optimizations
Compiled from latest Linaro GCC 4.9.3 2015.02 Toolchain [Christopher83]
Upstreamed to 3.10.71 from kernel.org, from 3.10.28
Asynchronous Fsync ported from HTC Devices
Dynamic Fsync v2.0 [faux123/varunchitre15]
PowerSuspend v1.7 driver support (replaces EarlySuspend) [yank555.lu & faux123]
Android early_suspend/late_resume PM kernel driver framework has been
deprecated by Google. This new powersuspend PM kernel driver is a replacement
for it.
Conserves battery much better.
Triggered by Screen on/off.
Intelli_plug v3.9 driver [faux123]
Intelligent hotplug cpu driver with eco mode.
KCAL - Advanced color control
Disabled MMC CRC check for extra 30% boost in IO
Reduced debugging = More performance
Simple GPU Algorithm [faux123]
FIOPS, BFQ + stock I/O Schedulers
Filesystems support : NTFS, F2FS
Sysfs implementation for changing vibrator intensity [varunchitre15]
Zswap, Frontswap and znswap [faux123]
Support for kernel-mode NEON [faux123]
Increased charging current to 1.2A
Frandom - Fast Kernel Random Number Generator driver added
Added ARM NEON Crypto functions
Click to expand...
Click to collapse
Download :
Velocity v1.1 <- Mirror
Velocity v1.0 <- Mirror
Camera Fix
Changelog :
v1.1
- Added KCAL - Advanced color control (Thanks to @savoca for his great job) check this thread for more info
- Numerous fixes from android kernel_common 3.10 and 3.10.y repos.
- Enabled Conservative governor
v1.0
- Initial release
Installation :
1. Download and save the latest zip to your phone
2. Flash this zip from any custom recovery (eg. TWRP, CWM, Philz)
3. If camera doesn't work, perform steps 1 & 2 for the zip containing camera fix
Recommended Settings :
Min. CPU freq. : 400MHz (Under this might cause SOD)
GPU Governor : simple_ondemand
I/O Scheduler : FIOPS
Read-ahead size : 1536 kB
Intelliplug profiles :
* For general use : Eco Performance/Eco Conservative
* For gaming : Balanced/Disabled
Kernel apps : FauxClock, Kernel Adiutor, Trickster MOD
Credits :
@varun.chitre15
@faux123
@Christopher83
XDA:DevDB Information
Velocity Kernel, Kernel for the YU Yureka
Contributors
neomanu
Source Code: https://github.com/neomanu/android_kernel_yu_msm8916/tree/cm-11.0_exp
Kernel Special Features:
Version Information
Status: Stable
Current Stable Version: v1.1
Stable Release Date: 2015-03-11
Created 2015-03-07
Last Updated 2015-03-11

Reserved

ooo new kernel...
hello bro first of all thanks for contributions towards Development of yu yureka..
Now downloading...
FEEDBACK AFTER SOME HOURS OF PLAYING....

Hey, can I flash it directly on other custom kernel

screen shots??

ankurvvvv said:
screen shots??
Click to expand...
Click to collapse
Its a kernel not a rom. What do you need screenshots of?

My bad. too excited with my new Yureka that not paying attention to anything

flashed this kernel and used it for 5 hrs.
Good BATTERY command.
i attended a con-call for 90 plus minutes and battery drained only 5%
No lag while using basic games like clash of clan or clash of lords
Issues identified
screen black out while on call, you cant control your calls like add new call or check text while you are on phone calls. but no issue in voice and reception.
while making call you cant drop call as screen goes black out.
No heating issue as far i observed.
colour reproduction is good.
seems need little fine tune can make this kernel a must install.
All the very best to develops
Regards

question
MIUI custom ROM supported???

sunilnair007 said:
flashed this kernel and used it for 5 hrs.
Good BATTERY command.
i attended a con-call for 90 plus minutes and battery drained only 5%
No lag while using basic games like clash of clan or clash of lords
Issues identified
screen black out while on call, you cant control your calls like add new call or check text while you are on phone calls. but no issue in voice and reception.
while making call you cant drop call as screen goes black out.
No heating issue as far i observed.
colour reproduction is good.
seems need little fine tune can make this kernel a must install.
All the very best to develops
Regards
Click to expand...
Click to collapse
you are talking about proximity sensor issue , is it right?
Sent from my AO5510 using XDA Free mobile app

Review after using a whole day.
1. First & best intelli_plug driver - loved the live and smooth activation and deactivation of cores acc to load. only single core runs while using light apps (whatsapp,hike,tapatalk etc) i.e. full utilization of a single core.
2. Highly customizable using the FauxClock pro app.
3. cpu temp was usually higher (50-60 degrees) than my last kernel (Tz).
4. As @sunilnair007 posted the screen goes black while call. But one thing i noticed was when i press just at the side of proxi sensor the screen wakes up Exactly same as the Yureka proximity issue but on all other kernels the proxi was working fine on my phone (stock, thunderzap)...
5. i didn't used the phone for an hour or so i.e. phone was in deep sleep the i tried to wake up the device by the power button several times but finally had to remove battery and put again and booted the device :c
and after turning on the battery was 12% (earlier it was above 75%) and it was increasing by itself >.> battery usage graph ss --- i.imgur.com/y9QCyCz.png
and after keeping it turned off for sometime and restarting the battery got stable at 46% and started decreasing as per usage. (so got much less battery backup)

How to make best use of it.
Installed this kernel.
However, it seems very complex to make best use of it by a person like me who is not used to Custom Kernels. Before this I have used ThunderZap2, and Xcelerate, without much of tweaking. In Xcelerate for example, I found that different cores where shutting down by default. Here all the core are working by default. Obviously with this Kernel it seems I will have to do some tweaking.
I have also installed Kernel Adiutor as recommended in OP. However, information on recommended setting is too sketchy.
Would like to more detailed information as how to tweak / set this kernel to make best use of it.

tons of thanks to you bro... for kcal addition
Bro thanks a lot for adding kcal colour management to YU yureka..
Very nice bro..
One thing bro the hotplug is only working with 4 cpu of first cluster only...
I'm using kernel audiutor beta...
And please rommended any setting to run it cooller because comparing to other custom kernel it run little high temp..
Otherwise working grate.....

[KERNEL][3.10.71][KCAL] Velocity v1.1
Seems developer worked hard and results are visible.
No complaints so far testing since morning.
Need 2 days time to give a stable review.
Best wishes and please keep this spirit intact
Regards

Tarry! said:
5. i didn't used the phone for an hour or so i.e. phone was in deep sleep the i tried to wake up the device by the power button several times but finally had to remove battery and put again and booted the device :c
Click to expand...
Click to collapse
Noticed this too. Pressing the volume buttons once/twice, when it is unresponsive, wakes it right back up.
esukhdev said:
Here all the core are working by default. Obviously with this Kernel it seems I will have to do some tweaking.
I have also installed Kernel Adiutor as recommended in OP. However, information on recommended setting is too sketchy.
Would like to more detailed information as how to tweak / set this kernel to make best use of it.
Click to expand...
Click to collapse
Firstly, I'll try to simplify the recommended settings.
Secondly, hotplugging is not enabled by default.
Enable it by going to CPU Hotplug in Kernel Adiutor and enabling Intelliplug.
DGEEEK said:
One thing bro the hotplug is only working with 4 cpu of first cluster only...
I'm using kernel audiutor beta...
And please rommended any setting to run it cooller because comparing to other custom kernel it run little high temp..
Otherwise working grate.....
Click to expand...
Click to collapse
Set the Intelliplug profile to Eco Conservative/Eco Performance to hotplug upto 7 cores.
I'm looking into the cluster problem as mentioned.
To run cooler, try reducing the max frequency.

Tarry! said:
1. First & best intelli_plug driver - loved the live and smooth activation and deactivation of cores acc to load. only single core runs while using light apps (whatsapp,hike,tapatalk etc) i.e. full utilization of a single core.
2. Highly customizable using the FauxClock pro app.
3. cpu temp was usually higher (50-60 degrees) than my last kernel (Tz).
4. As @sunilnair007 posted the screen goes black while call. But one thing i noticed was when i press just at the side of proxi sensor the screen wakes up Exactly same as the Yureka proximity issue but on all other kernels the proxi was working fine on my phone (stock, thunderzap)...
5. i didn't used the phone for an hour or so i.e. phone was in deep sleep the i tried to wake up the device by the power button several times but finally had to remove battery and put again and booted the device :c
and after turning on the battery was 12% (earlier it was above 75%) and it was increasing by itself >.> battery usage graph ss --- i.imgur.com/y9QCyCz.png
and after keeping it turned off for sometime and restarting the battery got stable at 46% and started decreasing as per usage. (so got much less battery backup)
Click to expand...
Click to collapse
Regarding point 5 , I faced same behavior in TZ as well xccelerate kernel.I don't understand the problem.the battery completely drained out and more heat on backside of the mobile.whenever if i would make any changes on IO SCHEDULER or governed faced the issue.
Sent from my AO5510 using XDA Free mobile app

androidgalaxyman said:
Regarding point 5 , I faced same behavior in TZ as well xccelerate kernel.I don't understand the problem.the battery completely drained out and more heat on backside of the mobile.whenever if i would make any changes on IO SCHEDULER or governed faced the issue.
Sent from my AO5510 using XDA Free mobile app
Click to expand...
Click to collapse
The issue is that if you set performance profile to "Power save", gov "ondemand" & min frequency lesser than 500MHz, phone sleeps to death & you have to hard reboot to get back on. Its a known bug and is present in stock kernel too. Check if settings i stated are the reason for you. Doesn't happen with "Interactive" because it never scales lower.
Sent from my AO5510 using XDA Free mobile app

@neomanu , Do I need to wipe cache and dalvik cache while flashing this kernel over any ROM. Also I have flashed a custom kernel previously and now I want to flash this, so Should I simply follow your instructions or need to wipe something.

No Need to wipe anything. To give u extra boost you can wipe dalvik cache which will rebuild cache again and its always good. no need of cache or data wipe

Is this kernel support's volte?
Sent from my AO5510 using XDA-Developers Legacy app

Interactive governor highly efficient profile for SmartPack Kernel - Android N/O/P

Hello all.
After about a month of researching and testing with the Galaxy S5, I'm finally happy with my SmartKernel profile, with the interactive governor carefully tuned, using known resources and countless trials and errors, as well as other various tweaks, like VM and I/O scheduler, and decided to publish on it's own thread.
The main resources I've used for the Interactive governor tuning includes the well known:
Android Modders Guide;
[GUIDE] Advanced Interactive Governor Tweaks; Buttery smooth and insane battery life! for Nexus 5X; and it's twin
[GUIDE] Advanced Interactive Governor Tweaks; Buttery smooth and insane battery life! for HTC Evo 4G.
First of all, this tweaks should be a little sensible to the ROM, kernel, apps, and other tweaks your using. Like, I just found out that Havoc pie style quicktile settings use way more juice then if I turn it off and go back to Oreo default. Bellow you will see the apps I mainly crafted this profile in mind.
For reference: I have a klte with latest Oreo Havoc installed, nano OpenGapps, Magisk and the SmartPack kernel. For apps I use Facebook lite, cause the normal app is just a big hog, whatsapp and instagram social apps. Chrome. I don't use the Google App or Greenify(uninstall/delete velvet). And play lots of games like Clash Royale, Star Wars Force Arena and Arena of Valor. BetterBatteryStats.
And a lot of random apps that normally don't stay on the background.
DESCRIPTION
On the SmartPack manager profile:
. HIghly Efficient Interactive Governor Tunables (most important part);
. No Touchboost or any other boost, only the governor dictates to CPU in which clock it should to be;
. Overclock disabled, but can be enabled at you will;
. No underclock, I do undervolt my CPU but this you need to find your specific device numbers, mine won't cut;
. LazyPlug Hotplug with all 4 cores on all the time (better performance while using and battery savings while at idle);
. I/O Schedulers: ZEN (the L-Speed profile complement this part, with it's scheduler tunables);
. READ-AHEAD internal 1024kb (for 16GB or more) and external 512 kb (for my 8GB SDCard, adjust accordingly to yours SD Card size conform described here
. Adreno Idler disabled: it doesn't make any effect;
. Speaker Driver Leakage disabled and Boeffla Sound enabled with 0 gain as it does make a difference, at least with ViperFX magisk module installed;
. Screen minimum RGB set to 1 (0 won't stick), for a darker dark on our AMOLED, plus some tweaks;
. Led blinking fade enable;
. VM tweaks: dirty_ratio 30 and dirty_background_ratio 15; for minor battery improvement, with a perceptible lower termperature/cpu usage and almost imperceptible performance hit;
. VM tweaks: page-cluster 1; for better multitasking/memory management
. VM tweaks: oom_dump_tasks 0; disable depuration of dumping tasks, less cpu needed.
. LMK values: 32 48 64 128 176 208 (MBs)
L-Speed Profile
. Logging and I/O stats disabled;
. Animations speed set to 0.25x;
. System battery save trigger at 20%;
If you need to provide or read logs, enable logging and i/o stats back on l speed; i/o stats and oom_dump_tasks 1 on smartpack manager
INSTALLATION
Unzip the attached file and import with SmartPack Manager:
The attached profile should be imported, applied and marked as to run "On Boot" to make effect. It will only work with SmartPack Manager and Kernels for both Nougat and Oreo, maybe even Pie. Just try it, and report back. If you wanna fine tune it. You need to use an app or enable the "show cpu clocks" option if your rom supports it (like Havoc, RR and many more), and monitor at which frequencies the lags happens, while doing the jobs you want the CPU to be efficient at. And mainly tweak the target_load according, maybe above_high_speed delays of 1,7GHz clock and above. You need to read the guides more in-dept too see exactly how to do it, but I'll paste here the most important parts on how to tweak this settings more to your Galaxy S5, with your particularly apps and ROM:
soniCron said:
Optimize Idle Frequency
Now that you've got the base configuration, we need to tweak it so that the CPU stays at your efficient idle frequency (384Mhz in this case) without spontaneously jumping when your phone is actually idle. To do this, open a CPU monitor that displays the current core frequencies (I like CoolTool, but you can use what you like as long as it doesn't significantly impact the CPU use--you're best off using a passive monitor and checking the results after 30-60 seconds of no activity), watch the frequencies and see how often they go above your efficient idle frequency when you're not doing anything at all, and adjust the following:
timer_rate - If your idle frequency is not being exceeded much, adjust this downward in increments of 5000 until it is, then increase it by 5000. If your idle frequency is being exceeded often, adjust this upward in increments of 5000 until your CPU primarily stays at or below your desired idle frequency.
above_highspeed_delay - Only if your timer_rate has matched or exceeded 50000 and still won't stay at or below your desired idle frequency most of the time, set timer_rate to 50000 and adjust the "20000" portion of the value upwards in increments of 5000 until the idle frequency has stabilized.
The lower these two values are, the more snappy/lag free your system will be. So try to get them as low as possible without the idle frequency being exceeded too much, as this inversely affects the snappiness and efficiency of your phone when you're not doing anything. Lower = snappier but uses more CPU when you're not doing anything (such as reading a webpage); higher = less snappy but stays in a power saving state more often reducing CPU use when you're not interacting with the device. These are the most critical in determining your idle power savings, so keep that in mind if you want the most battery life!
Enhance Task Responsiveness
Now use the efficiency and nominal clock rate correlations you made for your master clock rate list in the section above and adjust your frequencies to suit your usage patterns. For example, I had web page scrolling as my 710Mhz/864Mhz rates, so I will open a web page and scroll and see how everything feels. If it feels sluggish, I will increase all the references to "710000" in both above_highspeed_delay and target_loads upwards to the next available clock rate until that task is smooth. What you are looking for is constant poor/sluggish performance when the task you're testing for is using its highest CPU use. If the task becomes sluggish/stuttery as it winds down (such as a scrolling webpage slowing to a stop), we will address that next, so do not take that behavior into consideration as you adjust these values! If the task is smooth until (or after) it slows down, then you have reached your optimal clock rate and can move on.
If you need to exceed your nominal clock rate for a particular task, first measure it again just to be sure you had it correct. If you did indeed have it correct, leave it at your nominal clock rate and adjust the value after the colon next to the task frequency you're tuning downward in increments of 5. For example, if my setting of "864000:80" is still not sufficient, I will adjust it first to "864000:75", then "864000:70", and so on until the task is smooth. However, it almost certainly won't come to this, but if you reach ":50" and the task still isn't performing how you want, set it back to ":80" and increase the clock step once more, then decrease the ":80" until it is smooth.
Do the same for each other frequency in your master clock rate list until you are satisfied. If you have chosen to use more than 2 primary clock rates, add them and use ":##" values between the two surrounding frequency values.
Fix Stuttering
Now that you have adjusted your frequencies for optimal high CPU use in each given task, you may notice some stuttering as the task winds down. (Such as a scrolling webpage slowing to a stop.) If this bothers you, you can tweak this at the expense of some (minor) battery life by adjusting min_sample_time up in increments of 5000 until you are satisfied.
If you have exceeded a value of 100000 for the min_sample_time setting and still are not satisfied, change it back to 40000 and increase (and re-optimize) your idle frequency by one step. This will impact battery life more, but less than if you were to keep increasing the value of min_sample_time.
Adjust High Load Clock Rates
You're almost done! Now you can leave everything as is and be satisfied with your amazing, buttery smooth, snappy experience, or you can optionally tweak things further to either increase the responsiveness of high load tasks (such as loading image previews in Gallery) or increase battery life somewhat.
Adjust the final delay value in above_highspeed_delay to suit your needs. The default ("150000") means that the CPU load at the highest set frequency (default "1026000") will have to be sustained for 150ms before it allows the load to go above that frequency. Increasing this value will prevent the CPU from reaching higher frequencies (which may be unnecessary) as often, saving battery life. This will come at the expense of burst-type high CPU load tasks. Reducing it will allow the CPU to reach higher frequencies more often, at the expense of battery life. However, adjusting this is probably unnecessary, as it will most likely not yield any perceptible difference in performance. It is recommended to leave this value at its default.
Click to expand...
Click to collapse
Besides CPU Voltage and Battery, all tabs on the manager are modified and tuned to achieve best performance, while having best efficiency possible. Is not a battery or a performance, but a efficiency profile.
Refer to this thread if you wanna undervolt your device with a well know secure margin for the CPU Snapdragon 801 2.5ghz MSM8974AC, which our Galaxy S5 contains:
[GUIDE] Snapdragon 805/801/800/600 Clock & Voltage (PVS bin) guide by HD2Owner I've managed to achieve much lower voltages then PSV15+ devices (refer to the sheets).
I also attached the excel spreadsheet I've made with all this thread information, both governor guide equations on target loads, undervolting guide findings, and made my own base calculations and settings. Feel free to use, modify, and discuss it with me. You will see that I based the most efficient clocks in an original thought about which ones are the most efficient, instead of plotting the differentials between voltages of each clocks, I did plotted the difference of the clock divided by voltage, which on itself should be how much voltage 1 mhz uses, on each clock rate. So, the higher the number, more speed each clock rate give us by voltage used. It's kinda complicated and idk if I explained it the right way, and even if it really makes sense under scrutiny, but I couldn't think why not myself, so, any inputs are welcome.
I own my thanks to all the following XDA fellows, without them, I could not have achieved this:
@sunilpaulmathew for the SmartPack Kernel which is the only kernel for the S5 that can turn that damned MPDecision off and SmartPack Manager;
@soniCron for both of the governos Guides;
@Saber for the Android Modders Guide which is immensely helpful.
CHANGELOGS
L-Speed Profile (download the app on PlayStore):
011118 lspeed profile
- first release
031118 lspeed profile
- Removed most tweaks, only left minor stuff, refer to the OP.
L Speed profile is not really needed, SmartPack will do 99% of the job.
SmartPack Manger Profile (download the kernel and the app here):
301018
- first release.
011118 smartpack profile:
- A few Interactive governor tweaks;
- Removed Virtual Memory and LMK tweaks, let it on default or use L-Speed to optimize, as it does a much better job then me.
031118 smartpack profile:
- Governor tunning: better high load management;
- Included back only 3 sane VM configurations, no more freezing, better cooling (less cpu needed, while performance barely took a hit)
- Sane LMK configurations, kills apps not being used faster, retain some multitasking while not let it slow down the device
081118 smartpack profile:
- target_load (no changes up to 1497600) ...1728000:89 1958400:91 2265600:95 -> ...1728000:88 1958400:90 2265600:95
- above_hispeed 20000 1190400:60000 1497600:64000 1728000:77000 1958400:84000 2265600:130000 -> 20000 1190400:60000 1728000:68000 1958400:79000 2265600:110000
- external storage read-ahead from 512 -> 2048 (because I've gone from a 8GB to a 32 GB SDCard, ADJUST YOURS ACCORDINGLY TO https://androidmodguide.blogspot.com/p/io-schedulers.html)
- cleaned unused and already default values from profile
101118 smartpack profile:
- Turned Alucard off, accidentally activated it with Lazyplug also enabled, not good!
- Managed to go 1 point higher on freq 1497 MHz, the 2 hotplugs enabled were messing with me trying to test this change before, also 1 point lower on the idle freq 268 MHz for smoother scrolling while still staying at freq 268 while idle. And some more high load optimizations now that I only got 1 hotplug enabled as it should always be.
- target_loads from 268800:29 ... 1497600:86 1574400:5 1728000:88 1958400:90 2265600:95 to -> 268800:28 ... 1497600:87 1574400:5 1728000:89 1958400:91 2265600:94
- above_hispeed 20000 1190400:60000 1728000:68000 1958400:79000 2265600:110000 -> 20000 1190400:60000 1728000:74000 1958400:82000 2265600:120000
- dirty_background_ratio 15 -> 10
221118 smartpack profile:
. Reverted new SmartPack Kernel v14r4 changes to Virtual Memory back to original default configurations, if you've have had reboots this should fix it, please report back here and/or the kernel's thread;
. More changes to Interactive governor aiming to optimize high load scenarios according to the profile philosophy:
. above_hispeed_delay 20000 1190400:60000 1728000:74000 1958400:82000 2265600:120000 -> 20000 1190400:60000 1728000:74000 1958400:80000 2265600:105000;
. Enabled fast charge configurations, set at 1200 mhA as I found it's a good charging speed without heating the phone too much on my hot city, nothing you can't change at your will.
241218 smartpack profile:
. Restored missing min_sample_time tunable since 081018 profile
. dirty_ratio 30 -> 25
. General cleanup
. Tested on Pie

@justjr
Nice work friend. Great to see that your finally open a place to share your findings. In my opinion, your profile should work on any klte device with minimum kernel support. I haven't seen much SmartPack specific stuff in your profile except some hotplug related things. So, if you make it as a shell script instead of KA/SP-Kernel Manager profile, it shall be beneficial for everyone. Anyway, as usual, I'll kang your changes to my kernel default profile

sunilpaulmathew said:
@justjr
Nice work friend. Great to see that your finally open a place to share your findings. In my opinion, your profile should work on any klte device with minimum kernel support. I haven't seen much SmartPack specific stuff in your profile except some hotplug related things. So, if you make it as a shell script instead of KA/SP-Kernel Manager profile, it shall be beneficial for everyone. Anyway, as usual, I'll kang your changes to my kernel default profile
Click to expand...
Click to collapse
I think this profile should work on original Kernel Adiutor, or any fork of it, shouldn't it?
It should work on any other kernel if the changes really stick, and uses the same paths, but MPDecision will mess with frequencies all the time. It would still follow the governor tunables anyway, but it will interfere with it and in the end will not gain too much efficiency out of it.
Actually I only state it is for SmartPack specifically because of the fact that is the only one I can disable MPDecision on our device, and because I included all the tweaks other then just governor tweaks.
Actually I'm kinda lazy right now, but I could do a shell script if any demand for it shows up.

justjr said:
I think this profile should work on original Kernel Adiutor, or any fork of it, shouldn't it?
It should work on any other kernel if the changes really stick, and uses the same paths, but MPDecision will mess with frequencies all the time. It would still follow the governor tunables anyway, but it will interfere with it and in the end will not gain too much efficiency out of it.
Actually I only state it is for SmartPack specifically because of the fact that is the only one I can disable MPDecision on our device, and because I included all the tweaks other then just governor tweaks.
Actually I'm kinda lazy right now, but I could do a shell script if any demand for it shows up.
Click to expand...
Click to collapse
Well, official KA (free version) doesn't allow to import profiles (paid feature), but all other mods does.
and yes, it is supposed to work on every klte device as long as the sysfs paths exist. Means it should work on any custom Kernel with lazyplug support (most of the other stuff are actually included in the stock kernel itself). Of course, the default settings provided by the kernel devs might conflict. e.g., as you said, MPDecision, although the line "stop mpdecison" in your profile will disable it. By the way, I'm not the only one who disabled mpdecision and relay on other hotplugs in this klte community

sunilpaulmathew said:
Well, official KA (free version) doesn't allow to import profiles (paid feature), but all other mods does.
and yes, it is supposed to work on every klte device as long as the sysfs paths exist. Means it should work on any custom Kernel with lazyplug support (most of the other stuff are actually included in the stock kernel itself). Of course, the default settings provided by the kernel devs might conflict. e.g., as you said, MPDecision, although the line "stop mpdecison" in your profile will disable it. By the way, I'm not the only one who disabled mpdecision and relay on other hotplugs in this klte community
Click to expand...
Click to collapse
Oh, really? Which one? I must had missed it. I've tested all kernels I could find. At least all the remotely up-to-date, like venom, tuned and boeffla kernels. I didn't see any option to change hotplugs on any. There were hotplug profiles, to keep cores online and stuff, but everyone of them keep changing min and max frequency at MPDecision will.

justjr said:
Oh, really? Which one? I must had missed it. I've tested all kernels I could find. At least all the remotely up-to-date, like venom, tuned and boeffla kernels. I didn't see any option to change hotplugs on any. There were hotplug profiles, to keep cores online and stuff, but everyone of them keep changing min and max frequency at MPDecision will.
Click to expand...
Click to collapse
Boeffla and Venom largely depends on MPDecision. However, as I remember correctly (on the basis of the code review, not from my experience, I never used it by myself), the Tuned kernel by @fbs disabled MPDecision upon booting to work well with its own Tuned hotplug.

sunilpaulmathew said:
Boeffla and Venom largely depends on MPDecision. However, as I remember correctly (on the basis of the code review, not from my experience, I never used it by myself), the Tuned kernel by @fbs disabled MPDecision upon booting to work well with its own Tuned hotplug.
Click to expand...
Click to collapse
I tested it too. And although he claims he uses hes own hotplug, it behave the same as boeffla and venom, it has the same profiles, and it does changes min and max freq out of my control.

justjr said:
I tested it too. And although he claims he uses hes own hotplug, it behave the same as boeffla and venom, it has the same profiles, and it does changes min and max freq out of my control.
Click to expand...
Click to collapse
no it doesn't change any freqs
it works by disabling or enabling cores, just that.
if any cpu reaches the maximum frequency, it enables one more core (as the other ones are already giving their best)
if any cpu reaches the minimum frequency too many times, it disables it (as it doesn't seem to be needed)
so in any moment you can have all 4 cores enabled or only 1. even with display on or off, it doesn't matter
mpdecision will NEVER let you use just 1 core, and it doesn't react as fast: battery hog

fbs said:
no it doesn't change any freqs
it works by disabling or enabling cores, just that.
if any cpu reaches the maximum frequency, it enables one more core (as the other ones are already giving their best)
if any cpu reaches the minimum frequency too many times, it disables it (as it doesn't seem to be needed)
so in any moment you can have all 4 cores enabled or only 1. even with display on or off, it doesn't matter
mpdecision will NEVER let you use just 1 core, and it doesn't react as fast: battery hog
Click to expand...
Click to collapse
Alright, sorry then, it seems my memories got clouded or something, as I've tested it about a month ago. I might go back any day just to test that. Thanks for giving us one more kernel option! :good:

UPDATE OP WITH
Description
Changelogs
New profile 011118, changelog:
. Few governor tweaks
. Removed Virtual Memory and LMK tweaks, let it on default or use L-Speed to optimize, it does a much better job then me
Also uploading the L-Speed profile I use so those who want to use it like I do, but you can choose any VM and LMK profile that fits your needs on the app. Just don't use the governor tuner because it will mess with my tunings, and l-speed governor tuning is a generic one for all devices, VM and LMK is OK to use generic tweaks, but not on governor.
@sunilpaulmathew I took a look at l-speed virtual memory and lmk profiles and they make incredible sense, take a look yourself, they may be what you need to put o that spectrum profiles, because above all they are device independent and do make a noticeable difference.

Is it valide for stock rom (6.0)?

lollazzo said:
Is it valide for stock rom (6.0)?
Click to expand...
Click to collapse
What kernel? It should work if the kernel have lazyplug or alucard hotplug, if is the late you just have to enable it.

Updates
SmartPack Manager Profile 031118:
. Governor tunning: better high load management;
. Included back only 3 sane VM configurations, no more freezing, better cooling (less cpu needed, while performance barely took a hit)
. Sane LMK configurations, kills apps not being used faster, retain some multitasking while not let it slow down the device
LSpeed Profile 031118:
. Removed most tweaks, only left minor stuff, refer to the OP.
L Speed profile is not really needed, SmartPack will do 99% of the job.
OP: descriptions for both profiles updated.

New profile.
I returned to Nougat, RR 5.8.5, same configs works awesomely and the device is cooler/faster then with Oreo. But still will works the same with both N/O and even Pie, not tested.
I also reinstalled Hearthstone as a high load app so I could tune the governor better for it, and up to 1490 MHz nothing is changed, and changed a bit target_loads and above_hispeed of the clocks above it so Hearthstone (and any other high load apps, or, using split screen with youtube) runs smoother/without lags and tasks like opening an app will finish faster, and also go back to a lower clock faster because of that. So, in the end it stays most of the time at lower clocks anyway, only difference is that it will jump faster when needed for less waiting time/lag.
Just to clarify, this is not suppose to waste battery, or drain it faster. As an efficiency profile the goal is to do the job you the want faster the possible, ramping up to the clocks that the jobs demands, without lags (or minimal lags) and go back to idle/lower clocks as soon as high clocks aren't needed anymore, so it don't overstay at a higher clocks then it's needed, very simple.
So, going to a high clock doesn't mean less battery life, finishing a job fast and going back to idle is the key to achieve more battery life, specially during deep sleep, when you really want your device go back to deep sleep fast, but also at any other time. Watching youtube, browsing and using low demand apps still uses the same clocks.
Also, on top of that you will spend more time USING the device instead of WAITING for it to finish a job. Battery life is very subjective, and SoT doesn't mean nothing IRL, I mean, are you spend that SoT waiting for a job to finish or to actually use the device?
081118 smartpack profile:
- target_load (no changes up to 1497600) ...1728000:89 1958400:91 2265600:95 -> ...1728000:88 1958400:90 2265600:95
- above_hispeed 20000 1190400:60000 1497600:64000 1728000:77000 1958400:84000 2265600:130000 -> 20000 1190400:60000 1728000:68000 1958400:79000 2265600:110000
- external storage read-ahead from 512 -> 2048 (because I've gone from a 8GB to a 32 GB SDCard, ADJUST YOURS ACCORDINGLY TO https://androidmodguide.blogspot.com/p/io-schedulers.html)
- cleaned unused and already default values from profile
File attached on OP.

I don't use SD card so what do I do?

razor17 said:
I don't use SD card so what do I do?
Click to expand...
Click to collapse
In that case nothing is needed, the configurations related to the absent sd card will not be applied.

Ok guys. I was wondering why my device was heating a lot more these last 2 days. Turns out both Alucard and Lazyplug were accidentally activated on 081119 profile. Turn one of them off and everything will be a lot better. Sorry for that. I will upload a new profile very soon.
edit:
101118 smartpack profile:
- Turned Alucard off, accidentally activated it with Lazyplug also enabled, not good!
- Managed to go 1 point higher on freq 1497 MHz, the 2 hotplugs enabled were messing with me trying to test this change before, also 1 point lower on the idle freq 268 MHz for smoother scrolling while still staying at freq 268 while idle. And some more high load optimizations now that I only got 1 hotplug enabled as it should always be.
- target_loads from 268800:29 ... 1497600:86 1574400:5 1728000:88 1958400:90 2265600:95 to -> 268800:28 ... 1497600:87 1574400:5 1728000:89 1958400:91 2265600:94
- above_hispeed 20000 1190400:60000 1728000:68000 1958400:79000 2265600:110000 -> 20000 1190400:60000 1728000:74000 1958400:82000 2265600:120000
- dirty_background_ratio 15 -> 10

I will give this a try. Hope it works well...

Yeah.
You know, try it and report back. I don't see any reports, so I assume is working well for people.
Any reports are welcome.
lentm said:
I will give this a try. Hope it works well...
Click to expand...
Click to collapse
Enviado de meu SM-G900M usando o Tapatalk

justjr said:
Yeah.
You know, try it and report back. I don't see any reports, so I assume is working well for people.
Any reports are welcome.
Enviado de meu SM-G900M usando o Tapatalk
Click to expand...
Click to collapse
No problems so far...greats for daily use..scrolling smoother than default..but pubg still laggy on lower res...may i know which rom are u using?

Smooth working zenwatch3 with custom settings on kernel auditor but gps dont work

Hey guys recently i did a battery swap on my zenwatch with a true 400 mah(some modifications required), and finally got my watch to work after a year of being dead.
It now work really well, its responsive and till now i couldn't find any bug.
I did the normal
[ROM]ASUS-ZenWatch-3-WI503Q- Swift [6 DEC-2017][STOCK-NWD1.170623.001]
procedure and used the following kernel auditor configs
cpu max 1267mhz
cpu min 533mhz
cpu governor darkness
input interval 1500ms
io scaler mode noop
mem cleaner set to agressive but with 72 mb on primary
and on virtual memory i set the z-ram to 600 mb <- this did the most for the performance.
If someone wants more detail, please ask.
Even though its working with my smartphone normaly the gps data its not passed to the watch, anyone have a clue?
(yes the permission is allowed in both dispositives)

Can you detail where you got the battery and what modifications you did?