Related
WARNING:THIS METHOD CAN BE DANGEROUS. DONT DO ANYTHING IF YOU DO NOT KNOW WHAT YOU DO.I AM NOT RESPONSIBLE IF YOU TRANSFORM YOUR PHONE INTO A BRICK.
Horse Power 2x eXtreme SuperSonic SR4R
Welcome to HP Development, If you like my work, you can buy me a beer
I dont work for donations but they do help and helped in the past to counter accidential expenses that comming unplanned. And helped me to buy caffeine for my development.
Here are the list of Donators who have donated so far. I'd like to thank everybody including users of HP Kernels for support, without support and contribution it cant reach till here:
Names of Donators who donated since development of HP Kernels:
-SuperSkill (multi time donator, greatest contributors of development)
-Striatrum_bdr (My neuro protective donator)
-yann73(Multi Time Donators)
-Carburano( Thanks my friend)
-Civato(Thanks my friend)
-wapz
-Basil 123
-Steieve
-psonic2k
-PhunKee
-zerocoolrider
-fuxman
-skylight
-shreeprajay
-patiiet
-Omar Cornejo Sanchez
-abwyatt,-
-tablighs
-Rehborn-
-Jonas Andrulis
-Chris Daßler
- Bert van Hoesel
-Miguel Angel Mulero Martinez
-DARIO FRANZONI,
-Antonello Picerno
-sorry if i've forgot anybody's name please remind me if i've
HP Pro SuperSonic SR4
Changelogs(Kernel Specific)
-too long list of changelogs
-Included all changes since SS1 to SS21
-HP Pro RT Scheduler removed temporarily for stability issue
-Compiled with HP Pro SuperSonic ToolChain for maxium Performance, snappiness and fluidity
Compiled with HP Pro SuperSonic ToolChain.
HP Pro SuperSonic ToolChain Features: (Based on GCC Linaro Sources)[/U][/B]
(-) Tegra specific optimization
(-) Toolchain Target flags has been optimized in same manner as the kernel drivers are written
(-) "Optimizing as the way program is written". I have overy observed all the codes by , as they're written and used same appropriate optimizations
(-) By observing codes 1st thing that comes in mind is Structures & Unions. Used Target Optimizations for it: '-fpack-struct and mstructure-size-boundary=32' for proper alignments of Structures and Unions for faster access
(-) fivopts for variable strength optimizations
(-) fforce-mem with fomit-frame-pointer for faster pointer access
(-) Except tegra codes most of the kernel codes have inlined functions. All functions inlined for faster access of codes. By inlining functions it can be accessed as fast as macro
(-) Code assembly and linking with ArmV7-A architecture's Cortex-A9 cpu's Virtulizations, Integer Division Float and Multi-Processing CPU Extensions
(-) CortexA9 Processor has support for Array Prefetching same like windows does SW based Prefetch. This CPU features during runtime loads longer arrays in advance in CPU memory via AX/BX registers. Which can significantly improve runtime execution and overall snappiness. Target toolchain optimized with array-prefetch optimizations to compile codes with array pre-fetch instructions
(-) By observing Tegra and LG drivers, there are very few short loops, which needs no optimizations, thus graphite loop optimizations disabled.
(-) LTO( Link Time Optimizations) for removal of unused codes during linking stage and re-sections of functions and data for faster access
(-) As armv7-a architecture supports Unaligned Access, instead of disabling, its optimized with 8K access
(-) This is the same toolchain that has been used since 5 months to speedup SuperSonic Test builds for Stock Kernel. No extra blind optimizations used for issue of stability but only as drivers and kernel codes are written "Target specific optimizations" for maxium possible performance
(-) toolchain: Complete set of Used CFLAGS_FOR_TARGET: -O0 -finline-functions -fpack-struct=8 -mstructure-size-boundary=32 -fpreferch-loop-arrays -fivopts -fforce-mem -fomit-frame-pointer CFLAGS_FOR_BUILD: -O0 -march=atom -mtune=atom( as my cpu is atom) Cflags:-O0 -finline-functions
Download
OC Version: https://www.dropbox.com/s/1byhged9oqw5a6n/HP_Pro_SuperSonic_SR4R_OC.zip
No-OC Version: https://www.dropbox.com/s/uvnq7fppcsd8z7e/HP_Pro_SuperSonic_SR4R_No-OC.zip
BIG THANKS TO SUPERSKILL & SHREEPRAJAY FOR PROVIDING ALL HP KERNEL MIRRORS WORKING LINK, IF ANYBODY ELSE HAS ALSO MIRRORED PLEASE PM ME THE LINKS
Downlaod HP Krnls(Latest Build is SR3R2/R:
https://www.box.com/s/5995c4bdcf9abb4e375f
Download HP Performance Packs
https://www.box.com/s/d2a5c32bd3cc0e5d174f
An APP To Control On-The-Fly features of RC12, A Big Thanks to Developer Keshav0001, Who without saying Created an application and still progressing, He is New to XDA as needed 10 or more posts:
Downloads:
search in Market "HorsePower 2x OTF Kernel Tweaker"
Horse Power 2x eXtreme 16/24/32BPP RC12-R(RC Release)
This kernel is based on LG V20Q sources. This kernel is competible and should only be flashed with STOCK MCR FROYO and GINGERBREAD. NOT COMPETIBLE WITH CM AND MIUI
Cryptic Changelogs History:
PHP:
Code:
+Fixed core cpu memory leak
+ Fixed group scheduler"s cpu memory leak, no need to restart phone every 100 hours.
+[B][U](SR3R2)[/U][/B] Reverted to original BackLight drivers as request of many users [B][U](SR3R2)[/U][/B]
+[B][U](SR3R2)[/U][/B] Fixed missing codes in PowerSave [B][U](SR3R2)[/U][/B]
+[B][U](SR3R2)[/U][/B] Fixed with NoOC Version without compcache [B][U](SR3R2)[/U][/B]
+[B][U](SR3R)[/U][/B] Fixed missing definition of CPU memory leak. After hours by hours, days by days more smoothness w/o slow down due to memory leak [B][U](SR3R)[/U][/B]
+[B][U](SR3R)[/U][/B] Full SMP support, enhancing Real Time Dual Core Performance for Multi-Tasking And activated PowerSave profile 4,5,6 [B][U](SR3R)[/U][/B]
+[B][U](SR3R)[/U][/B] Full IP Tables supported, by an upgraded IP Tables [B][U](SR3R)[/U][/B]
+[B][U](SR3R)[/U][/B] Included farajep's backlight driver (Thanks to farajep for making source available) [B][U](SR3R)[/U][/B]
+[B][U](SR3R)[/U][/B] Quick responsiveness and smoothness like SR3 [B][U](SR3R)[/U][/B]
+[B][U](SR3R)[/U][/B] Longest battery performance [B][U](SR3R)[/U][/B]
+[B][U](SR3R)[/U][/B] Fixed freeze, no need to apply +mV patch. One version for all devices [B][U](SR3R)[/U][/B]
+[B][U](SR3R)[/U][/B] Fast WiFi browsing [B][U](SR3R)[/U][/B]
+[B][U](SR3R)[/U][/B] More smooth scrolling [B][U](SR3R)[/U][/B]
+[B][U](SR3)[/U][/B] Introducing OTF V2.0 including Strong Vibrator OTF Function and many bug fixes. To activate strong vibrater just set value "1" in /data/spica/strong_vibe and save, Instantly strong vibrator driver will be activated. To enable boot time Strong Vibrator support set value "1" to /data/spicabootcfg/strong_vibe. For +mV versions and BPP patch InstallKernel first than apply patches for that reffer post #2 after this [B][U](SR3)[/U][/B]
+[B][U](SR3)[/U][/B] Fixed EndCall BSOD(Thanks to Vadonka) [B][U](SR3)[/U][/B]
+[B][U](SR3)[/U][/B] Extra responsiveness with Low Latency Realtime Processing [B][U](SR3)[/U][/B]
+[B][U](SR3)[/U][/B] Mega Smooth UI performance and Rock Solid Stability [B][U](SR3)[/U][/B]
+[B][U](SR3)[/U][/B] Longest battery life. 2 versions available one with my modded battery driver and another with DS battery driver(jumpy-funky reading but long battery life) (Thanks to DS available sources) [B][U](SR3)[/U][/B]
+[B][U](RC12-R)[/U][/B] Longest battrery performance on v20q source kernel with RevisedOTF PowerSave functionality [B][U](RC12-R)[/U][/B]
+[B][U](RC12-R)[/U][/B] Mega Smooth UI Smoothness, You'll really be amazed by never seen smoothness [B][U](RC12-R)[/U][/B]
+[B][U](RC12-R)[/U][/B] RockSolid Stability [B][U](RC12-R)[/U][/B]
+[B][U](RC12-R)[/U][/B] Fully Functional Spica Revised OTF Pack, Lesser freeze free re-mastered values for powersave, gentle yet effective, Selected target values for powersave to significantly reduce battery drainage, PowerSave profile 1-6 (tutorial soon to be written) [B][U](RC12-R)[/U][/B]
+[B][U](RC12-R)[/U][/B] Fixed InCall BSOD previously reported with TestBuilds [B][U](RC12-R)[/U][/B]
+[B][U](RC12-R)[/U][/B] By default screen off max freq setted to 503 Mhz as always, You can exclusively play with different values On-The-Fly with RevisedOTF Functionalities for music listenings w/o distortion or for incoming call as per your needs by setting MaxScreenOff CPU freq values of choice by GUI Application (Thanks to Kaunshik001) or by writing values to /data/spica/maxscreenofffreq. No need to reply on pre-set values. [B][U](RC12-R)[/U][/B]
+[B][U](RC12)[/U][/B] On-the-fly Pack, Exported many HW controlled values from static to dynamic at userspace level (Originally I was inspired by the the concept of Xmister)([B]Credits to Xmister[/B])[B][U](RC12)[/U][/B]
+[B][U](RC12)[/U][/B] On-the-fly VDEFREQ/GPUFREQ/MINCPU1ON/MAXCPU1OFF/SUSPEND_CORE_MV/POWERSAVE/NITROS/SCREENOFFMAXFREQ/DDR2_MIN_KHZ/LPDDR2_MIN_KHZ Support. No need to reboot/restart daemon. It works on kernel syscalls. It takes effect in notime.[B][U](RC12)[/U][/B]
+[B][U](RC12)[/U][/B] On-the-fly [B]VDEFREQ [/B]change support. Responsible file is located in /data/spica/vdefreq & /proc/spica/vdefreq. You can change the value in any of these both files. I preffer user-friendly /data/spica/vdefreq. Edit values with ES file explorer and just save file. No need to change permissions. It takes effect instantly. Default value is 600000. Supported Values in between 600000-700000. Any values above 600000 will OC it w/o increasing supplying voltage. For safety concern no values except in range will be accepted. To enable boot-time support select values in /data/spicabootcfg/vdefreq [B][U](RC12)[/U][/B]
+[B][U](RC12)[/U][/B] On-the-fly [B]GPUFREQ[/B] change support. Responsible file is located in /data/spica/gpufreq & /proc/spica/gpufreq. You can change the value in any of these both files. I preffer user-friendly /data/spica/gpufreq. Edit values with ES file explorer and just save file. No need to change permissions. It takes effect instantly. Default value is 280000. Default value is 300000 Supported Values in between 280000-350000. Any values above 280000 will OC it w/o increasing supplying voltage. For safety concern no values except in range will be accepted.To enable boot-time support select values in /data/spicabootcfg/gpufreq [B][U](RC12)[/U][/B]
+[B][U](RC12)[/U][/B] On-the-fly [B]MINCPU1ON[/B] freq change support. Means during upword scaling at what freq 2nd core will be activated. Responsible file is located in /data/spica/mincpu1on & /proc/spica/mincpu1on. You can change the value in any of these both files. I preffer user-friendly /data/spica/mincpu1on. Edit values with ES file explorer and just save file. No need to change permissions. It takes effect instantly. Default value is what you see after boot. Supported Values in between 216000-1100000. Default value of spica kernel is 810000 For safety concern no values except in range will be accepted.To enable boot-time support select values in /data/spicabootcfg/mincpu1on [B][U](RC12)[/U][/B]
+[B][U](RC12)[/U][/B] On-the-fly [B]MAXCPU1OFF[/B] freq change support. Means at what max freq 2nd core will be off during returning phaze. Responsible file is located in /data/spica/maxcpu1off & /proc/spica/maxcpu1off. You can change the value in any of these both files. I preffer user-friendly /data/spica/maxcpu1off. Edit values with ES file explorer and just save file. No need to change permissions. It takes effect instantly. Default value is what you see after boot. Supported Values in between 216000-1100000. Default value of spica kernel is 860000 For safety concern no values except in range will be accepted.To enable boot-time support select values in /data/spicabootcfg/maxpu1off [B][U](RC12)[/U][/B]
+[B][U](RC12)[/U][/B] On-the-fly [B]MaxScreenOffFreq[/B] support. Means During screen off what will be the max freq.Responsible file is located in /data/spica/screenoff_maxcpufreq & /proc/spica/screenoff_maxcpufreq. You can change the value in any of these both files. I preffer user-friendly /data/spica/maxcpu1off. Edit values with ES file explorer and just save file. No need to change permissions. It takes effect instantly. Default value is what you see after boot. Supported Values in between 216000-999000. For safety concern no values except in range will be accepted.To enable boot-time support select values in /data/spicabootcfg/screenoff_maxcpufreq. [B][U](RC12)[/U][/B]
+[B][U](RC12)[/U][/B] On-the-fly [B]DDR2 MINIMUM FREQUENCY[/B] support. It's theminimum frequency of DDR2(SDRAM).Responsible file is located in /data/spica/ddr2_min_khz & /proc/spica/ddr2_min_khz. You can change the value in any of these both files. I preffer user-friendly /data/spica/ddr2_min_khz. Edit values with ES file explorer and just save file. No need to change permissions. It takes effect instantly. Default value is what you see after boot. Supported Values in between 10000-50000. Default value is 50000 For safety concern no values except in range will be accepted.To enable boot-time support select values in /data/spicabootcfg/ddr2_min_khz. [B][U](RC12)[/U][/B]
+[B][U](RC12)[/U][/B] On-the-fly[B] LPDDR2 MINIMUM FREQUENCY[/B] support. It's theminimum frequency of LPDDR2.Responsible file is located in /data/spica/lpddr2_min_khz & /proc/spica/lpddr2_min_khz. You can change the value in any of these both files. I preffer user-friendly /data/spica/lpddr2_min_khz. Edit values with ES file explorer and just save file. No need to change permissions. It takes effect instantly. Default value is what you see after boot. Supported Values in between 1000-18000. Default value is 18000 For safety concern no values except in range will be accepted.To enable boot-time support select values in /data/spicabootcfg/lpddr2_min_khz. [B][U](RC12)[/U][/B]
+[B][U](RC12)[/U][/B] On-the-fly [B]SUSPENDED CORE VOLTAGE SUPPLY[/B] support. It's theminimum frequency of CORE VOLTAGE WHEN Core is in suspend state.Responsible file is located in /data/spica/suspend_core_mv & /proc/spica/suspend_core_mv. You can change the value in any of these both files. I preffer user-friendly /data/spica/suspend_core_mv. Edit values with ES file explorer and just save file. No need to change permissions. It takes effect instantly. Default value is what you see after boot. Supported Values in between 600-1000. Default value is 1000 For safety concern no values except in range will be accepted.To enable boot-time support select values in /data/spicabootcfg /suspend_core_mv. [B][U](RC12)[/U][/B]
+[B][U](RC12)[/U][/B] Dynamic On-The-Fly '[B]powersave'[/B] profile. Which accepts value from '0' to '6'. During 'powersave' kernel smartly adjust various thresholds of voltage to lower possible values. "0' value means disable(Defult) "1" light powersave "2" moderate powersave "3" aggressive powersave "4" Profile "1" during screen off "5" Profile "2" during only screen off "6" Profile "3" during screen off only(POWERSAVE doesnt touch UV). Make sure 'nitros' mode disable aka value '0' Responsible file location /data/spica/powersave and boot time file location /data/spicabootcfg/powersave [B][U](RC12)[/U][/B]
+[B][U](RC12)[/U][/B] Dynamic On-The-Fly "[B]Nitros[/B]" -"Performance" mode. It accepts two values, "0" Disable "1"Enable. During "Nitros" Profile Kernel sets max fail-safe values (It doesnt touch OC). File location /data/spica/nitors and boot time file location /data/spicabootcfg.Make sure 'powersave' is disabled aka value '0'[B][U](RC12)[/U][/B]
+[B][U](RC12)[/U][/B] V20Q Sources merged[B][U](RC12)[/U][/B]
+[B][U](RC12)[/U][/B] Slight loud crystal clear volume in headphone[B][U](RC12)[/U][/B]
+[B][U](RC12)[/U][/B] Optimized SCHED_RR & SCHED_FIFO[B][U](RC12)[/U][/B]
+[B][U](RC11-R)[/U][/B] Fixed CpuFreq of 2nd Core not syncing with 1st core's cpufreq. NOW Very quicker 2nd core activation and very quicker 2nd core suspension. Thus fastest realtime resposnses and excellent reduced battery drainage. Standby battery drainage with OC/UV ~1-2mA [B][U](RC11-R)[/U][/B]
+[B][U](RC11-R)[/U][/B] Re-injected Compcache and removed ZRAM [B][U](RC11-R)[/U][/B]
+[B][U](RC11-R)[/U][/B] Modified Deadline Scheduler's FIFO parametrs to 20 instead of 16 for quicker response [B][U](RC-11R)[/U][/B]
+[B][U](RC11)[/U][/B] More snapier, stable and performance oriented [B][U](RC11)[/U][/B]
+[B][U](RC11)[/U][/B] Featuring ZRAM/(Previously known as CompCache) HW Compressed RAM with SWAP_FREE_NOTIFY feature [B][U](RC11)[/U][/B]
+[B][U](RC11)[/U][/B] Fixed freeze issue by re-compiling GCC HardFolat ARM tool chain [B][U](RC11)[/U][/B]
+[B][U](RC11)[/U][/B] OC/UV & VOODOO remerged [B][U](RC11)[/U][/B]
+[B][U](RC10)[/U][/B]Removed LG's lowmemorykiller.c and added same modified by me for assured oom optimal functionality with no possible memory leak[B][U](RC10)[/U][/B]
+[B][U](RC10)[/U][/B]Longest battery performance among all HP KRNLS. Extended battery life[B][U](RC10)[/U][/B]
+[B][U](RC10)[/U][/B]NVMAP enabled to kill processes envoked by GPU to assure GPU mem functionality without allocation of static GPU memory[B][U](RC10)[/U][/B]
+[B][U](RC10)[/U][/B]Enabled Android pMem functionality[B][U](RC10)[/U][/B]
+[B][U](RC10)[/U][/B]Patched tegra framebuffer to allow pseudo color palate support on same x,y axis with >/= 16 bits support[B][U](RC10)[/U][/B]
+[B][U](RC10)[/U][/B]Quicker apps response[B][U](RC10)[/U][/B]
+[B][U](RC10)[/U][/B]Extended most efficious multi-tasking[B][U](RC10)[/U][/B]
+[B][U](RC10)[/U][/B]ARM Hard Float VFP support. Compilation along with ARMHF tool chains[B][U](RC10)[/U][/B]
+[B][U](RC9)[/U][/B] Fully based on Official released V20L sources, Merged all HP kernel changes since beta to RC8 with V20L[B][U](RC9)[/U][/B]
+[B][U](RC9)[/U][/B]More optimized scheduling, Quicker APP response and More smooth UI (Taken from SR3 Test release)[B][U](RC9)[/U][/B]
+[B][U](RC9)[/U][/B]Fixed wifi with dynamic msallocation (Taken from SR3 Test build)[B][U](RC9)[/U][/B]
+[B][U](RC9)[/U][/B]More optimized for power saving (Taken from SR3 Test build)[B][U](RC9)[/U][/B]
+[B][U](RC9)[/U][/B]SMBFS file system support as a module (Taken from SR3 Test build) [B][U](RC9)[/U][/B]
+[B][U](SR2)[/U][/B] Power Saving optimizations [B][U](SR2)[/U][/B]
+[B][U](SR2)[/U][/B] More optimized for smoother responce [B][U](SR2)[/U][/B]
+[B][U](SR2)[/U][/B] Merged changes of RC7 & RC8 without JRCU daemon[B][U](SR2)[/U][/B]
+[B](RC8-Revised)[/B] Fixed EMC core UV issue and Max OCed reverted back to 1408Mhz[B][U](RC8-Revised)[/U][/B]
+[B][U](RC8)[/U][/B] JRCU as daemon support[B][U](RC8)[/U][/B]
+[B][U](RC8)[/U][/B] OCed upto 1.55 Ghz Normal Vibrator Version[B][U](RC8)[/U][/B]
+[B][U](RC8)[/U][/B] More possible optimizations for lesser battery drainage[B][U](RC8)[/U][/B]
+[B][U](RC7)[/U][/B] Watchdog Support added: Tegra ODM Watchdog support as a module[B][U](RC7)[/U][/B]
+[B][U](RC7)[/U][/B] SDRAM related EMC core voltage undervolted to -50mV[B][U](RC7)[/U][/B]
+[B][U](RC7)[/U][/B] More possibly optimized for better possible battery[B][U](RC7)[/U][/B]
+[B][U](RC7)[/U][/B] Max OC frequency back to 1.4Ghz[B][U](RC7)[/U][/B]
+[B][U](SR1)[/U][/B] Strong Vibrator driver, Both version availibility with Strong Vibrator driver and with Default vibrator driver [B][U](SR1)[/U][/B]
+[B][U](SR1)[/U][/B] Best hand-picked stuff from RCs, Default frequencies of CPU towards 1.4Ghz[B][U](SR1)[/U][/B]
+[B][U](SR1)[/U][/B] Assured Stability, Better Performance and energy-saving battery performance[B][U](SR1)[/U][/B]
+[B][U](RC6)[/U][/B] TEMP info fixed[B][U](RC6)[/U][/B]
+[B][U](RC6)[/U][/B]Minor debug clean-ups[B][U](RC6)[/U][/B]
+[B][U](RC6)[/U][/B] In-call volume mute issue in Froyo fixed[B][U](RC6)[/U][/B]
+[B][U](RC5)[/U][/B] OCed upto 1.5Ghz, New freq steps 216,389,655,816,1015,1216,1408,1504[B][U](RC5)[/U][/B]
+[B][U](RC5)[/U][/B] Declaration of NVODM FULL VOLTAGE in mV undefined ,Depends now on FUSE functionality .Low and Critical NVODM voltage in mV selected 9400 & 8800 respectively in NVODM initialization file[B][U](RC5)[/U][/B]
+[B][U](RC5)[/U][/B] All Kernel drivers from SU660 GB sources except power,odm_kit,base,nvos fixed for the competibility and merged[B][U](RC5)[/U][/B]
+[B][U](RC5)[/U][/B] "Anticipatory" I/O scheduler as mainline scheduler[B][U](RC5)[/U][/B]
+[B][U](RC5)[/U][/B] Compiled with GCC-4.6.2 Linaro tool chain with Voku's favourite -Ofast flags. Removed tegra specific flags and added ARM standard graphic optimized flags for cortex-a9. CFLAGS_KERNEL and MODFLAGS: -Ofast -pipe -mcpu=cortex-a9 -mtune=cortex-a9 -mfpu=vfpv3-d16 -mfloat-abi=soft -floop-block -floop-interchange -floop-strip-mine -ffast-math -funsafe-loop-optimizations -funsafe-math-optimizations -fbranch-target-load-optimize2[B][U](RC5)[/U][/B]
+[B][U](RC4)[/U][/B] Dual SPI drivers supporting HSPA+ from su660[B][U](RC4)[/U][/B]
+[B][U](RC4)[/U][/B] Wifi modules fixed for re-loading issue and Quicker connect after several hours (Needs testing)[B][U](RC4)[/U][/B]
+[B][U](RC4)[/U][/B] Regluator & RTC drivers from SU660[B][U](RC4)[/U][/B]
+[B][U](RC4)[/U][/B] Battery driver reverted to modified RC1 driver[B][U](RC4)[/U][/B]
+[B][U](RC3)[/U][/B] Featuring BPP(Bits-Per-Pixel) On-The-Fly Support, select bits in init.d/bpp file and reboot[B][U](RC3)[/U][/B]
+[B][U](RC3)[/U][/B] Modified star_battery_charger.c to allow extra-voltage charge [B][U](RC3)[/U][/B]
+[B][U](RC3)[/U][/B] Some drivers previously merged from SU660 reverted as of no visible improvement , And new NVOS NVDDK CORE drivers merged from SU660[B][U](RC3)[/U][/B]
+[B][U](RC3)[/U][/B]SCHED_FIFO optimizations for quicker SCHED operations [B][U](RC3)[/U][/B]
+[B][U](RC3)[/U][/B]Voodoo and missing batt temp in RC2 fixed with RC3[B][U](RC3)[/U][/B]
+[B][U](RC3) [/U][/B] More optimized SCHED_OTHER & SCHED_RR/FIFO for optimum I/O operation[B][U](RC3)[/U][/B]
+[B][U](RC 2)[/U][/B]NEW released su660's V20D GB kernel sources' WLAN module, MMC, USB, I2C, MTD, SPI, NVRM, NVODM, ODM_KIT, STAR, POWER dirvers fixed for the competibility and merged[B][U](RC 2)[/U][/B]
+[B][U](RC 2)[/U][/B]Ext2 support enabled.[B][U](RC 2)[/U][/B]
+[B][U](RC1)[/U][/B] Fixed pre-mature reboots on Terminal Emulator, USB debugging, Script Manager, Compeitble with Andrev OC Daemon APP, fixed reboot on restart daemon service.[B][U](RC1)[/U][/B]
+[B][U](RC1)[/U][/B] Optimized for Quicker APPs response[B][U](RC1)[/U][/B]
+[B][U](RC1)[/U][/B] 32BPP/24BPP Tegra-FB enabled kernel. For 32BPP, Enabled Virtual A8R8G8B8 32BPP to 24BPP to 18BPP panle color with changed RGB and Transperency OFFSET and LENGTH[B][U](RC1)[/U][/B]
+[B][U](RC1)[/U][/B] Heridant topogigi's vold.fstab in installation zip file, for preventing unmounted SD issue on other ROMs [B][U](RC1)[/U][/B]
+[B][U](RC1)[/U][/B] tocuhscreen fix credits to pastime[B][U](RC1)[/U][/B]
+[B](Beta1.1)[/B] Re-strctured modded battery driver with Beta1. OverHeat suspenstion now supports 410-550 TEMP instead of 450-550. Assured up-to 50% lesser battery drainage. Battery driver now supports scaling through 3360 to 4182 mv instead of 4150mv[B].(Beta1.1)[/B]
+Mega-smooth UI Fluidity/smoothness and higher benchmarks
+Quicker UI and/or APP responsiveness
+Efficient multi-tasking
+OC/UV Codes merged from Cpsjuste Sources([B]Thanks cpsjuste ,impertius sources available[/B])
+Voodoo codes from [B]Supecorio[/B] sources(Thanks)
+Ext4 supported
+Competible with V20 l/j/g/i/c/e/q/p/o/l/m And Froyo MCR
If you appreciate my work than feel free to Support My O2x Development
Recommendation:
-Battery calibration. After calibration let it disachrge full for the first time then full charge. Then you're ready to go! Full discharge needs to be done ONLY ONCE after calibration.
Procedure:
-charge phone full when its off, start phone. Charge till it shows full status. Charge more for 15mins untill you see battery voltage at 4182mv. Then calibrate battery with Battery Calibration App.
HP TB Sources: https://github.com/spica234/HP-TestBuild-Repo-upwords-Sr3R
HP 2x Kernel Sources since RC1 to Sr3R2: https://github.com/spica234/HP-2X-V20Q
HP 2x Deprecated Sources since RC1 to RC11 https://github.com/spica234/HP-Krnl-2.6.32.9
revOTF Patch Attached in the post!
Various Patches
+10mV Patch:
http://www.box.com/s/5vbo951za4x0yyx9jvn8
+15mV Patch:
http://www.box.com/s/ei3elm0d7ey30a2pbfvh
BPP Patch Default 24BPP:
http://www.box.com/s/3ikgfufphfb3bl5x7805
Flashing now! What are the differences from the first beta in Topogigi's thread?
Ah: "And I've released beta1.1 with major battery fix and more UI responsiveness".
Great
wapz said:
Flashing now! What are the differences from the first beta in Topogigi's thread?
Click to expand...
Click to collapse
Knwon issues are persistent. Got not much time for it. But it has been overall optimized for more fluid UI responsiveness and more efficient lesser battery drain. this time modded battery driver lessens battery drains and consumptions more than previous test versions.
Thanks for your work!!!
Just flashed beta 1.1 on Topogigi 1.9, will report if i notis any bugs.
A huge tanks to u and all other devs that has finally made me happy white my hardware.
Sent from my LG-P990 using xda premium
Thanks , something new to play, yeahhh
The kernel version is listed correctly now as well
Yes
wapz said:
The kernel version is listed correctly now as well
Click to expand...
Click to collapse
Sent from my LG-P990 using Tapatalk
beta1 in standby (3G, wifi off) use my battery 1-2mA
very GOOD!!!
that is extremely low, nicee
for most efficient effect you need battery calibration as we ve different battery driver this time
PAIIITET said:
beta1 in standby (3G, wifi off) use my battery 1-2mA
very GOOD!!!
Click to expand...
Click to collapse
Sent from my LG-P990 using Tapatalk
i know this dev from samdroid.net (galaxy spica) and i have to say...he's good
At 22% now, will start full recharge too 100% and wipe stats.
Charge full first during phone is off. Then start phone and charge to 100% full status shown , wait till more 15mins 15 minutes more till you see 4182 mv . Then calibrate battery via battery calibration app.
wapz said:
At 22% now, will start full recharge too 100% and wipe stats.
Click to expand...
Click to collapse
Sent from my LG-P990 using Tapatalk
Hey man nice to c u inhere i miss spica still:/ you got lg 2x?
ker0ltjuh said:
i know this dev from samdroid.net (galaxy spica) and i have to say...he's good
Click to expand...
Click to collapse
Sent from my LG-P990 using Tapatalk
So this kernel reduces battery drain upto 50%? Lets say I do happen to do something wrong, I can always smart flash right?
Does GPS work for you mates, or this is Topo's ROM problem?
downloaded, installed without any problems and now to test the battery, thanks for the work spica
You can restore if youve backed up
Soulj4h said:
So this kernel reduces battery drain upto 50%? Lets say I do happen to do something wrong, I can always smart flash right?
Click to expand...
Click to collapse
Sent from my LG-P990 using Tapatalk
Disable CPU rendering & Enable full GPU rendering
This work only with Adreno200I do some research and found that the device work better if you disable CPU rendering.
Introduction:
The UI of android keeps improving as updates from the android team keep flowing in. There has been a massive improvement in the aesthetics and looks of the system UI from the ancient Eclair till Jelly Bean. With improving UI and better graphics the system keeps becoming an resource hog. All android smartphones these days come with a separate GPU to satisfy the graphics rendering needs of the apps these days. However the GPU doesn’t exactly help in rendering of the system UI that means the load falls of the CPU to render the system UI and other system framework.
so here is a Mod that will disable CPU rendering and enable full GPU rendering,which will let you enjoy the true power of your adreno200!
Improvements:
-Improved performance.
-Blazing speed.
-Better sound quality.
-Improved responsiveness.
-Smoother UI experience.
-Some apps(bloatware) that earlier ran slow like Facebook will turn snappy.
-Free up CPU for other tasks.
requirements:
-Rooted device
-File manager with root permission
-Little brain xd
1) MAKE A NAND BACKUP OF YOUR ROM. Just in case something would go wrong
2) To disable CPU rendering the ONLY things to do are:
- with a file manager with root access go to system/lib/eg
- open the file egl.cfg. DELETE everything inside the file but keep this line: 0 1 adreno200
- Set the permission to rw-r--r-- for the egl.cfg file.
- rename libGLES_android.so to libGLES_android.so.bakfrom egl folder. Don't delete it so if there is an issue with your ROM you can revert back to this file.
- REBOOT
That's all you have to to to disable CPU rendering. Depending on the ROM you are using you'll see some improvements or not (compile the poll on the top of the page)
In addiction to this explanation, disabling CPU rendering reduce battery juice!
This mean that your device will drain some battery.
Set the permission to rw-r--r-- for the egl.cfg file.
What might you benefit from? So far this is what I noticed.
- performance boost
- speed boost
- increased responsiveness
- better audio quality
- apps such as Facebook that would become slow and unresponsive are suddenly blazing fast
let me try this first and see if it will be better... ☺
So this is better than "Force GPU rendering" in Developer options?
ssurell said:
So this is better than "Force GPU rendering" in Developer options?
Click to expand...
Click to collapse
the "opposite" !
this option is to force the rendering to always switch-on this one......and it's highly recomended to definitively disable it .
Paget96 said:
Disable CPU rendering & Enable full GPU rendering
This work only with Adreno200I do some research and found that the device work better if you disable CPU rendering.
Introduction:
The UI of android keeps improving as updates from the android team keep flowing in. There has been a massive improvement in the aesthetics and looks of the system UI from the ancient Eclair till Jelly Bean. With improving UI and better graphics the system keeps becoming an resource hog. All android smartphones these days come with a separate GPU to satisfy the graphics rendering needs of the apps these days. However the GPU doesn’t exactly help in rendering of the system UI that means the load falls of the CPU to render the system UI and other system framework.
so here is a Mod that will disable CPU rendering and enable full GPU rendering,which will let you enjoy the true power of your adreno200!
Improvements:
-Improved performance.
-Blazing speed.
-Better sound quality.
-Improved responsiveness.
-Smoother UI experience.
-Some apps(bloatware) that earlier ran slow like Facebook will turn snappy.
-Free up CPU for other tasks.
requirements:
-Rooted device
-File manager with root permission
-Little brain xd
1) MAKE A NAND BACKUP OF YOUR ROM. Just in case something would go wrong
2) To disable CPU rendering the ONLY things to do are:
- with a file manager with root access go to system/lib/eg
- open the file egl.cfg. DELETE everything inside the file but keep this line: 0 1 adreno200
- Set the permission to rw-r--r-- for the egl.cfg file.
- rename libGLES_android.so to libGLES_android.so.bakfrom egl folder. Don't delete it so if there is an issue with your ROM you can revert back to this file.
- REBOOT
That's all you have to to to disable CPU rendering. Depending on the ROM you are using you'll see some improvements or not (compile the poll on the top of the page)
In addiction to this explanation, disabling CPU rendering reduce battery juice!
This mean that your device will drain some battery.
Set the permission to rw-r--r-- for the egl.cfg file.
What might you benefit from? So far this is what I noticed.
- performance boost
- speed boost
- increased responsiveness
- better audio quality
- apps such as Facebook that would become slow and unresponsive are suddenly blazing fast
Click to expand...
Click to collapse
It affects battery?
Thanks man
Sent from my LG-E610 using XDA Free mobile app
After a lot of testing and hours of hard-work, I have developed a kernel based on the latest sources. As the name of the kernel suggests, the primary focus of the kernel is speed and performance. As a result, I have fine-tuned and optimized this kernel to perform in the best possible manner. However, I haven't missed to look into the Battery issues of the phone. A lot of effort has been made to fix unnecessary consumption of battery along with regulated CPU usage. Further, I have worked really hard to include almost all features and fixes so as to make my kernel the most feature-packed All-in-One solution.
Main Features---
Display---
Support for kCAL Colour Control v2.0 (enhances Colour Vibrance and Intensity). (available as a Screen TAB in Kernel Adiutor).
Up-to-date LiveDisplay Driver.
Support for Colour Enhancement (Updated).
Support for HotPlugs---
MSM (Fast Lane Load)
Mako
AluCard
IntelliPlug
ThunderPlug
AutoSMP (Modified and Enhanced for big.LITTLE architecture by ME )
State Helper v2.0 (Modified and Enhanced for big.LITTLE architecture by ME )
MSM mP-Decision (Bricked)
Support for Governors---
Conservative
Darkness
ElementalX
LionFish
IntelliDemand
Interactive
OnDemand
Performance
PowerSave
SmartMax
Hyper
Wheatley
YankActive
AluCard
Support for I/O Schedulers---
FIOPS
BFQ v7r8 with Hierarchical Scheduling
ROW
NOOP
DeadLine
CFQ
SIO
CPU---
Fixed High-Load Average from UnInterruptible Waits (reduces CPU-Load even more in idle state).
Overclocked CPU upto 1.7GHz (big Cluster) and 1.2GHz (LITTLE Cluster) for Extreme Performance (Modified and Enhanced by ME ).
Proper and Uniform Frequency Table Format with 200MHz Gap between each Frequency
Support for Fast-IDLING of CPU (should reduce Power-Consumption a lot).
Support for Power Efficient WorkQueue to reduce Power-Consumption (available in CPU tab of Kernel Adiutor).
GPU---
Support for ADRENO-IDLER algorithm (saves a lot of Battery by reducing GPU Frequency to minimum when there is less load).
Altered GPU-Frequency Table for more Power-Savings without noticeable decrease in Performance.
Memory---
Support for Swap, FrontSwap, and zSwap techniques (improve performance significantly when zRAM is full).
Support for Memory Compaction (improves performance).
Support for CleanCache Driver (improves I/O performance).
Support for zsmAlloc with Page-Table Mapping techniques (improve memory performance).
Support for zRAM with LZ4 compression algorithm (improves performance by saving memory).
Battery---
Support for ARCH_Power to reduce Power-Consumption and increase Battery-Life.
Support for the new PowerSuspend algorithm (improves Battery-Life).
Support for preventing unnecessary WakeLocks (improves Battery-Life). (available under the Misc. Tab of Kernel Adiutor)
Support for ThunderCharge Current Control Driver v2.1 (accelerates Charging by a large margin).
Optimizations and Tweaks---
Based on the latest sources of CyanogenMod (CM) for Yu Yureka/Yureka PLUS.
Disabled CRC-Check for upto 30% faster I/O.
Support for FRandom RNG Driver (upto 50x faster than the default one).
Compiled with UberTC 4.9.4 Optimized for 64-BIT (Uber uses the latest of every component as well as increases the Battery-Life too).
Support for Touch-Boost and CPU-Boost (Updated).
Support for Vibration Intensity Control (available in Misc. TAB of Kernel Adiutor).
Lowest Possible CPU-Usage (a lot of tweaks have been implemented system-wide).
Support for various Wake-Up Gestures including D2W.
Disabled Debug-Info (should reduce the size of the kernel making it lighter).
Support for HMP Aware and Power-Aware Task Allocation (should improve Performance and Battery-Life).
Support for Faux Sound Control v4.1 (Modified and Enhanced by ME ).
Support for a Custom Thermal Driver with Optimized Core Control v2.0 (Better Heat-Management with Flexible Controls, Modified and Enhanced by ME ).
Support for Load Shifter Mechanism (allows more Power-Savings, built by ME ).
The above mentioned features are just the main ones (many are omitted due to word limit), there are many more small technical changes done to improve the overall experience. By the way, the number written after the # symbol in the "Kernel Version" available in About Phone section, tells the number of times I have compiled the kernel. That number alone is an evidence of the amount of time, hard-work and patience I have applied in developing this kernel.
I have tried my best to make my kernel the most polished one. From minor tweaks to major improvements, everything is perfectly done. Moreover, I'll update my kernel whenever a useful feature or new sources come out so as to make you people experience the best and the latest of everything.
I encourage all the people here to try this kernel and squeeze out every bit of performance from our hot-tempered Yu Yureka/Yureka Plus.
Notes---
1. This kernel performs best when used with ROMs based on the latest sources of CyanogenMod.
2. My kernel doesn't requires any other app except for Kernel Adiutor to control the features. Therefore, you people are free to uninstall any other Kernel-Management app. #NoHassles
3. The *NEW word written after a feature indicates that this feature is NOT present in any other Kernel at the time of release.
4. The words 'Modified and Enhanced' written after any Feature indicate that I, myself, have modified that feature to make it more Efficient for our specific Device.
Installation Instructions---
1. It is recommended to clean-flash the kernel if you face any problems such as LED not blinking, unstable frequencies, etc.
2. To download the kernel, head over to the ChangeLogs and Downloads post and select the version of kernel you want.
3. To install the kernel, just flash the .zip using TWRP recovery.
Credits---
1. Google (for everything related to Android)
2. Cyanogen (for Source Code)
3. Varun Chitre (for ThunderCharge)
4. Savoca (for kCAL Colour Control v2.0)
Changelogs and Download Links---
v14.0---
For Changelog and Download Link, refer here.
Recommended Settings---
Note---
1. Use Kernel Adiutor-MOD to apply settings!
Download Link for Kernel Adiutor-MOD---
https://github.com/yoinx/kernel_adiutor/raw/master/download/app/app-release.apk
2. Always set the Apply on Boot Delay to 20 seconds or more. This is useful to avoid situations in which a certain feature malfunctions everytime after it is enabled at boot and thus results in a bootloop. Setting the delay to a higher value allows to disable that particular feature before it gets enabled.
CPU TAB---
For Balanced Performance---
1. Set Min. to 200MHz and Max. to Max. Available for both Clusters.
2. Interactive/Impulse Governor for both Clusters.
3. Enable Schedule WorkQueues Toggle.
For Battery-Saving and Less Heat---
1. Set Min. to 200MHz and Max. to 1200MHz for big Cluster.
2. Darkness/LionFish Governor for both Clusters.
3. Enable Schedule WorkQueues Toggle.
CPU HotPlugs TAB---
Use AutoSMP if you want more Battery-Life and Decent Performance with Less Heating than Stock Kernel.
State Helper---
1. Max. Core Online (Screen On) at 6 (Useful for Gamers)---
More Battery-Saving and Lesser Heating than Stock Kernel.
2. Max. Core Online (Screen On) at 4 (Useful for Normal Usage)---
Excellent Battery-Saving and Minimal Heating but Lesser Performance than Stock Kernel.
3. Max. Core Online (Screen On) at 2 (Useful for those who don't play Games or do much Browsing)---
Extreme Battery-Saving and Least Heating but much Lower Performance than Stock Kernel.
Thermal TAB---
1. Least Heating Profile---
Enable Core Control.
Temperature Throttle at 45 C.
2. Balanced Heating Profile---
Enable Core Control.
Temperature Throttle at 60 C.
3. Gaming Heating Profile---
Disable Core Control.
Temperature Throttle at 75 C.
Note---
Keep rest of the Thermal Settings at Default Values for all Profiles!
GPU TAB---
Enable Adreno IDLER.
Screen TAB---
Improved Colour Enhancement is in-built in kernel. Still, this is what I use---
LiveDisplay---Night Mode
Minimum RGB Value---32
Saturation Intensity---48
Wake Controls TAB---
As per your own preference.
Sound TAB---
As per your preference.
Battery TAB---
I don't use ThunderCharge as I feel that the stock values provided by YU charge the phone within a decent time. So, again, use as per your preference. However, using Charge Rate beyond 1250mAh may damage the hardware.
I/O Scheduler TAB---
BFQ for both Internal and External Storage.
WakeLocks TAB---
Disable all (to Save Power). However, if you face any problems, then re-enable all.
Misc Controls TAB---
Disable Android Logging.
Init.d TAB---
Enable Emulate Option.
Leave the rest TABs as they are.
Note---
In order to reset settings to default, just Disable the Apply On Boot option of the particular TAB in Kernel Adiutor and reboot the phone.
ENJOY!!!
Reserved.
Shoaib05 said:
Reserved
Click to expand...
Click to collapse
Will this kernel work on stock cm12?????
as currently I'm using Sandy kernel
And getting average battery life and performance ????
gtsfreak said:
Will this kernel work on stock cm12?????
as currently I'm using Sandy kernel
And getting average battery life and performance ????
Click to expand...
Click to collapse
Since the stock CM12 ROM is based on the older sources, I doubt that my kernel will work perfectly. However, you may try and tell me whether it works or not. It would be really helpful.
By the way, which version of Sandy Kernel are you using?
Shoaib05 said:
Since the stock CM12 ROM is based on the older sources, I doubt that my kernel will work perfectly. However, you may try and tell me whether it works or not. It would be really helpful.
By the way, which version of Sandy Kernel are you using?
Click to expand...
Click to collapse
Sandy kernel v1.5
Battery life and performance is average
gtsfreak said:
Sandy kernel v1.5
Battery life and performance is average
Click to expand...
Click to collapse
Try mine if you're unhappy with the results you're getting with your current kernel.
However, I don't think everything will work i.e., LED or Camera but you'll get better performance and Battery-Life, this I can promise.
Support for Android Marshmallow (6.0) has been added!!! Check 2nd post for Download Link!!! (thanks to Hriday Sharma for the commits!)
From now onwards, this thread will not be maintained. Head to Yu Forums to stay updated!!!
Edit---
Thread will be maintained here on XDA too.
Kernel Manager ?
Shoaib many thanks for creating this for us ! God bless you !
Hi Dev Champs !
I am a noob when it comes.to Kernel and Kernel manager. I am a user of Yu Yureka running custom CM13 rom (Created by SantoshM) and im running Velocity 2.0+.
Can you pls suggest the best Kernal Manager in ur opinion. I am using Ex Kernal Manager right now.
Can you also walk me through the steps of setting up the best units for saving battery as well... Of course if thats not a lot of trouble.
download links not working , wanted to check this out with cm13 latest built
Update---
Velocity Kernel v14.0!!!
Changelog---
1. Merged Latest CM's Source Updates into Velocity's Source (contains many improvements).
2. Updated the Linux Base Version to the latest one of 3.10 branch i.e., 3.10.104 (contains BUG-Fixes). *NEW
3. Updated the PowerSuspend Drivers to the latest version i.e., v1.7 (should improve Battery-Life).
4. Added Support for Impulse 2016 Edition Governor (a Balanced Governor for smooth performance and decent Battery-Life). *NEW
5. Added Support for State Notifier Driver (an Optimized mechanism for knowing about Panel's State). *NEW
6. Tuned the LionFish Governor (for better Performance). *NEW
7. Modified the Touch-Boost to be user-controllable (In CM, it is enabled by default and is not user-controllable. This makes the Battery deplete much faster. In my kernel, it is disabled by default and is also user-controllable.). *NEW
8. Improved the Thermal Mechanism (better Heat-Management without much degradation in Performance). *NEW
9. Tuned the Interactive Governor for Efficient operation and more Power-Savings. *NEW
10. Removed Franco's Sound Control (Although, I ported it in the best possible manner, it still wasn't quite upto my standards.).
11. Removed the stock CyanogenMOD Core Control Feature (the current implementation wasn't as Efficient as it should have been in reducing Heat and improving Battery-Life). *NEW
12. Minor BUG-Fixes and Improvements.
Now, the Highlights of v14.0 (unique features which only Velocity Kernel offers for Yu-Devices)---
1. Core Control v2.0---
Built from scratch by me, this version of Core Control is much more efficient than the stock one. In this version, Cores are disabled according to temperature in a much more optimized manner. Further, this Core Control of mine, offers efficient Heat-Management as well as improved Battery-Life. To sum up, this is the best Core-Based Heat-Management Technique for Yu-Devices.
2. Faux Sound Control v4.1---
In this Sound Control, I have used Faux Sound v3.6 as base and on top of it, I have modified, fixed and enhanced the Driver. All of the changes are done by me! I have named this version as v4.1 because I have made 5 changes to the Driver (v3.6 + 5 Changes = v4.1). Coming to the point, this Sound Control is finally the best one. I have worked hours on it to port and fix it in the best way. Thus, now, there is no Low-Volume issue. Further, even the Negative Values work too. Also, the Volumes are boosted without distortion now i.e., higher Volumes can be achieved easily. Also, now, there is a fully functional Enable/Disable Toggle for Sound Control. To bring this feature and make it Compatible with the Modified Kernel Adiutor, I did a very clever workaround too. To sum up, this is indeed the best Sound Control for Yu-Devices with No BUGs.
3. Perfect Core-HotPlug Mechanism---
In this version of my kernel, I have added two HotPlugs, AutoSMP and State Helper. Now, you may ask what is unique about it? Well, I have just used these HotPlugs as base. On top of these HotPlugs, I have done huge modifications, wrote many new Codes and worked on them many hours and I am very happy with the results.
AutoSMP (Modified)---
I have modified this HotPlug to only work as an On/Off Toggle. I have removed all the Options and Codes to make this HotPlug lightweight. Th only function of this HotPlug now is to turn an Octa-Core Soc into a Quad-Core one retaining the HMP or big.LITTLE technique. This will allow much more Power-Savings without degrading Performance as well as lesser Heat too.
State Helper (Modified) v2.0---
I have modified this HotPlug to a great extent. The original State Helper was only meant for Normal Architectures and not big.LITTLE architectures. I worked on this HotPlug to make it support big.LITTLE architecture as well as I have Optimized it to Perform in an efficient way too. Also, I have fixed a critical BUG of this HotPlug. Further, I have removed the unnecessary Codes to make it lightweight. Since I have Optimized this HotPlug for big.LITTLE architecture, this HotPlug now offers the ability to disable the big Cluster completely. Further, this HotPlug also offers the ability to turn an Octa-Core HMP Soc to a Hexa-Core one just like the setup of Snapdragon 650. This Optimization allows for Extreme Power-Savings.
These Core-HotPlug mechanisms offer the best way to Control the Cores for managing Heat and Improving Battery-Life. The best part is that users can control these HotPlugs to find the Perfect Combination according their usage. Also, an important point about these HotPlugs is that they are not Load-Based ones. These HotPlugs don't use CPU-Resources and thus offer Better Battery-Life and Lesser CPU-Usage. To sum up, I have Modified and Optimized these HotPlug in the best possible manner. These HotPlugs are the best ones for Yu-Yureka/Yureka PLUS.
4. Perfect OverClock for Snapdragon 615 1st Gen SoC---
As you all know, our devices seem to use the 1st Gen of SD615 SoC. Probably, that's why, we have 1.5 GHz of Max. Frequency. Further, due to great variations among the same SoC, developing OC to work on every device is a very difficult task. The Max. Frequency that our SoC can run properly is 1.7GHz. Above it, the SoC fails to boot. Further, kernels which were offering OCs above 1.7GHz were containing fake OCs i.e., only the numbers change, not the actual Frequency. Now, after weeks of testing by myself as well as some very good testers, I have managed to find the perfect way of implementing the 1.7GHz and 1.2GHz OC Frequency for big and LITTLE Cluster respectively. In my implementation of the OC, I have applied an Efficient Voltage Distribution technique. This allows to not only consume the least amount of Power but also helps in achieving Perfect Stability i.e., the OC will work on every Device irrespective of Revisions. Further, people who choose to not use the OCs, then the kernel will return to use the stock voltages thus providing the same level of efficiency as the stock kernel.
5. Load Shifter---
As I have already discussed in the Load Shifter's own thread, this feature transfers the Workload from the big Cluster to the LITTLE CLuster. Even the Android Background Processes are forced to run on the LITTLE Cluster with the help of this feature. Since we use LITTLE Cluster for most of the tasks except Gaming, there are considerable Gains in Battery-Life as well as Lesser Production of Heat.
Notes---
1. Due to variations in SoC, the Sound Control will work properly at different levels of Volume for different people. For ex, value 5 of Mic Gain may be too loud for some but too low for others. So, you people have to find out the perfect value for yourselves. By the way, value 10 of Mic Gain is known to be the most suitable for every device.
2. In order to avoid conflicts, I have added a failsafe regarding Core-Control and Core-HotPlug Mechanism. This means, out of AutoSMP, State Helper and Core Control, only one can be used at a time. Even if you try to enable each one of them simultanouesly, they won't get enabled. I have done this to avoid malfunctions.
3. After manually changing the CPU Governor or Frequency, all the Cores will come online even if any HotPlug is enabled. So, you just need to re-enable any HotPlugs you were using in order to disable the Cores again.
4. Currently, AOSParadox ROM and a few other voLTE enabled ROMs too have 100% Core-Load Issue. This leads to more Heat-Generation. Further, High CPU-Usage makes Charging Time a lot slower as well as decreases the Battery-Life by a large margin. Until this BUG is fixed, nothing much can be done to improve upon these areas.
5. Sometimes, enabling Core Control may cause the ROM to hang. In this case, rebooting via ROM doesn't work. So, just press and hold Power button until the phone restarts.
6. When Core 0 gets disabled (due to Core Control or State Helper HotPlug), Adiutor fails to get Frequency and Governor information and hence shows 0MHz in Frequency Panel and Blank Space in Governor Panel. This is normal. In this case, if you need to change Governor or Frequency, then you need to disable Core Control or State Helper HotPlug as the case may be. After this, force close Adiutor and then re-open it. This will make Adiutor get CPU information again.
Recommended Settings are also updated!!!
That's it folks! My best creation till date for Yu-Devices. My aim was always to improve the experience we get from our phones and provide the users with control over everything. Today, I have achieved that goal. This became possible only due to months of hard-work by me and testing-work done by some very reliable testers.
Testers (without these people, developing a Stable and BUG-Free Kernel would be near to impossible)---
dixan43
Bijendra barman
Frozen_Lemon
Ryuk and many others were there, thanks to all of you!!!
Download Links---
For all Lollipop (5.1.1) and Yu-OS ROMs---
https://www.androidfilehost.com/?fid=385035244224394352
For Marshmallow (6.0.x) ROMs only---
https://www.androidfilehost.com/?fid=529152257862677379
For AOSParadox 3.x (6.0.x) ROM only---
https://www.androidfilehost.com/?fid=529152257862677377
Enjoy the most efficient and thoughtfully made Kernel.
Shoiab I always use urs kernel as a daily driver but there is low mic volume issue in V14 and unable to resolve that so back to V13 ...so plz share the recommended settings for V13 ....
I hv yu yureka plus running on RRrom6.0.1.Is this kernel good for the rom
Will it work for my yu yureka plus 5510?I have RR rom installed based on Android MM6.0.1
Does this kernel work for 7.1.1 yureka builds?
Sent from my YU5510 using Tapatalk
Same question here does this kernel work for yu yureka on LineageOS 14.1 ?
Sent from my AO5510 using XDA-Developers Legacy app
---------- Post added at 06:29 AM ---------- Previous post was at 06:21 AM ----------
Shoaib05 said:
Update---
Velocity Kernel v14.0!!!
Changelog---
1. Merged Latest CM's Source Updates into Velocity's Source (contains many improvements).
2. Updated the Linux Base Version to the latest one of 3.10 branch i.e., 3.10.104 (contains BUG-Fixes). *NEW
3. Updated the PowerSuspend Drivers to the latest version i.e., v1.7 (should improve Battery-Life).
4. Added Support for Impulse 2016 Edition Governor (a Balanced Governor for smooth performance and decent Battery-Life). *NEW
5. Added Support for State Notifier Driver (an Optimized mechanism for knowing about Panel's State). *NEW
6. Tuned the LionFish Governor (for better Performance). *NEW
7. Modified the Touch-Boost to be user-controllable (In CM, it is enabled by default and is not user-controllable. This makes the Battery deplete much faster. In my kernel, it is disabled by default and is also user-controllable.). *NEW
8. Improved the Thermal Mechanism (better Heat-Management without much degradation in Performance). *NEW
9. Tuned the Interactive Governor for Efficient operation and more Power-Savings. *NEW
10. Removed Franco's Sound Control (Although, I ported it in the best possible manner, it still wasn't quite upto my standards.).
11. Removed the stock CyanogenMOD Core Control Feature (the current implementation wasn't as Efficient as it should have been in reducing Heat and improving Battery-Life). *NEW
12. Minor BUG-Fixes and Improvements.
Now, the Highlights of v14.0 (unique features which only Velocity Kernel offers for Yu-Devices)---
1. Core Control v2.0---
Built from scratch by me, this version of Core Control is much more efficient than the stock one. In this version, Cores are disabled according to temperature in a much more optimized manner. Further, this Core Control of mine, offers efficient Heat-Management as well as improved Battery-Life. To sum up, this is the best Core-Based Heat-Management Technique for Yu-Devices.
2. Faux Sound Control v4.1---
In this Sound Control, I have used Faux Sound v3.6 as base and on top of it, I have modified, fixed and enhanced the Driver. All of the changes are done by me! I have named this version as v4.1 because I have made 5 changes to the Driver (v3.6 + 5 Changes = v4.1). Coming to the point, this Sound Control is finally the best one. I have worked hours on it to port and fix it in the best way. Thus, now, there is no Low-Volume issue. Further, even the Negative Values work too. Also, the Volumes are boosted without distortion now i.e., higher Volumes can be achieved easily. Also, now, there is a fully functional Enable/Disable Toggle for Sound Control. To bring this feature and make it Compatible with the Modified Kernel Adiutor, I did a very clever workaround too. To sum up, this is indeed the best Sound Control for Yu-Devices with No BUGs.
3. Perfect Core-HotPlug Mechanism---
In this version of my kernel, I have added two HotPlugs, AutoSMP and State Helper. Now, you may ask what is unique about it? Well, I have just used these HotPlugs as base. On top of these HotPlugs, I have done huge modifications, wrote many new Codes and worked on them many hours and I am very happy with the results.
AutoSMP (Modified)---
I have modified this HotPlug to only work as an On/Off Toggle. I have removed all the Options and Codes to make this HotPlug lightweight. Th only function of this HotPlug now is to turn an Octa-Core Soc into a Quad-Core one retaining the HMP or big.LITTLE technique. This will allow much more Power-Savings without degrading Performance as well as lesser Heat too.
State Helper (Modified) v2.0---
I have modified this HotPlug to a great extent. The original State Helper was only meant for Normal Architectures and not big.LITTLE architectures. I worked on this HotPlug to make it support big.LITTLE architecture as well as I have Optimized it to Perform in an efficient way too. Also, I have fixed a critical BUG of this HotPlug. Further, I have removed the unnecessary Codes to make it lightweight. Since I have Optimized this HotPlug for big.LITTLE architecture, this HotPlug now offers the ability to disable the big Cluster completely. Further, this HotPlug also offers the ability to turn an Octa-Core HMP Soc to a Hexa-Core one just like the setup of Snapdragon 650. This Optimization allows for Extreme Power-Savings.
These Core-HotPlug mechanisms offer the best way to Control the Cores for managing Heat and Improving Battery-Life. The best part is that users can control these HotPlugs to find the Perfect Combination according their usage. Also, an important point about these HotPlugs is that they are not Load-Based ones. These HotPlugs don't use CPU-Resources and thus offer Better Battery-Life and Lesser CPU-Usage. To sum up, I have Modified and Optimized these HotPlug in the best possible manner. These HotPlugs are the best ones for Yu-Yureka/Yureka PLUS.
4. Perfect OverClock for Snapdragon 615 1st Gen SoC---
As you all know, our devices seem to use the 1st Gen of SD615 SoC. Probably, that's why, we have 1.5 GHz of Max. Frequency. Further, due to great variations among the same SoC, developing OC to work on every device is a very difficult task. The Max. Frequency that our SoC can run properly is 1.7GHz. Above it, the SoC fails to boot. Further, kernels which were offering OCs above 1.7GHz were containing fake OCs i.e., only the numbers change, not the actual Frequency. Now, after weeks of testing by myself as well as some very good testers, I have managed to find the perfect way of implementing the 1.7GHz and 1.2GHz OC Frequency for big and LITTLE Cluster respectively. In my implementation of the OC, I have applied an Efficient Voltage Distribution technique. This allows to not only consume the least amount of Power but also helps in achieving Perfect Stability i.e., the OC will work on every Device irrespective of Revisions. Further, people who choose to not use the OCs, then the kernel will return to use the stock voltages thus providing the same level of efficiency as the stock kernel.
5. Load Shifter---
As I have already discussed in the Load Shifter's own thread, this feature transfers the Workload from the big Cluster to the LITTLE CLuster. Even the Android Background Processes are forced to run on the LITTLE Cluster with the help of this feature. Since we use LITTLE Cluster for most of the tasks except Gaming, there are considerable Gains in Battery-Life as well as Lesser Production of Heat.
Notes---
1. Due to variations in SoC, the Sound Control will work properly at different levels of Volume for different people. For ex, value 5 of Mic Gain may be too loud for some but too low for others. So, you people have to find out the perfect value for yourselves. By the way, value 10 of Mic Gain is known to be the most suitable for every device.
2. In order to avoid conflicts, I have added a failsafe regarding Core-Control and Core-HotPlug Mechanism. This means, out of AutoSMP, State Helper and Core Control, only one can be used at a time. Even if you try to enable each one of them simultanouesly, they won't get enabled. I have done this to avoid malfunctions.
3. After manually changing the CPU Governor or Frequency, all the Cores will come online even if any HotPlug is enabled. So, you just need to re-enable any HotPlugs you were using in order to disable the Cores again.
4. Currently, AOSParadox ROM and a few other voLTE enabled ROMs too have 100% Core-Load Issue. This leads to more Heat-Generation. Further, High CPU-Usage makes Charging Time a lot slower as well as decreases the Battery-Life by a large margin. Until this BUG is fixed, nothing much can be done to improve upon these areas.
5. Sometimes, enabling Core Control may cause the ROM to hang. In this case, rebooting via ROM doesn't work. So, just press and hold Power button until the phone restarts.
6. When Core 0 gets disabled (due to Core Control or State Helper HotPlug), Adiutor fails to get Frequency and Governor information and hence shows 0MHz in Frequency Panel and Blank Space in Governor Panel. This is normal. In this case, if you need to change Governor or Frequency, then you need to disable Core Control or State Helper HotPlug as the case may be. After this, force close Adiutor and then re-open it. This will make Adiutor get CPU information again.
Recommended Settings are also updated!!!
That's it folks! My best creation till date for Yu-Devices. My aim was always to improve the experience we get from our phones and provide the users with control over everything. Today, I have achieved that goal. This became possible only due to months of hard-work by me and testing-work done by some very reliable testers.
Testers (without these people, developing a Stable and BUG-Free Kernel would be near to impossible)---
dixan43
Bijendra barman
Frozen_Lemon
Ryuk and many others were there, thanks to all of you!!!
Download Links---
For all Lollipop (5.1.1) and Yu-OS ROMs---
https://www.androidfilehost.com/?fid=385035244224394352
For Marshmallow (6.0.x) ROMs only---
https://www.androidfilehost.com/?fid=529152257862677379
For AOSParadox 3.x (6.0.x) ROM only---
https://www.androidfilehost.com/?fid=529152257862677377
Enjoy the most efficient and thoughtfully made Kernel.
Click to expand...
Click to collapse
Shoaib05 please can you make it for Yu yureka on LineageOS 14.1 ?
CAN YOU MAKE IT FULL VOLTE FOR IT CAN DO HD VOICE CALLING BUT VIDEO AND WI-FI CALLINGS ARE STILL MISSING , i searched all threads on XDA but still can't find what i am looking for.
Sent from my AO5510 using XDA-Developers Legacy app
I Clean Flash the Velocity Kernel 14.0 Old but after flashing WiFi and WiFi Hotspot Not Working
How to Solve this Issue
Flashed on CM 12.1
Sent from my YU5510A using Tapatalk
O
Sent from my AO5510 using XDA-Developers Legacy app
Code:
#include "std/disclaimer.h"
/*
* I am not responsible for bricked devices, dead SD cards,
* thermonuclear war, or you getting fired because the alarm app failed. Please
* do some research if you have any concerns about features included in this software
* before using it! YOU are choosing to make these modifications, and if
* you point the finger at me for messing up your device, I will laugh at you.
*/
What Is It
Subcore is an root daemon that utilizes various sensors in the device to systematically apply different usage profiles. The goal is to achieve a balance based on the user's workload, rather than relying on the CPU governor to make bias assumptions about the current workload.
How Does It Work
Subcore reads and writes to system files on the device to determine which profile to place the device into. These interfaces include:
• Active CPU load
• Available CPU cores
• Available CPU governors
• Available CPU frequencies
• Available GPU load
• Available GPU frequencies
• Current battery capacity
• Battery state (charging / discharging)
• Screen state
◦ State Notifier (primary choice)
◦ Power Suspend (secondary choice)
◦ Framebuffer interface (tertiary choice)
• Available device memory
• Max device memory
• Available IO schedulers
• Block readahead
• Block swappiness
• Block cache pressure
• Block dirty rations
• Random entropy
• Block overcommit
• Block page cluster
• Block dirty centisecs
• Block LMK
• Block laptop mode
• Block KSM
• Uniquely Generated Interactive Tunables
• Uniquely Generated Schedutil Tunables
User Prediction Algorithm
Without some form of user prediction, a game could begin to lag for a moment during a loading scene, where the load requirement dips. To counteract this, Subcore implements a user prediction algorithm that attempts to maintain fluidity in heavy applications, even during moments of low load. It works by determining repetitive load averages, and scanning less often when the load is consistent. This results in far less lag spikes when playing intensive games.
Power Aware Algorithm
Since Subcore is a low-level (yet userspace) tool, it has direct access to battery statistics. When charging (and screen on), Subcore will boost your performance to the highest performing profile to ensure the user experiences UI/UX conformity, disregarding the energy limitation. Additionally, when Subcore detects the device is at 15% battery or less, it will half the loadavg, which means it requires twice as much CPU load to enter the next profile. Likewise, at 5% battery or less, Subcore locks the device into the lowest profile, which is optimized for deep sleep or idle, sacrificing a chunk of performance to battery. This setting can be disabled by toggling "Disable Power Aware" in the Subcore GUI app.
RUPG - Realtime Unique Profile Generation
Subcore implements a new concept that I call RUPG. What makes Subcore special is the fact that it is compatible with essentially all devices. At runtime, Subcore initially gathers heaps of data to generate numerous device-specific profiles based on various factors. These generated profiles are heavily optimized for each device, so that each user achieves the most efficient software experience for the available hardware/software provided. These profiles are then saved in memory and are marked for deletion when Subcore exits. Some examples where RUPG is utilized is in the generation of device specific LMK offsets (minfree). Each device has a different RAM size, so Subcore must manually calculate the optimum LMK minfree sizes for each offset vector (VERY_LIGHT --> VERY_AGGRESSIVE). Subcore also utilizes RUPG in the production of the governor tunables. Each device has a different SOC CPU frequency table, which must be accounted for. These profiles are generated automatically by the binary, so the user doesn't need to tune anything themselves.
Race To Idle
Research proves that when completing a task, less resources are eaten when boosting to a slightly higher frequency for a short time, rather than a low frequency for longer. Subcore takes full advantage of this theory and applies special tunables for each profile. Each Subcore profile has a different goal to achieve. The UI/UX is the main profile that takes full advantage of RTI. This profile tunes the governor to stay at minimum frequencies until a small workload is requested. It then jumps up a frequency level to complete the task faster, then it instantly shoots back to minimum frequency if all other tasks are completed. If a heavy task comes up, but not quite heavy enough to trigger a profile change, the UI/UX profile will handle it by jumping another 1-2 frequency levels. Finishing the work requested, the loadavg will quickly shoot down and the governor will return to idle, saving battery yet increasing performance; it sounds impossible, but in practice, it works better than expected.
Performance == Battery
It sounds impossible. How can an app save power, but also make my device perform better? Here's why it works. Think about battery and performance as independent spectrums. Just because you have one doesn't mean you can't have the other. By working efficiently, Subcore can actually improve performance on some devices. This is because Subcore doesn't just tune your device for battery, it also applies VM tweaks, MM tweaks, Block tweaks, and much more. During my testing phase, many of my testers were telling me how Subcore strangely caused some tasks to perform better than usual. This included UI/UX smoothness, app start times, Camera HDR rendering, file IO (such as zipping a large file), and some other tasks. I realized that the tweaks that Subcore applies improve battery by improving performance in areas that don't affect battery as much. For example, something as basic as IO readahead will cause a marginal impact on battery, but the Block performance benefit that comes with a higher readahead can cause IO tasks to finish much faster. Applying the concept of Race To Idle, the disk performance benefit helps the device finish its current task faster, allowing the CPUs to reach deep sleep sooner, and in turn, providing better battery.
Hyper Optimizing
Subcore is written in native C++. In fact, the Android app for Subcore just forks the included binary based on the device architecture. Since Subcore is written in C++, it is light, fast, and pretty tiny. It is also entirely independent from Java code entirely. Once it's started, the Subcore app can be killed fully (even force quit), and the daemon will persist, since it is the parent of its own process. Using `top`, you can see Subcore isn't even on the list. Every single line of the C++ code is written to utilize the least amount of memory, and run as efficiently as possible. It utilizes C++11 inlines, uint*_t, -Ofast, --strip-all, custom built NDK clang toolchains from source, and far more optimization. Subcore includes C++STL in the binary as well, so it is portable and is contained all in one binary. Subcore is also compiled in ARM, ARM64, x86, x86_64. MIPS is not supported at this time.
Automatic Backup/Restore Algorithm
Since Subcore writes to a large portion of your sysctl, many of your kernel manager tweaks would be written over until they are reapplied on the next boot. Luckily, I spent the extra time to implement an automatic backup and restore algorithm to save the device's current settings on the start of Subcore. On sending a SIGINT or SIGTERM to Subcore, it will restore the user settings before exiting. This way, you don't need to reboot each time you stop Subcore. NOTE: If you toggle Start On Boot to Subcore, there is a high probability that it will start before your kernel manager's apply on boot will. This means that Subcore won't backup the proper data, so when you stop Subcore, your kernel manager tweaks won't be applied. To solve this, either reduce the timeout for starting on boot for your kernel manager, or start Subcore manually after each boot.
Results
When you start using Subcore, it'll feel too good to be true. But stats don't lie. I will provide quotes from my testers, along with screenshots of my testers and my battery life improvement. I urge everyone that tries Subcore to post your results, along with the device model you are using. If you have any questions about how Subcore works, or if you have any questions at all, please contact me. I'd be more than happy to address your concerns.
Testers
I'd like to personally thank all of my testers for sacrificing their phones to my code. Each and every one of them assisted in the stability of the program itself.
@SmallTarzan
@efranz
@kdrag0n
@ASHLEY117
@abhirams2020
@Mountaser_halak
Extra Notes
For Subcore to work properly, please ensure the following things are proper:
• Make sure Subcore is always granted root.
• Use Low-memory mode if the device does not have ZRAM or ZCACHE, or if you notice apps crashing / not opening.
Contact
I am always available for contact. Send me anything you want: questions, concerns, suggestions, comments, assistance, thank you messages, etc. I always appreciate messages from users
Gmail: [email protected]
Telegram: @tytydraco
XDA: @tytydraco
Donate
When I released System Mods, users were always asking how they could donate. So I thought I'd post a PayPal link so you can donate if you really enjoy my work
Those who donate can request to be put on the XDA thread and I'll add you to the list of donators here. You can also write a message to post here if you can fit it.
https://www.paypal.me/TylerNijmeh
--DONATORS--
none yet
Download
Google Play
VirusTotal report:
arm64 raw binary: https://www.virustotal.com/#/file/5...3074755f96e516f20bb1f6fb85c95abf95a/detection
XDA:DevDB Information
Subcore, App for all devices (see above for details)
Contributors
tytydraco
Version Information
Status: Stable
Current Stable Version: 1.0
Stable Release Date: 2018-09-05
Created 2018-09-06
Last Updated 2018-09-05
Here are some quotes from my testers:
"With subcore on image processes faster ?" ~ Franz
"But I'd say gcam is a bit slower when subcore is off" ~ Franz
"Sorry been quiet and lurking but tested on stock soldiers ROM S9, Phh treble aosp and havoc device specific. Results are pretty impressive! Getting 20% more battery life and faster operations on stock based and aosp based but not much difference noticed with treble GSI" ~ Ashley117
"Subcore on: 866/4543, Subcore off: 772/2527" ~ Franz
"@tytydraco I think you will like this ^^ *photo of Antutu*: 147987 (Subcore on) vs 142286 (Subcore off)" ~ Franz
"It has more IQ than some of my classmates." ~ SmallTarzan
PROMO CODES
These are first come first serve. Here is 10 to start off. Enjoy!
0KKVAS9PEPU2X9JWP3Z2JXT
AW6VZ9WGPT3WSH0P9AUH40S
1FG32WUV2T02XBE8H0SRMKT
ECM1UY61V7V8295AFFZZ5QY
F836DQPKJ26RNW4Y49LAYEX
CZB08PFUV2MB3M8CP5J1RPK
8X8AHN7L5MCZ1KXVGW4B2W7
9YTQUQTFVZHNWXY3WT7S81M
JD8K4L46S40R61YWY0599JG
YCG4QQ36YXPF2LYXYPYG70K
Edit: all the promo codes were used. Sorry guys ?
Amazing battery life with only a slight impact on performance. I watched this mature from a minimal C++ program to a full-on app that balances performance and battery very well. Good luck!
Hi, mum! I'm on YouTube!
tytydraco said:
PROMO CODES
These are first come first serve. Here is 10 to start off. Enjoy!
0KKVAS9PEPU2X9JWP3Z2JXT
AW6VZ9WGPT3WSH0P9AUH40S
1FG32WUV2T02XBE8H0SRMKT
ECM1UY61V7V8295AFFZZ5QY
F836DQPKJ26RNW4Y49LAYEX
CZB08PFUV2MB3M8CP5J1RPK
8X8AHN7L5MCZ1KXVGW4B2W7
9YTQUQTFVZHNWXY3WT7S81M
JD8K4L46S40R61YWY0599JG
YCG4QQ36YXPF2LYXYPYG70K
Click to expand...
Click to collapse
Took F836DQPKJ26RNW4Y49LAYEX. Thanks for the code.
senpaidev said:
Took F836DQPKJ26RNW4Y49LAYEX. Thanks for the code.
Click to expand...
Click to collapse
No problem! Let me know how you like it, and please share the thread if you want
Claimed 9YTQUQTFVZHNWXY3WT7S81M
Thank you! Will test it out and provide some feedback soon.
tytydraco said:
PROMO CODES
These are first come first serve. Here is 10 to start off. Enjoy!
0KKVAS9PEPU2X9JWP3Z2JXT
AW6VZ9WGPT3WSH0P9AUH40S
1FG32WUV2T02XBE8H0SRMKT
ECM1UY61V7V8295AFFZZ5QY
F836DQPKJ26RNW4Y49LAYEX
CZB08PFUV2MB3M8CP5J1RPK
8X8AHN7L5MCZ1KXVGW4B2W7
9YTQUQTFVZHNWXY3WT7S81M
JD8K4L46S40R61YWY0599JG
YCG4QQ36YXPF2LYXYPYG70K
Click to expand...
Click to collapse
Oops!!! All those codes were redeemed. Do you have more? Please?
arunv707 said:
Oops!!! All those codes were redeemed. Do you have more? Please?
Click to expand...
Click to collapse
I won't be releasing any more on XDA, but if Android Police or Android Authority choose to sponsor my app, they will give people up to 20 promo codes.
Pleasure to test and 1 of the 1st apps I install in my daily flashing routine ??
Improving performance on GSI ROMs now I've noticed but only on Phh releases. Thank you again
I fixed the issue where some devices would get incredibly laggy. The cause for this was that my algorithm for determining the screen sleep state was faulty. The system would deliver inaccurate information for the variable I was tracking, so I switched to a new (updated) variable (specifically measured_fps. It is 0.0 when the screen is off). This should fix the lag for the Pixel 2 XL as well as some other devices.
I sincerely apologize to those affected, and I ask that you give Subcore another chance. I am passionate about this project, and I want my users to be satisfied. If you'd like a refund, email me and I can try to figure something out. Thank you.
Credit to log comes from Reddit user u/faz712. Thanks so much
Reddit thread: https://www.reddit.com/r/androidapps/comments/9deihr/app_root_subcore_adaptive_daemon_v10/
I use it on a S8 . After enabling, governor is schedutil and device is underclocked From 2,3 Ghz to 1066 Mhz . Is this underclock normal ? https://drive.google.com/file/d/1BG8ZyNH6LojgquYVZCWxxzNIWY39VUEV/view?usp=drivesdk Logcat when i Start subcore. @tytydraco
Re¢o said:
I use it on a S8 . After enabling, governor is schedutil and device is underclocked From 2,3 Ghz to 1066 Mhz . Is this underclock normal ? https://drive.google.com/file/d/1BG8ZyNH6LojgquYVZCWxxzNIWY39VUEV/view?usp=drivesdk Logcat when i Start subcore. @tytydraco
Click to expand...
Click to collapse
That's perfectly normal. That setting will keep changing depending on what you're doing. Don't change the settings as Subcore will handle it for you
tytydraco said:
That's perfectly normal. That setting will keep changing depending on what you're doing. Don't change the settings as Subcore will handle it for you
Click to expand...
Click to collapse
I used it for different things like casual Apps and some gaming but the Frequenz is still 1066Mhz and some Times i had little lags and device get hot. But when you say its normal i will tryit out for longer . But on thing i can say battery is very nice
Hello,
I am using S8 (Exynos) with velocity kernel. Do I need to enable any other settings in the app too? Also it doesn't look like it changes all values such as LMK. I checked that with MTweaks but didn't changed settings there ofc.
Also I was wondering if disabling debugging and IO stats would break the algorithm.
SH4M3 said:
Hello,
I am using S8 (Exynos) with velocity kernel. Do I need to enable any other settings in the app too? Also it doesn't look like it changes all values such as LMK. I checked that with MTweaks but didn't changed settings there ofc.
Also I was wondering if disabling debugging and IO stats would break the algorithm.
Click to expand...
Click to collapse
No, you're good to go. LMK is not tuned when memory awareness is disabled (which should be on Samsung ROMs).
On the kernel side, disabling debugging and IO stats won't break Subcore. It doesn't use those.
kdrag0n said:
No, you're good to go. LMK is not tuned when memory awareness is disabled (which should be on Samsung ROMs).
On the kernel side, disabling debugging and IO stats won't break Subcore. It doesn't use those.
Click to expand...
Click to collapse
Thx ^^ Great App btw
I am not able to download this app in play store, the search also does not show up this app. Please can some one give me a download link
cphilch said:
I am not able to download this app in play store, the search also does not show up this app. Please can some one give me a download link
Click to expand...
Click to collapse
Absolutely! As long as your region supports paid purchases, you should be able to download the app. Enjoy!
https://play.google.com/store/apps/details?id=com.draco.subcore
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?