Welcome to Z-Kernel's thread!
Features
- Base kernel fully updated to linux-tegra-nv-3.1 (bug fixes & performance improvements)
- Simplified board codes
- Cleaned up Acer specific code
Click to expand...
Click to collapse
Changelog
r2:
- Restarted kernel development (r1's features not implemented yet)
- Base kernel fully updated to linux-tegra-nv-3.1 (bug fixes & performance improvements)
- Simplified board codes
r1:
- CPU OC to 1.6 ghz by default (should be stable)
- GPU OC support up to 700MHz (default is 520 mhz)
- Overclocked LP core from 500 to 620 mhz
- Custom user voltage control for CPU and Core components such as EMC, GPU, and LP (faux123)
- Dynamic FSYNC
- Optimized KSM
- Optimized ZRAM
- Compiled using latest Linaro toolchain with optimized compiler flags
- Optimized SLUB and use SLUB by default instead of SLAB
- Glibc memcpy and memmove
- Deadline improvements for solid state drives
- Proportional Rate Reduction for TCP
- Tegra 3 variant display (faux123)
- Optimized swahb32 byteswap helper
- Asynchronous I/O latency improved through removal of plug in do_io_submit()
- allow use of an I/O controller's native max block size
- Optimized ARM RWSEM algorithm
- timer: optimize apply_slack()
- Optimized crypto algorithms
- Optimized AES and SHA1 routines
- LowMemoryKiller fixes and improvements
- Lock performance governor to all 4 cores
- Many scheduler improvements and optimizations
- updated bcmdhd driver (wifi)
- over 450 changes committed, so the above list isn't complete
Click to expand...
Click to collapse
Complete list of changes can be found in the commit log: https://github.com/Ziyann/android_kernel_acer_t30
I'm not responsible if anything bad happens with your device!
This build has been tested on CM11 only, so if you run into something with other ROMs, report it and I will see what I need to change to cooperate with it.
XDA:DevDB Information
Z-Kernel, Kernel for the Acer Iconia A700 and A510
Contributors
Ziyan
Kernel Special Features:
Version Information
Status: Stable
Current Stable Version: R2
Stable Release Date: 2014-07-30
Created 2014-09-23
Last Updated 2014-09-23
Nice, if it's working fine, I hope you will also support the A510/A511
Shreps said:
Nice, if it's working fine, I hope you will also support the A510/A511
Click to expand...
Click to collapse
Of course, I'll see what can I do when I get everything (OC, UV, ...) working here waiting for a tester...
it is indeed slow. even when completely debloated plus stripped of "essential" system components that I personally do not use. I will try this right away. will report back within an hour in this post.
@Ziyan
it boots, runs, everything seems standard. not seeing any performance increases though. same ol' 10 to 15 fps is there anything more you wish for me to test with it? I replaced this tab a while ago with galaxy note pro 12.2 so I can't really use it enough to check for random reboots
Sterist said:
@Ziyan
it boots, runs, everything seems standard. not seeing any performance increases though. same ol' 10 to 15 fps is there anything more you wish for me to test with it? I replaced this tab a while ago with galaxy note pro 12.2 so I can't really use it enough to check for random reboots
Click to expand...
Click to collapse
Thanks, that's good, it means I can continue improving it. I need to check the kernel periodically after a big bunch of commits, because if something gets broken, it can be hard to find what causes it if from a thousand things I'll push a new version and changelog later today or tomorrow.
sounds good. quote this post when it's uploaded, it'll send me am email notification and I can get right on it.
Sterist said:
sounds good. quote this post when it's uploaded, it'll send me am email notification and I can get right on it.
Click to expand...
Click to collapse
Here's a new version. Before testing it, please make some benchmarks with the previous version (mainly 3D), because - if everything works as it should -, the GPU is now working at 520 mhz instead of 416. It should also have CPU overclocking and voltage control support, so please install Trickster Mod, or something like that from Play Store to see if it works (screenshots are welcome). If it works (i'd be a bit surprised lol it was too easy), please run some benchmarks again to see if there's a noticeable difference. I've got 12 pages of commits waiting to be merged, so yeah, if something got broken, I better fix it now :silly:
Ziyan said:
Here's a new version. Before testing it, please make some benchmarks with the previous version (mainly 3D), because - if everything works as it should -, the GPU is now working at 520 mhz instead of 416. It should also have CPU overclocking and voltage control support, so please install Trickster Mod, or something like that from Play Store to see if it works (screenshots are welcome). If it works (i'd be a bit surprised lol it was too easy), please run some benchmarks again to see if there's a noticeable difference. I've got 12 pages of commits waiting to be merged, so yeah, if something got broken, I better fix it now :silly:
Click to expand...
Click to collapse
just woke up and leaving for work in 20 minutes. when I get there and settle in (about an hour and 20min from this post) I'll test it
which benchmark though, antutu?
Sterist said:
just woke up and leaving for work in 20 minutes. when I get there and settle in (about an hour and 20min from this post) I'll test it
which benchmark though, antutu?
Click to expand...
Click to collapse
Yeah, antutu will do, just note the invidual points
Ziyan said:
Yeah, antutu will do, just note the invidual points
Click to expand...
Click to collapse
woah woah... I just went to download the second version and the tab was dead from 77% last night, still warm.
there's a wake problem, screen will turn on one time after booting up but only that one time
and a sleep problem, after manually turning the screen off it will not turn back on (and kills battery very quickly!)
Sterist said:
woah woah... I just went to download the second version and the tab was dead from 77% last night, still warm.
there's a wake problem, screen will turn on one time after booting up but only that one time
and a sleep problem, after manually turning the screen off it will not turn back on (and kills battery very quickly!)
Click to expand...
Click to collapse
Thanks for the report, I'll investigate the problem tomorrow (it's 01:30 AM here :silly. If you could take a dmesg (while turning the screen off, then trying to turn it back on), or last_kmsg, that would be great help! If you don't know how, refer to section 2 and 3: http://forum.xda-developers.com/showthread.php?t=1520508
Ziyan said:
Thanks for the report, I'll investigate the problem tomorrow (it's 01:30 AM here :silly. If you could take a dmesg (while turning the screen off, then trying to turn it back on), or last_kmsg, that would be great help! If you don't know how, refer to section 2 and 3: http://forum.xda-developers.com/showthread.php?t=1520508
Click to expand...
Click to collapse
higher score / lower 3D performance is v1
lower score / higher 3D is v0
recent apps cleared and CPU set to 1400 performance and ROW
no app gives OC/UV options with v1
I don't have access to a pc at work so can't run dmesg properly for this, and I'm having trouble reproducing the sleep crash now
this is probably all exactly what you did not want me to say lol
edit: so, I got it to crash again (yay!) but can't get klast to work (read only fs) I tried mounting various directories as RW but honestly I have no idea which to do... and here's dmesg which may or may not contain what you need.
I know it might be a little early to ask but any chance you could implement Frandom?
Sterist said:
(cut)
edit: so, I got it to crash again (yay!) but can't get klast to work (read only fs) I tried mounting various directories as RW but honestly I have no idea which to do... and here's dmesg which may or may not contain what you need.
I know it might be a little early to ask but any chance you could implement Frandom?
Click to expand...
Click to collapse
Thanks for the detailed report, I think I revert Franco's hotplugging driver for now, seems like it's on a rampage. May try again in the future.
As for the last_kmsg, your first command was correct, it's just that it doesn't always get created.
We'll see about Frandom when we get things working nice
Here's a build with the stock hotplugging driver, report back if it still crashes.
Ziyan said:
Thanks for the detailed report, I think I revert Franco's hotplugging driver for now, seems like it's on a rampage. May try again in the future.
As for the last_kmsg, your first command was correct, it's just that it doesn't always get created.
We'll see about Frandom when we get things working nice
Here's a build with the stock hotplugging driver, report back if it still crashes.
Click to expand...
Click to collapse
ok I let it idle for about 30 minutes (that was enough to crash every time I left it alone at work) and so good so far.
still no OC/UV though
edit... idle 2 more hours and no problems
Sterist said:
ok I let it idle for about 30 minutes (that was enough to crash every time I left it alone at work) and so good so far.
still no OC/UV though
edit... idle 2 more hours and no problems
Click to expand...
Click to collapse
Great, let's see if CPU OC/UV works with this one. If it does, don't forget to run a benchmark, as GPU OC didn't work till now
Ziyan said:
Great, let's see if CPU OC/UV works with this one. If it does, don't forget to run a benchmark, as GPU OC didn't work till now
Click to expand...
Click to collapse
still no CPU OC/UV. also, that 52mhz step has never worked on any ROM or kernel I've tried, that may extend battery life
Sterist said:
still no CPU OC/UV. also, that 52mhz step has never worked on any ROM or kernel I've tried, that may extend battery life
Click to expand...
Click to collapse
Ok, it must work now.
About 52 mhz, it's so low that any small background work would ramp up the CPU to hispeed_freq, so in the end, it would shorten battery life. The same thing happens with Galaxy Nexus if we go down to 180 mhz, which is a lot, compared to 52 mhz
I've added about 200 commits since your last try (this is a great daily activity :silly, the kernel is getting to be on pair with a Nexus 7 kernel soon if we get OC/UV and some more extra things working :highfive:
Ziyan said:
Ok, it must work now.
About 52 mhz, it's so low that any small background work would ramp up the CPU to hispeed_freq, so in the end, it would shorten battery life. The same thing happens with Galaxy Nexus if we go down to 180 mhz, which is a lot, compared to 52 mhz
I've added about 200 commits since your last try (this is a great daily activity :silly, the kernel is getting to be on pair with a Nexus 7 kernel soon if we get OC/UV and some more extra things working :highfive:
Click to expand...
Click to collapse
ok so UV menu now loads but doesn't look to work quite right - not usable. this is the menu I was looking for that did not load before
OC still does not work though
about 52 (51 actually) every time it is selected, after I leave the screen and come back 102 becomes the selected minimum automatically, even if lock frequency at 51
need benchmark? and ty ty your time!
Sterist said:
ok so UV menu now loads but doesn't look to work quite right - not usable. this is the menu I was looking for that did not load before
OC still does not work though
about 52 (51 actually) every time it is selected, after I leave the screen and come back 102 becomes the selected minimum automatically, even if lock frequency at 51
need benchmark? and ty ty your time!
Click to expand...
Click to collapse
At least we're making progress :good: try this one, and also try trickster mod (specific and general menu).
Benchmarks are welcome, those 200 commits should improve performance a bit, though I think most of them can only be seen in real usage (low memory killer, zram, ...)
Ziyan said:
At least we're making progress :good: try this one, and also try trickster mod (specific and general menu).
Benchmarks are welcome, those 200 commits should improve performance a bit, though I think most of them can only be seen in real usage (low memory killer, zram, ...)
Click to expand...
Click to collapse
bootloop, won't get past Acer logo
benchmark is from the last kernel
Related
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Join us on irc.freenode.com #cm6-snap
Snap F.A.Q.
(maintained by shift_)
Click to expand...
Click to collapse
Daily Drivers
The best options for daily drivers are:
Downloads:
cm6-snap-v7.5-havs925 Download md5 bcdb177c62b51542e450ce2e620fea45
cm6-snap-v7.01 Download md5 80cfe44a7043a4a6d06cd0eefca88bb4
cm6-snap-v7.11 Download md5 9ed1236e28a82766f46c5eea994eac5e
Read the rest of the OP and ask questions in the thread for additional information.
Click to expand...
Click to collapse
Snap kernels are built to work only on CM6 based ROMs
You assume all responsibility for the use of this software.
Version 7.6 [cfs/bfs]/nhavs925/qs2
Before I start, I want to give a special thanks to the usual suspects: spiicytuna for his work on SNAPturbo, and shift for his outstanding graphics work. We also had a very helpful beta testing team open their phones up to some fairly wild experimentation and some late nights: drmacinyasha, jabbawalkee, i[e, gerald410, swatspyder, nicholaaaas, mrkmrk, and jsseidel1. (Deepest apologies if I missed anybody, please let me know and I'll update the list)
Initially there are two releases of v7.6: CFS and BFS. Try both and use the one that works best for you. v7.6 is built from the CM6 2.6.32.15 source. It includes the first release of SNAPturbo, SNAPpapers, SNAPwidget, overclocking to 1.19ghz, netarchy's modified HAVS [nHAVS], and my modified conservative governor. You do not have to utilize SNAPturbo: It is an optional feature. Instructions for use are below.
The BFS version of v7.6 uses BFS Scheduler-v318 of BFS because this version currently provides the best results on CM6. All other features of the BFS release are identical to the CFS release.
SNAPturbo
SNAPturbo is a proprietary application designed to enhance system performance with no additional overclocking or battery penalty. SNAPturbo is not derived from the kernel source, is not subject to GPL, and the source code will not be shared, so please do not ask. SNAPturbo may not be distributed without prior written consent from jmxp69 and spiicytuna. SNAPturbo will only activate on a snap kernel.
Once you've successfully activated Turbo, you never have to do it again as long as you stick with a v7.6 kernel. You can safely flash v7.6 directly on top of CM6 nightlies in the same recovery session.
Before using SNAPturbo, please follow these instructions:
Perform a nandroid backup. Really, you should be doing this anytime you flash customized software.
Optional but recommended: Use Titanium Backup or My Backup Pro (available in Market) to backup your data and applications.
Enable Airplane Mode
Run the SNAPturbo application
Give SNAPturbo SU permissions
Do not touch any controls or the screen until after the phone reboots.
Note: You will probably see force closes while running SNAPturbo. This is normal and expected. Just let SNAPturbo run and it will reboot your phone when it finishes.
Known Issues
Important: During beta testing, some members of the beta team reported they stopped receiving SMS messages. We were unable to directly correlate this to anything happening with the kernel. In other words, it was not repeatable and the majority of testers never saw the issue. In one case, a re-flash of CM6 restored inbound SMS, and in another, it took a re-flash back to Stock Sense (with root). In each case after flashing either CM6 or a Sense ROM, the testers were able to re-flash v7.6 and never encountered the issue again.
Occasionally after activating SNAPturbo, one or two applications may repeatedly FC after rebooting. If this happens, try clearing data in application manager or just re-install the app. This has cleared the problem 100%.
SNAPturbo may look like it's destroying your phone when it runs. You may see force closes and maybe even smoke coming from the battery compartment. This is NORMAL. Let it run, leave it alone, and it should reboot on its own. After reboot, your phone should run normally. (Actually, I'm kidding about the smoke, but it does look ugly at first. Just let it ride…)
If for whatever reason SNAPturbo does not reboot your phone and return you to normal operating conditions (boot loops/odd behavior):
Do not attempt to re-activate.
Use the failsafe installation method listed below.
The only current method of disabling SNAPturbo is to wipe. v2 of SNAPturbo will provide a disable function.
Screen Tearing - v7.6 sets Nova panels T2 to 380. Previous testing indicates this is the best option for most phones. If you encounter any tearing, find Assasainslament's Novafreq and try 371.
After enabling turbo, if SetCPU FC's, uninstall and reinstall. That fixes it.
Failsafe Install
As much testing as went into SNAPturbo, the possibility exists you may run into problems. If you do, the following method is known to work 100%.
Backup apps with Titanium or My Backup Pro
Wipe Everything
Flash CM6
Flash v7.6
Reboot-DO NOT sign-in to Google
Turn Airplane Mode On
Activate Turbo
Sign-In to Google (Open Market)
Restore Apps
Resume normal use
Flashing Nightlies
If you flash a new nightly, make sure you flash v7.6 immediately afterwards. I recommend flashing in the same recovery session. If you do not flash v7.6 after flashing a nightly, you will bootloop.
If you forget to flash v7.6 after a nightly and you start to bootloop, just go back into recovery (hold Volume down while powering phone on) and flash v7.6. You will work fine afterwards.
v7.6 Changelog
Kernel now includes SNAPturbo application only. All other applications have been removed
Set the maximum CPU freq to 1.19. Many people were able to run 1.22g, but there is no practical benefit to doing it, so 1.19 is the new max across all revisions.
Minimum UV is 925. I've found this value to be the most stable and best for my battery.
Added Koush's AnyKernel Updater. Wiping Dalvik should now be a thing of the past.
BFS Version: Revert to BFS v0.318
Set interactive as default governor
Legacy snap tweaks to filesystem, network, vm, etc..
Tweaked conservative governor timings
Downloads
Click to expand...
Click to collapse
SNAP Extras - Here are a few extra user installable goodies to round-out SNAP on your CM6 installation.
SNAPsplash
For even greater Snapification of your phone, check out the graphics madness from Shift available now via SNAP Themed Splash Screens. Shift posted screenshots and detailed instructions here.
Update: SNAP Turbo Splash Screens now available in the Extras folder. See this post for screenshots.
Downloads
Click to expand...
Click to collapse
SNAPpapers
SNAPpapers is for those who want to sport their love and support for SNAP. Application credit goes to spiicytuna with wallpapers by Shift. It will work on any version of CM6, even if you don't have a SNAP kernel installed.
You install SNAPpapers just like any other .apk and use it by long press on the home screen, selecting wallpapers, and clicking SNAPpapers. For those unsure on how to install SNAPpapers: download a versions below and simply do an "adb install c:\path\to\snappapers.apk" or download an installer from the Market and install the SNAPpapers.apk from your sdcard.
v0.0.5 Changelog
New Snap Graphix themed wallpapers
Includes everyone's favorite Timeless Classic wallpapers (a la Lady in Red & Grunges)
Known Issues
Link to SNAP thread is not clickable as of yet
Planned Updates
Clickable link(s) to SNAP thread
Live wallpapers
v0.0.3 Changelog
Some wallpapers from v1 & v2 modified as per request
More wallpapers, including pics graciously provided by kpoz
known issues
Link to SNAP thread is not clickable as of yet
Planned Updates
Clickable link(s) to SNAP thread
More requested wallpapers
Live wallpapers
???
Downloads
Click to expand...
Click to collapse
SNAPwidget
The SNAPwidget is a widget created by our own spiicytuna for use with snap kernels that utilize H/AVS. It will not work on non-snap h/avs kernels. You install this just like any other .apk and
use it just like any other widget--ie. long press on the home screen. For those unsure on how to install SNAPwidget: download a version below and simply do an "adb install c:\path\to\Widget.apk" or download an installer from the Market and install the SNAPwidget.apk from your sdcard.
The goal of SNAPwidget is to provide easy access to H/AVS adjusted voltage at any given CPU frequency. The widget also displays the current battery draw in mA; red for discharging, and green for charging. Testing has shown no noticeable loss of battery with SNAPwidget when using update intervals of greater than 15 seconds; even with logging enabled.
**Please note that the frequency and temperatures displayed may not match setCPU. Rest assured that SNAPwidget has been triple checked and it's information is exactly the same as what the kernel/EVO is providing.
v0.0.5 Changelog
FIXED: bug that widget showed o[email protected]
Planned Updates
Additional skins/colors (post suggestions to thread)
Downloads
Click to expand...
Click to collapse
Click to expand...
Click to collapse
Version 7.5 BFS/UV/OC/nHAVS
v7.5 is built from the CM6 2.6.32.15 source. It incorporates the latest BFS Scheduler-v0.330, overclocking to 1.19g, netarchy's modified HAVS [nHAVS], and my modified conservative governor.
There have been some mixed results with v8.x kernels. Some people have charging issues, some don't. Some people have screen tearing issues, some don't. While 2.6.34 issues continue to be sorted out, I decided to release a known stable version with the latest BFS/nHAVS implementation.
Known Issues
Testing revealed a down threshold of approximately 40 for the conservative governor to yield the best screen interaction. You can set this value in the advanced tab in SetCPU.
Since the introduction of AVS, some users see bootloops after installing. The known fix is to wipe dalvik. Since moving away from the ultra-undervolt kernels, I have yet to see a bootloop on my device. YMMV--if you encounter a bootloop, wipe dalvik.
This kernel is not as fast as v8.x. It's not because anything is wrong, it's because it is an older kernel revision. Please do not fill up the thread complaining about quadrant scores. For reference, I saw [email protected] vs [email protected] on v8.x
v7.5 Changelog
Set the maximum CPU freq to 1.19. Many people were able to run 1.22g, but there is no practical benefit to doing it, so 1.19 is the new max across all revisions.
Minimum UV is 925. I've found this value to be the most stable and best for my battery.
Added BFS v0.330
Built with CM-6.0.0 ramdisk. Works great on the first official CM6.
Legacy snap tweaks to filesystem, network, vm, etc..
Tweaked conservative governor timings
Downloads:
cm6-snap-v7.5-havs925 Download md5 bcdb177c62b51542e450ce2e620fea45
Click to expand...
Click to collapse
Version 8.2/BFS/U-UV/OC/nHAVS
v8.2 is built from Toastcfh's 2.6.34 source. It incorporates the BFS Scheduler, Overclocking to 1.19g, and netarchy's modified HAVS [nHAVS].
With BFS enabled, we're seeing quadrant scores approaching 2000 @ 1.19g. Stock frequencies (998mhz) routinely achieve 1500-1600.
Known Issues
Some phones have demonstrated difficulty charging via AC. So far, I've been unable to replicate the issue. I'll keep an eye out for updates and apply anything that looks relevant.
In-line headset buttons don't work. I patched 8.2 with the latest HTC Headset driver, but I don't believe this fixed the problem.
Led Flashlight - Toast commented that Torch didn't light the led flashlight on github. I have not experienced this problem. Two tools I've used (torch and switchpro widget) both light the camera leds just fine on my phone.
Conservative CPU governor is the default in v8.1 and it does not appear to log the correct minimum CPUFreq in kmsg so the snap widget will continually report 384mhz. You can check the actual frequency with:
Code:
adb shell s.getfreq
This should show you 245mhz if your phone is idle. If this really bothers you, switch to interactive as your default.
v8.2 Changelog
IPv6 added (Google Goggles fix)
Set the maximum CPU freq to 1.19. Many people were able to run 1.22g, but there is no practical benefit to doing it, so 1.19 is the new max across all revisions.
Added BFS
Regulator patch from toast's github
Built with CM-6.0.0 ramdisk. Works great on the first official CM6.
Fixed 802.11n - works again
Legacy snap tweaks to filesystem, network, vm, etc..
Tweaked conservative governor timings
Downloads:
cm6-snap-v8.2-havs800 Download md5 45a9428cf556d4d44d16dbb295b41d23
cm6-snap-v8.2-havs825 Download md5 5f207d52e44878b8fdae78fc541e8db9
cm6-snap-v8.2-havs850 Download md5 668f0eb6115c68e980b37a0867c867c9
cm6-snap-v8.2-havs875 Download md5 618b4c4c2dbff49ce5bf7816b054af3e
cm6-snap-v8.2-havs900 Download md5 7fd5a621592f4775ed971ce19ec71057
cm6-snap-v8.2-havs925 Download md5 262c5a836e75ac0643f7115fd7d5f853
Click to expand...
Click to collapse
Version 8.1/U-UV/OC/nHAVS
v8.1 is built from Toastcfh's 2.6.34 source. It incorporates netarchy's modified HAVS [nHAVS] introducing the ability to specify the maximum and minimum voltage range at every frequency step. This differs from the original implementation of HAVS which only permitted specifying the maximum voltage at a given step. By incorporating a minimum we still benefit from voltage scaling, but it provides a little human intervention to prevent AVS from trying to undervolt too far.
This first v8.1 release uses an 850mv floor. With the more stable implementation of HAVS, I have high hopes that it addresses some of finicky behavior we've seen with previous revisions. My preference is to start reducing the number of versions in each release which is why this first version is U-UV or UltraUnderVolt.
This is a significantly faster kernel out of the box than .32.
Known Issues
Led Flashlight - Toast commented that Torch didn't light the led flashlight on github. I have not experienced this problem. Two tools I've used (torch and switchpro widget) both light the camera leds just fine on my phone.
Conservative CPU governor is the default in v8.1 and it does not appear to log the correct minimum CPUFreq in kmsg so the snap widget will continually report 384mhz. You can check the actual frequency with:
Code:
adb shell s.getfreq
This should show you 245mhz if your phone is idle. If this really bothers you, switch to interactive as your default.
I will closely monitor toast's github for updates to address this and other remaining minor issues.
v8.1 Changelog
Added Static version of Snap 8.1. This build eliminates nHAVS and uses stock frequency/voltage scaling. For those of you unable to find a stable nHAVS implementation, this one is for you.
Removed 1.22g in havs825. We've gone back and forth with 1.22 in various revisions of snap, but I've come to the conclusion that downside outweighs upside. So 1.19g will be the new max in snap going forward.
Fixed 802.11n and Wifi AP.
Merged netarchy's HAVS from .32 enabling specification of min/max AVS voltages at each frequency step.
Built with CM-6.0.0 ramdisk. Works great on the first official CM6.
Fixed 802.11n - works again
Fixed 1.22g - confirmed working
Legacy snap tweaks to filesystem, network, vm, etc..
Removed - Added OC up to 1.22
Tweaked conservative governor timings
Downloads:
cm6-snapv8.1-static.zip/OC Download md5 30485362938e2c586d6abc4b67479487
cm6-snap-v8.1-havs825/OC Download md5 5b4949ab11c81ffb30e107a3dcbce0b0
cm6-snap-v8.1-havs850/OC Download md5 99955f8d1a6eaeb98ffa7d578717cb73
cm6-snap-v8.1-havs900/OC Download md5 8fc3b56f0a50d1dfae4e80715a9abc5d
Click to expand...
Click to collapse
Version 7.4 HAVS/OC/UV
The 7.4-havs kernel incorporates BFQ and AVS. After spending some quality time discussing HAVS with intersectRAVEN, this release should work on most phones. If it doesn't work for your phone, let me know in the thread and we'll try to sort it out. v7.4 is a minor update from v7.3 below focused on enabling stable Hybrid AVS. BFQ from v7.3 is also included, but I took it out of the kernel name because it's also now a standard feature in CM6.
About AVS
Code:
Adaptive Voltage Scaling (AVS) for ARCH_MSM_SCORPION
The AVS driver adjusts the CPU voltage based on hardware feedback. Using
hardware feedback AVS is able to achieve lower voltages than the equivalent
static voltage scaling (SVS) voltage.
The Scorpion architecture includes three ring oscillators for AVS. The
ring oscillators provide real time feedback about the voltage requirements
for the current operating conditions. The hardware can sense when the voltage
can be lowered and needs to be raised.
The AVS software keeps track of the current operating conditions. Periodically
AVS queries the hardware. Every query AVS updates a table of required voltage
indexed by operating conditions, CPU frequency and temperature.
This first release uses 975mv as the floor voltage based on intersectRaven's test results from his work on the N1. The current release plan for 7.4 includes:
UV - 975 - Available now
UV - 875 - Available now
UV - 825 - Available now
Version 7.4-havs Changelog
Modified conservative CPU governor set as default. Modifications designed to reduce scaling lag.
HAVS implemented with min voltages set to 975mv in -havs975 and 875mv in -havs875
Known Issues
Do not reboot your phone with adb reboot. Use the power button and reboot/power off from within the phone. Using adb reboot causes HAVS minimum voltages to stay at the maximum specified in the AVS voltage table. This will cause battery drain equivalent to stock kernels.
If you get a bootloop after installing one of the v7.4 kernels, reboot into recovery and wipe dalvik/cache. That generally fixes things.
Downloads:
cm6-snap-v7.4-havs975/OC/UV Download md5 d121ee63c9f147dcadd91ebd1626fa83
cm6-snap-v7.4-havs875/OC/UV Download md5 cb4ff35841eadc47651e19d24c7f64cf
Avoid this one unless you know what you're doing.
cm6-snap-v7.4-havs825/OC/UV Download md5 d138071715a7d5137622c57867f56271
A big thanks to intersectRaven for discussing AVS with me and clearing up some nagging problems!
Click to expand...
Click to collapse
Version 7.3-avs
The 7.3-avs kernel will be the only 7.3 option. I've decided against making a 7.3-noavs version because BFQ is not enough of a performance enhancement to warrant a new revision beyond 7.x1. So if you can't run AVS, I suggest you stick with 7.01 or 7.11. Version 7.3-avs incorporates BFQ and AVS (see codebox below).
** Note: The version numbers are known to be off in the betas.
Click to expand...
Click to collapse
Experimental zImages
Experimental zImages are provided only for those interested pushing their devices for even more performance. They are not intended as daily drivers, although some may find them perfectly acceptable as a daily driver.
I will not provide update.zips for experimental zImages so please don't ask. These zImages are intended for seasoned users who are comfortable restoring their phones and using fastboot.
Please see the readme in each download section for further information.
CFS Releases
v7.6cfs-havs800
v7.6cfs-havs825
v7.6cfs-havs850
v7.6cfs-havs875
BFS Releases
v7.6bfs-havs875
This zImage is identical to the production release of v7.6 except the undervolt floor has been dropped to 800/825/850/875 for 128 and 245mhz.
Download
Click to expand...
Click to collapse
Click to expand...
Click to collapse
EOL Revisions
cm6-snapv7.3beta1 (900mv) Download
cm6-snapv7.3beta3 (875mv) Download
cm6-snap-v7.3 AVS Final (875mv/tweaked conservative governor) Download
cm6-snap-v7.3-avs825 Download
cm6-snap-v7.3-avs850 Download
cm6-snap-v7.3-avs875 Download
cm6-snap-v7.3-avs925 Download
cm6-snap-v7.3-avs950 Download
cm6-snap-v7.01 Download
cm6-snap-v7.11 Download cm6-snap-v5.01 Download
cm6-snap-v5.11 Download
cm6-snap-v5.0 Download
cm6-snap-v5.1 Download cm6-snap-v4.0-cc Download
cm6-snap-v4.1-cc Download
cm6-snap-v4.0 Download
cm6-snap-v4.1 Download cm6-snap-v3 Download
Click to expand...
Click to collapse
Before proceeding, please run a nand backup!
Download and Install
You do not need to wipe. Just flash over your CM6 nightly builds.
If you are flashing nightly CM6 builds, you'll need to flash this kernel again after each nightly. Just flash your nightly build, reboot and make sure everything is working, then reflash your favorite snap kernel.
Click to expand...
Click to collapse
v8: Thanks to toastcfh for his tireless efforts getting .34 working on CM6 and to netarchy for a great job modifying HAVS for stability.
I need to thank netarchy, assassinslament, joeykrim, sentenced, ffolkes, spiicytuna, and of course toastcfh for helping me along the way. Special thanks to ffolkes and netarchy for their work on the 2.1 kernels which has made its way to CM6. They are an incredibly helpful and patient group, and this community is lucky to have them working for all of us. Thanks to Cyanogen for providing crucial tips during the development of snap, and the entire CyanogenMod crew for a wicked 2.2 ROM. Thanks to intersectRaven for the AVS code.
GPL Compliance and Credits
My github
Koush for this exceptionally clever AnyKernel Updater template.
v8.x is built from toastcfh's source.
v8.1 nHAVS merged from netarchy's HAVS source.
spiicytuna for SNAPwidget, SNAPpapers, and the upcoming SNAPturbo.
shift for the incredible graphics work.
v7.x and below snap kernels are built from the CM6 git source.
v7 and below AVS code imported from intersectRaven git source.
Click to expand...
Click to collapse
Donate!
Ok, I've been asked multiple times how to donate for my work on snap, so I added a button to my sig.
Great job. Just installed it and working fine so far.
Will update more later after I put all my apps back on.
Thank you for the tweaks.
will this help improve battery or drop it quicker lol sorry
What the hell,Ill give it a shot.
Sporkman said:
will this help improve battery or drop it quicker lol sorry
Click to expand...
Click to collapse
Try it and tell me. It certainly will not *improve* the battery life, but I don't expect the penalty to be material.
E: No signature (11 files)
E:Verification failed
Installation aborted.
Any advice? Does this need to be run off Clockwork?
Fps2d before was roughly 49 fps with a stdev in the high 7s
now its 53 fps avg with stdev=5.26
gears is chilling at 53-54 fps
quadrant is 1279.
This is all without setcpu.
TheMike1 said:
E: No signature (11 files)
E:Verification failed
Installation aborted.
Any advice? Does this need to be run off Clockwork?
Click to expand...
Click to collapse
Yes, I'm sorry, I should have mentioned it's unsigned. I'll update the OP.
J
Just flashed, novatek 003 -- getting fps2d 51 with StDev of 9 after several runs, which is actually a slight downgrade. My Long Bench in SetCPU is in the 600's vs the 300's as before.
LinPack is very strange. I get my usual 39-43 but every once in a while it seems to lag and I get 2MFLOPS - 6MFLOPS, not 20, literally 2.
I have a feeling something must not be right, is there anyway to debug what is going on?
Didn't change anything, just sat around and did a bunch of LinPacks, then noticed they were pretty consistent so went into SetCPU and started doing a bunch of Long Bench, and actually started to get into the low 400s consistently, high 300s. Back to fps2d and now I am getting 54 avg with a 5.5StdDev consistently.
Strange, I cannot figure out what changed, any idea?
edit: Just ran a 1571 Quadrant too
My SetCPU Current profile btw is 1152max, 245min performance
It helps to let the phone settle for a while before testing. When you first boot, it's pretty busy.
This kernal just put me back to 29 fps. With or without setcpu. ?? Mflops was 46 tops though
Sent from my PC36100 using XDA App
TheMike: How does that quandrant score compare to your stock ROM?
jmxp69 said:
TheMike: How does that quandrant score compare to your stock ROM?
Click to expand...
Click to collapse
I am getting 1575+ Consistently now, vs 1400-1530 with CM6 stock kernel.
My stock ROM was like a 500 quadrant or something
This is Awesome!!
HAHAH! I just got a 1620 Quadrant with your Kernel, my first time breaking 1600
Awesome Kernel man, thank you very much
Attempted to flash this kernel on top of baked pastries beta 2 with the 2.2 update and just got a boot loop. The nexus boot logo animated fast then slower then screen for a blank and starts all over again.
Sent from my PC36100 using XDA App
rmriggin said:
Attempted to flash this kernel on top of baked pastries beta 2 with the 2.2 update and just got a boot loop. The nexus boot logo animated fast then slower then screen for a blank and starts all over again.
Sent from my PC36100 using XDA App
Click to expand...
Click to collapse
This is based on CM6 rmriggin. Kernel update.zips contain ramdisks with rom specific information. So you can't do it that way. I could make the zImage, and modules available to you if you want to flash it with fastboot and manually copy the modules over. That would likely work.
J
If you want to experiment, this kernel may work on a non-CM6 or maybe even a 2.1 ROM with the following steps. I have no idea. Proceed at your own risk.
**Warning** Don't try this without a backup! You'll need to nandroid restore to undo this.
1) Download this and unzip on your PC (do not try to flash it).
adb shell reboot bootloader
fastboot boot zImage <-----this will let you test to see if it works. If it does, proceed with the following to survive reboot. If it doesn't work, just reboot your phone and you'll be back to normal. No other action required.
2) Move to a different directory from where you unzipped donotflash.zip and do the following:
adb pull /system/lib/modules/bcm4329.ko
adb pull /system/lib/modules/sequans_sdio.ko
Save these somewhere safe.
3) From the location you unzipped donotflash.zip:
adb remount
adb push bcm4329.ko /system/lib/modules/
adb push sequans_sdio.ko /system/lib/modules/
adb shell reboot bootloader
fastboot flash zimage zImage ** pay attention to the caps!
fastboot reboot
If you try this, I'd be interested in hearing about your results.
Thank you so much for this kernel, I ran my FPS2d app on the HTC EVO 4g running under the latest Cyanogen ROM and I get 54 AVG with 5.45 stdev...
It's a lot faster and I'll check about battery usage when I get a full charge overnight.
Thanks again!
Quick question.. I've flashed latest nightly today and I'm capped at 28~30 fps now.. and I flashed this kernel and still stuck at 30 fps.. can anyone tell me what might be causing this? Any help will be greatly appreciated.
Sent from my PC36100 using XDA App
mizerab1e said:
Quick question.. I've flashed latest nightly today and I'm capped at 28~30 fps now.. and I flashed this kernel and still stuck at 30 fps.. can anyone tell me what might be causing this? Any help will be greatly appreciated.
Sent from my PC36100 using XDA App
Click to expand...
Click to collapse
Do you have setCPU installed? If so, uninstall it, reboot, and see what happens.
I've created a simple app to display the time the CPU spends in each frequency state and the current kernel build. May be useful to some... especially people running OC'ed kernels.
Also useful to confirm which kernel you're currently running.
** DOWNLOAD **
Android Market Link
Error complaining about states file not found? See this post.
*** Thanks to Rainerd for the patch to help with the negative state percentages.
Change log
v0.4.0 beta
-Display total state time
-Massive code cleanup
-Fix duration overflow bug
-Removed read-as-root attempt when unable to access states file due to instability
-Slightly improved tablet support
v0.3.2 beta
-Pulled in fix from Rainerd to help with percentage mixups after reboot
v0.3.1 beta
-Small fix that may help with freezing issues with some custom ROMS
v0.3.0 beta
-Attempts to read time_in_state file as root in case reading is blocked by a custom ROM
v0.2.2 beta
-States are now sorted from highest to lowest frequency
v0.2.1 beta
-added "Deep Sleep" to states list for time when CPU is off
v0.2.0 beta
-Added "reset timers" option to set all state timers to 0 sec
-Added "restore timers" to show time-in-state since boot
-Small UI adjustments
-Timers now show hours
v0.1.0
-Initial market release
Click to expand...
Click to collapse
source: https://github.com/bvalosek/cpuspy
previous versions (source only): https://github.com/bvalosek/cpuspy/tags
Works great on my rooted stock KB1 with CogKernel 4.
Since I'm running stock KB1, the full kernel name doesn't show up under About Phone and I've been looking for an easy way to confirm which kernel I've got installed at the moment, especially when I'm jumping from kernel to kernel. This works well.
If you made a (transparent) widget that showed the kernel name, I'd be all over it.
This is nice, now you can see what MHz use less of the cpu and you can undervolt more on those specific speeds.
Works on setup in my sig. Useful tool! Thanks!
just out of curiosity this displays total time in state since bootup correct? not like since last unplugged or since last magic trick
*edit
btw bravo, gave ya 5 stars in market
Just installed, I'll try it out through out the day and see how things look.
This is incredibly useful, thanks!
[Request]
Very useful. Thanks mate.
Working on dilligaf's 7.x with dilli pickle kernel, glitterball's kernel and xcaliburinhand's 2.3.5 kernel.
Request:
Could u please add a "reset" feature, if possible, so it would be easier to get the time spent on each state when playing with maximum CPU speeds. Like I might set my max speed to 1000 from 1280 n want to check the time spent at 1000. Right now only a reboot is resetting the data.
Or, like my gut feeling says, is this app reading for this data from anywhere forcing a reboot if the data has to be reset.
diablo009 said:
Very useful. Thanks mate.
Working on dilligaf's 7.x with dilli pickle kernel, glitterball's kernel and xcaliburinhand's 2.3.5 kernel.
Request:
Could u please add a "reset" feature, if possible, so it would be easier to get the time spent on each state when playing with maximum CPU speeds. Like I might set my max speed to 1000 from 1280 n want to check the time spent at 1000. Right now only a reboot is resetting the data.
Or, like my gut feeling says, is this app reading for this data from anywhere forcing a reboot if the data has to be reset.
Click to expand...
Click to collapse
It's reading the data from:
/sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state
Which only gets set to zero at each reboot.
Great app!
works perfect on the setup in my sig.
Thanks!
rajendra82 said:
It's reading the data from:
/sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state
Which only gets set to zero at each reboot.
Click to expand...
Click to collapse
what I had expected
thanks for the info !
so it basically does the same for Android & a really nice GUI
like the console-app cpufreq-info on linux
thanks a lot for coding that app, storm717 !
for me it probably will show 100 MHz for most of the time (due to powersave set in screen-off state) - it's however nice to know what frequency the CPU will spend most of its time in while it's on (the 2nd and 3rd most-used frequency) & dedicating some more UV-stability testing towards that frequency
others that don't use the powersave governor will surely find it even more useful
Handy Tool
Definitely a handy tool to have.
Quick, easy info without with command line for those who really want to know what's going on under the hood quickly and easily.
I did a fly by here this morning and it looks as though word is getting out about this.
Good show..
Peace-
LOL at those people saying "Works with setup in my sig!"... like you don't change that setup in your sig 5 times a month... You're gonna confuse all of the people that find this thread next week/month/year/decade/century.
Thanks for the cool app tho. Really do 'preciate it bra, should help UV'ing this sucker.
Awesome, this is exactly what I was looking for. Thanks!
Great job, man.
Working great on the Vibrant CM7 kernel.
Thanks again!
Glad you guys like it!
Updated to v0.2.0 in the Market -- added the reset timers features a few of yall requested. "reset timers" does what you'd think and "restore timers" returns them to show the time in each state since boot.
storm717 said:
Glad you guys like it!
Updated to v0.2.0 in the Market -- added the reset timers features a few of yall requested. "reset timers" does what you'd think and "restore timers" returns them to show the time in each state since boot.
Click to expand...
Click to collapse
Now that is what I call above and beyond.....thank you. Leaving app now and going to web site just to hit your button.
The time readouts in 0.2.0 are getting wrong after I keep the phone running for a long time. Here is the output from the file:
File:
1600 0
1500 0
1400 17001
1300 0
1200 8537
1120 0
1000 27348
900 0
800 434348
600 212601
400 149584
200 152861
100 561535
By the time I took this reading my phone has been up about 13 hours. The sum of all the values is 1563815, which seems to indicate that the values in each state are in terms of 1/33.33 seconds. This appears to be different than when the phone runs for a short time, when the values in the file seem to be in terms of 1/100 of a second. At some point the system must be making a switch to how it records, unless I am interpreting the numbers wrong, and the older times are getting discarded, and the sum has nothing to do with up time. CPU Spy still thinks that the values are in 1/100 of a second, and gives time in 1400 state as 0:2:50, and total of all states as 4:20:38. This can be avoided if the sum of the states values is checked against up time to come up with what the current unit of measurement is.
rajendra82 said:
The time readouts in 0.2.0 are getting wrong after I keep the phone running for a long time. Here is the output from the file:
File:
1600 0
1500 0
1400 17001
1300 0
1200 8537
1120 0
1000 27348
900 0
800 434348
600 212601
400 149584
200 152861
100 561535
By the time I took this reading my phone has been up about 13 hours. The sum of all the values is 1563815, which seems to indicate that the values in each state are in terms of 1/33.33 seconds. This appears to be different than when the phone runs for a short time, when the values in the file seem to be in terms of 1/100 of a second. At some point the system must be making a switch to how it records, unless I am interpreting the numbers wrong, and the older times are getting discarded, and the sum has nothing to do with up time. CPU Spy still thinks that the values are in 1/100 of a second, and gives time in 1400 state as 0:2:50, and total of all states as 4:20:38. This can be avoided if the sum of the states values is checked against up time to come up with what the current unit of measurement is.
Click to expand...
Click to collapse
I'll look into this tonight, but I think this is the correct behavior. The CPU goes into a deep sleep mode after a while and effectively shuts off waiting for external input or something interesting to happen. If this is the case I may add a "deep sleep" row to clarify.
app works as its states. i'm running phoenix ultimate, speedMod K13D, great job man
Introducing RebelKernel for all variants of the Moto E4 'perry' device. Upstreamed to the latest linux-stable 3.18 tag and loaded with features and optimizations. The aim of this kernel is to make the User Experience as smooth and efficient as possible, while also bringing in features like DoubleTap2Wake (DT2W), KCAL (advanced color control processing), and USB OTG that help bring this budget phone on par with mid-end devices.
A lot of testing has been done to get this kernel stable, however there is always a chance that flashing this kernel could leave something not working correctly. Please take logs (dmesg and ramoops) in this event and send them to me.
Features:
* Linux-stable: 3.18.63 -> 3.18.134
* F2FS Loopback Bug patched
* LZ4 Compression
* CPU Input Boost driver
* KCAL color control driver
* DT2W driver
* Boeffla Wakelock Blocker driver
* Wireguard Support
* XPad Rumble and LED support
* USB OTG Native support
* USB HID Keyboard support
* Cmdline flags removed to pass SafetyNet
* Toolchain: GCC 4.9.4 --> Linaro 7.4.1
* I/O Schedulers: Zen, Maple
* Governors: Electron, Zzmoove, Lionfish
* Hotplugs: Alucard
* GPU: Adreno Idler, Adreno Boost
* TCP: Westwood
* FSync On/Off
* Swappiness: 15
* VFS Cache Pressure: 10
* Drastically reduced logging overhead and spam
* Migrated many workqueues to Power Efficient WQs
Installation:
1) BACKUP. Always have a recent system backup when flashing anything.
2) Download the zip from the link below and flash from TWRP.
3) If you get bootloops or issues, please take kernel logs and logcats (if booted) and report back so I can address the issue.
Please give feedback. A lot of work is being put into this kernel so I hope it improves your experience.
Download:
Version: 2.0
https://mega.nz/#!M6J2ESiZ!xUpI5yQvhpta3TSWr_MQQYmi-xFhiEEJa_JnGBIfdww
Source:
* Branch 'rebel'
https://github.com/RebelLion420/kernel_perry
Credits:
@squid2
@facuarmo
@jasonmerc
*** While donating is not required to use my work, it is certainly appreciated. Thanks in advance!
https://paypal.me/rebelliouslion
Note:
I posted this on XDA to bring attention to my project, but I will not be regularly updating this thread. You can find the active thread on Android Forums
androidguy99 said:
Why? I had nothing to do with this
Click to expand...
Click to collapse
I removed the mention, I just felt that you contributed to the project as a whole. Also, I was stumped until you posted trees for us and then I got building again since I broke my last repo lol. But as you wish
Damn, with all those features you almost made me wish I still had my e4
Almost
Very nice work @RebelLion_
This kernel is extremely fluid and responsive. The baked in KCAL works great with Kernel Adiutor-Mod in customizing the display contrast & vibrance with the presets included in the app. No noticeable lags or instabilities. Wonderful work. Thank you for your contributions and hard work.
AeonFlux1603 said:
Very nice work @RebelLion_
This kernel is extremely fluid and responsive. The baked in KCAL works great with Kernel Adiutor-Mod in customizing the display contrast & vibrance with the presets included in the app. No noticeable lags or instabilities. Wonderful work. Thank you for your contributions and hard work.
Click to expand...
Click to collapse
I'm glad you like it, it was a lot of hard work lol. Don't forget to turn on DT2W in Kernel Adiutor 'Gestures' as well, and look through all the settings to see everything that's included. I know CPU Input Boost is disabled by default and requires a little tuning to get right. I have it set to boost to 1094 for 250 ms, which might not be as big of an improvement I hoped for since there are only 4 clock frequencies for the cpu to cycle through. But I'm working on fixing that too if it's possible for this device
jasonmerc said:
Damn, with all those features you almost made me wish I still had my e4
Almost
Click to expand...
Click to collapse
Almost is good enough lol
RebelLion_ said:
I'm glad you like it, it was a lot of hard work lol. Don't forget to turn on DT2W in Kernel Adiutor 'Gestures' as well, and look through all the settings to see everything that's included. I know CPU Input Boost is disabled by default and requires a little tuning to get right. I have it set to boost to 1094 for 250 ms, which might not be as big of an improvement I hoped for since there are only 4 clock frequencies for the cpu to cycle through. But I'm working on fixing that too if it's possible for this device
Click to expand...
Click to collapse
1094 MHz for 250ms appears to give a nice little boost when the load gets heavy. If you can improve upon that, you are a beast indeed. I have also set DT2W in Kernel Adiutor as you advised. And the Gesture settings....Wow!!
Don't cut yourself short with this nice piece of work. If you never added another mod, I would continue using this kernel over bone stock any day. I'm with zeal to see such a dedicated and skilled dev on this device. My many thanks are most sincere.
Out of curiosity, is this kernel compiled using the latest upstream sources?
Wow! I'm glad you finally got it working. Thanks for giving me some credits (although I'm more or less just a cherry-pick machine lel), I'll get an eye on this thing, probably even grab some patches for the msm8916 repo and maybe I'll send a PR at some point .
Been using this kernel since it's beta releases and it's amazing. I love the work put into this!
---------- Post added at 01:53 PM ---------- Previous post was at 01:51 PM ----------
Yes it is. As far as I know
AeonFlux1603 said:
1094 MHz for 250ms appears to give a nice little boost when the load gets heavy. If you can improve upon that, you are a beast indeed. I have also set DT2W in Kernel Adiutor as you advised. And the Gesture settings....Wow!!
Don't cut yourself short with this nice piece of work. If you never added another mod, I would continue using this kernel over bone stock any day. I'm with zeal to see such a dedicated and skilled dev on this device. My many thanks are most sincere.
Out of curiosity, is this kernel compiled using the latest upstream sources?
Click to expand...
Click to collapse
Yes it is
Your kernel fixed my sd card storage access problem! After unlocking/no-verity'ing, some apps couldn't access sdcard storage (Google Maps and Here Maps were a few). Your kernel allows them to finally access sd card storage perfectly! What did you do? Thank you!
---------- Post added at 04:41 PM ---------- Previous post was at 04:35 PM ----------
Follow up question: this new kernel eliminates the need for dm-no-verity, correct?
@RebelLion_, I wanted to let you know also that the Lionfish CPU governor is absolutely amazing. Handles heavy loads with ease.
zahna said:
Your kernel fixed my sd card storage access problem! After unlocking/no-verity'ing, some apps couldn't access sdcard storage (Google Maps and Here Maps were a few). Your kernel allows them to finally access sd card storage perfectly! What did you do? Thank you!
---------- Post added at 04:41 PM ---------- Previous post was at 04:35 PM ----------
Follow up question: this new kernel eliminates the need for dm-no-verity, correct?
Click to expand...
Click to collapse
I would think @RebelLion_ removed dmverity in his kernel.
If he has, definitely list that in your features dude. If not, that's a great (fairly straightforward) feature to add.
Noice work bro
madbat99 said:
I would think @RebelLion_ removed dmverity in his kernel.
If he has, definitely list that in your features dude. If not, that's a great (fairly straightforward) feature to add.
Noice work bro
Click to expand...
Click to collapse
@madbat99, I decompiled this kernel with an image kitchen; the ramdisk appears to have AVB/dm-verity set to disabled. Also, force encryption seems to be set to opt-encrypt. And, to note, I am using this kernel on my CDMA xt1766 "SPerry," and I've experienced no adverse issues or problems.
Very nice. An updated kernel with f2fs loopback bug patched is great news for this device. Magisk with no extra junk. (F2fs loopback bug workaround)
madbat99 said:
Very nice. An updated kernel with f2fs loopback bug patched is great news for this device. Magisk with no extra junk. (F2fs loopback bug workaround)
Click to expand...
Click to collapse
Amen @madbat99. Nice to use a root file explorer without kernel panic/dead lock. The Alucard hotplug on this kernel is solid as well. Man, this is just an all around badass piece of work. Excellent. Hey @madbat99, do you know if there are any CPU/SoC differences between the SPerry & the Perry?
madbat99 said:
Very nice. An updated kernel with f2fs loopback bug patched is great news for this device. Magisk with no extra junk. (F2fs loopback bug workaround)
Click to expand...
Click to collapse
OP fixed the F2FS bug as well?!? I didn't even think to check on that! IMO, his kernel has saved the Moto E4.
Now I'm wondering if this kernel has also fixed the echo cancellation problem with 3rd party ROMs...
AeonFlux1603 said:
Amen @madbat99. Nice to use a root file explorer without kernel panic/dead lock. The Alucard hotplug on this kernel is solid as well. Man, this is just an all around badass piece of work. Excellent. Hey @madbat99, do you know if there are any CPU/SoC differences between the SPerry & the Perry?
Click to expand...
Click to collapse
Small difference. Snapdragon 425 and Snapdragon 427
madbat99 said:
Small difference. Snapdragon 425 and Snapdragon 427
Click to expand...
Click to collapse
Ahh. I see. Makes sense then that the custom kernel works for both chipsets. Thank you.
Awesome kernel @Rebellion. Definitely appreciate your work on this. Just wondering though, is safetyNET supposed to pass by default with this kernel installed or do I need to do any additional steps to make it pass?
[email protected]@bl3s said:
Awesome kernel @Rebellion. Definitely appreciate your work on this. Just wondering though, is safetyNET supposed to pass by default with this kernel installed or do I need to do any additional steps to make it pass?
Click to expand...
Click to collapse
I know you directed this question to OP, but on my device (xt1766 Boost Mobile), running latest stock Android 7.1.1 Nougat (NCQS26.69-64-11)with OP's kernel, SafetyNet passes ctsProfile & basicIntegrity on Stable Magisk v18.1 -- by default and without any additional patches, mods or tweaks.
---------- Post added at 11:01 PM ---------- Previous post was at 10:15 PM ----------
@RebelLion_,I know you're probably tired of hearing my two cents, but I just wanted to inform you that I've tested all aspects of your kernel, and I have encountered no bugs or instabilities. I'm running debloated & Magisk rooted stock from this thread (NCQS26.69-64-11) with your kernel, with no additional Magisk Modules or mods. I'm using the Lionfish CPU governor with 960 MHz minimum and 1401 MHz maximum clocks; the Alucard Hotplug, I/O Busy, 65% Sampling Rate, 4 maximum cores online, GPU Adreno Idler, 20 Down Differential, 15 Idle Wait, 7 Workload, Vomer BrightBalance Color Profile w/ KCAL, DT2W Halfscreen, SoC Sound Drivers High Performance Mode, I/O Scheduler Maple 512kb Read Ahead for Internal Storage, Add Random enabled, I/O Stats enabled, RQ Affinity 2, Low Memory Killer set to Very Aggressive, Virtual Memory Dirty Ratio 20%, Dirty Background 5%, Dirty Expire Centisecs 200cs, Dirty Writeback Centisecs 5200cs, Overcommit Ratio 50%, Swappiness 100%, VFS Cache Pressure 9, Laptop Mode enabled, 2500kb Min Free, 10,800kb Extra Free, 510 MB Z-RAM Disksize, Entropy 64 Read, 128 Write; SELinux set Permissive, Westwood TCP Congestion Algorithm, FSync & Android Logging enabled.
Under normal to light use, my CPU averages around a 7% workload, whereas extremely heavy to heavy use (gaming, multitasking) will never average more than about 53% workload consumption.
Compared to unmodified stock, this kernel definitely improves upon responsiveness and overall performance on both normal and heavy usage. I'm seeing a 2 - 3 hour increase in battery life on the settings I referenced in comparison to the pure stock kernel. Also, during normal use, I'm seeing around 750 - 800 MB free RAM on average.
Hey everyone! Hope you're all doing fine. I just updated to Android 10, coming from AICP Pie, and I noticed that battery life took a serious hit compared to AICP. Now I know that AICP (and probably many other custom ROMs) use EAS by default, which could be credited for the great performance and battery life you get with these setups. This didn't stop me from conducting some tests and experimenting with some changes in order to try and improve the battery life I am getting on Android 10 (and possibly all previous versions of the stock ROM). Anyway, without further ado, here is a script that tweaks the phone a little, which should improve your phone's battery life on STOCK ROMs, mainly Android 10 but it is also applicable to Android 9, though I have mainly tested it on Android 10 and the deprecated developer previews and beta builds of Android 10. A link to download the script is provided down below, right below the prerequisites and instructions.
Prerequisites
1- An Essential PH-1 (of course!)
2- Magisk (make sure to have the latest version installed)
3- A terminal emulator app -- I use this one here:
https://play.google.com/store/apps/details?id=jackpal.androidterm
4- Any file manager app.
Instructions
1- Download the script from the link below.
2- For more convenience, move the script you just downloaded to the root of your internal storage (/sdcard) using any file manager if your choice.
3- Open the terminal emulator app.
4- Type "su" (without the quotes) and hit the enter/return key on your keyboard to grant it root access (Magisk could display a pop-up window asking whether you want to grant this app root access. Make sure to tap in Grant. This usually happens once).
5- Afterwards, type "sh /sdcard/essential-tweaks" (without quotes) and hit the enter/return key on your keyboard to execute the script.
6- Voila! You're done!
--> In case you think the script has caused any regressions your are dissatisfied with, simply reboot your phone since this script doesn't automatically get applied on boot.
--> In case you rebooted your phone and wish to re-apply the script, simply follow the same instructions again.
Download
G Drive: https://drive.google.com/file/d/101Z_Co7uVU_h2blanJ88MV8x9PpRcOvg/view?usp=drivesdk
Let me know your thoughts down below. Cheers!
Reserved
Reserved 2
Sounds interesting and I'd like to try it. I don't know if you know this though, but the file on Google Drive is set to "ask permission" to download it.
Tanner1294 said:
Sounds interesting and I'd like to try it. I don't know if you know this though, but the file on Google Drive is set to "ask permission" to download it.
Click to expand...
Click to collapse
Fixed. Sorry for inconvenience. Thanks for letting me know!
#justgoogledrivethings
Mostafa Wael said:
Hey everyone! Hope you're all doing fine. I just updated to Android 10, coming from AICP Pie, and I noticed that battery life took a serious hit compared to AICP. Now I know that AICP (and probably many other custom ROMs) use EAS by default, which could be credited for the great performance and battery life you get with these setups. This didn't stop me from conducting some tests and experimenting with some changes in order to try and improve the battery life I am getting on Android 10 (and possibly all previous versions of the stock ROM). Anyway, without further ado, here is a script that tweaks the phone a little, which should improve your phone's battery life on STOCK ROMs, mainly Android 10 but it is also applicable to Android 9, though I have mainly tested it on Android 10 and the deprecated developer previews and beta builds of Android 10. A link to download the script is provided down below, right below the prerequisites and instructions.
Prerequisites
1- An Essential PH-1 (of course!)
2- Magisk (make sure to have the latest version installed)
3- A terminal emulator app -- I use this one here:
https://play.google.com/store/apps/details?id=jackpal.androidterm
4- Any file manager app.
Instructions
1- Download the script from the link below.
2- For more convenience, move the script you just downloaded to the root of your internal storage (/sdcard) using any file manager if your choice.
3- Open the terminal emulator app.
4- Type "su" (without the quotes) and hit the enter/return key on your keyboard to grant it root access (Magisk could display a pop-up window asking whether you want to grant this app root access. Make sure to tap in Grant. This usually happens once).
5- Afterwards, type "sh /sdcard/essential-tweaks" (without quotes) and hit the enter/return key on your keyboard to execute the script.
6- Voila! You're done!
--> In case you think the script has caused any regressions your are dissatisfied with, simply reboot your phone since this script doesn't automatically get applied on boot.
--> In case you rebooted your phone and wish to re-apply the script, simply follow the same instructions again.
Download
G Drive: https://drive.google.com/file/d/101Z_Co7uVU_h2blanJ88MV8x9PpRcOvg/view?usp=drivesdk
Let me know your thoughts down below. Cheers!
Click to expand...
Click to collapse
Neat...
A kranel tweaker...
In my opinion:
The damn powerhint is probably the worst offender to battery...
Currently, with magisk, I just remove /vendor/etc/powerhint.xml
I am also using kernel touchboost so I can idle down to 300...
If your battery doesn't suck... You can switch back to 518 and 806 for minimum frequencies, disable msm touchboost, and kill the powerhint... And get MUCH closer to where you were with AICP on Pie
rignfool said:
Neat...
A kranel tweaker...
In my opinion:
The damn powerhint is probably the worst offender to battery...
Currently, with magisk, I just remove /vendor/etc/powerhint.xml
I am also using kernel touchboost so I can idle down to 300...
If your battery doesn't suck... You can switch back to 518 and 806 for minimum frequencies, disable msm touchboost, and kill the powerhint... And get MUCH closer to where you were with AICP on Pie
Click to expand...
Click to collapse
Is that similar to disabling perfd?
Because that is what I did (and incidentally what my script does).
Thanks a lot for your suggestion!
Mostafa Wael said:
Is that similar to disabling perfd?
Because that is what I did (and incidentally what my script does).
Thanks a lot for your suggestion!
Click to expand...
Click to collapse
No sir...
The powerhint has something to do with the PowerHals directly...
You'll notice if you watch any frequency monitor that when you touch the screen... It jumps to 1.1Ghz on both big and little ... That's NUTS...
It also will run the processor at 1.9 and 2.5 for 5 seconds on app launch... Also CRAZY and unnecessary
Perfd controls the profiles in /vendor/etc/... I think there's 8 of em...
And like mpdecision before it... It sucks...
On a side:
I've been on Q since beta 2... And have put together a magisk module that cuts frequencies down... 1.8 Max for little and 2.0 for big... Kills perfd... Kills the powerhint by replacing with a 0 byte file... Ups zram to 1 GB... And puts touchboost to 825 and 499...
I just incorporated your scheduler changes and I'll let you know what I come up with...
If you're interested in the module ... I'll share it .. just let me know
Edit: @KuranKaname approves the frequency choices BTW
rignfool said:
No sir...
The powerhint has something to do with the PowerHals directly...
You'll notice if you watch any frequency monitor that when you touch the screen... It jumps to 1.1Ghz on both big and little ... That's NUTS...
It also will run the processor at 1.9 and 2.5 for 5 seconds on app launch... Also CRAZY and unnecessary
Perfd controls the profiles in /vendor/etc/... I think there's 8 of em...
And like mpdecision before it... It sucks...
On a side:
I've been on Q since beta 2... And have put together a magisk module that cuts frequencies down... 1.8 Max for little and 2.0 for big... Kills perfd... Kills the powerhint by replacing with a 0 byte file... Ups zram to 1 GB... And puts touchboost to 825 and 499...
I just incorporated your scheduler changes and I'll let you know what I come up with...
If you're interested in the module ... I'll share it .. just let me know
Edit: @KuranKaname approves the frequency choices BTW
Click to expand...
Click to collapse
Yes I know about the max frequency values. These used to be the default in Kuran's AICP too
Interesting, so you mean to say that this is completely different from perfd? Well, I only disabled perfd and I am not seeing the phone jumping back to 1.1GHz while interacting with the screen or locking on max frequencies while launching apps.
Also, what command are you using to disable perfd on Q? I just found out that the usual "stop perfd" command is not working anymore like it used to on Pie :/
I used EXKM to disable it and it works just fine :good:
Let me know if my sched tweaks bring any further improvements to you. Cheers!
EDIT: these input boost frequency values used to be the ones Sultanxda go for too iirc right?
Mostafa Wael said:
Yes I know about the max frequency values. These used to be the default in Kuran's AICP too
Interesting, so you mean to say that this is completely different from perfd? Well, I only disabled perfd and I am not seeing the phone jumping back to 1.1GHz while interacting with the screen or locking on max frequencies while launching apps.
Also, what command are you using to disable perfd on Q? I just found out that the usual "stop perfd" command is not working anymore like it used to on Pie :/
I used EXKM to disable it and it works just fine :+1:
Let me know if my sched tweaks bring any further improvements to you. Cheers!
Click to expand...
Click to collapse
Interesting ..
stop perfd
getprop|grep perfd yields the service has stopped for me
rignfool said:
Interesting ..
stop perfd
getprop|grep perfd yields the service has stopped for me
Click to expand...
Click to collapse
Weird. I will check again when I am home.
Thanks for chiming in! :highfive:
Mostafa Wael said:
Weird. I will check again when I am home.
Thanks for chiming in! :highfive:
Click to expand...
Click to collapse
Interesting... I just put back the powerhint... While stopping perfd and now it's listening ... I wonder if I came up with that when I had the typo in my script...
Thanks for forcing me to debug...
---------- Post added at 02:30 PM ---------- Previous post was at 02:18 PM ----------
Mostafa Wael said:
Weird. I will check again when I am home.
Thanks for chiming in! :highfive:
Click to expand...
Click to collapse
OHHHH...
Are you using service.d to run your script?
If so... You need
while [ "$(getprop sys.boot_completed)" != 1 ];
do sleep 1;
done
sleep 5
Before... Otherwise init gonna reset your stuff...
And post-fs-data.d is WAAY too early
So I have been doing a lot of tracing and testing some new changes and, well, I think it is very difficult to squeeze any more battery life on stock ROMs. Which means that it is highly unlikely that this script is going to be updated with new additions as this is practically the best we could reach at the moment. However, I will keep digging deep and see if I can come up with any updates.
To put things into perspective, here is a quick comparison with the default stock ROM tunings.
By default, I would get an average active drain of 14%/h per charge cycle, peaking at 16%/h
After applying this script the average active drain rate would drop to around 12-13%/h, peaking at 15%/h.
In other words, there is around 1-2%/h improvement in active drain rate as per my usage.
Idle drain rate is fairly similar though.
Mostafa Wael said:
So I have been doing a lot of tracing and testing some new changes and, well, I think it is very difficult to squeeze any more battery life on stock ROMs. Which means that it is highly unlikely that this script is going to be updated with new additions as this is practically the best we could reach at the moment. However, I will keep digging deep and see if I can come up with any updates.
To put things into perspective, here is a quick comparison with the default stock ROM tunings.
By default, I would get an average active drain of 14%/h per charge cycle, peaking at 16%/h
After applying this script the average active drain rate would drop to around 12-13%/h, peaking at 15%/h.
In other words, there is around 1-2%/h improvement in active drain rate as per my usage.
Idle drain rate is fairly similar though.
Click to expand...
Click to collapse
hello. Thanks for your work. It's nice and works very well.
How I can add this script to autorun?
P.S. Here is screenshots of my battery life after tweaks
@Mostafa Wael Hey mate, do you remember what the experiment was that you wanted to do recently ?
Was meant to help with smoothness and battery on Android 10?
St.Noigel said:
hello. Thanks for your work. It's nice and works very well.
How I can add this script to autorun?
P.S. Here is screenshots of my battery life after tweaks
Click to expand...
Click to collapse
I really don't have any idea, I just run then every time after boot via terminal emulator ?
CamoGeko said:
@Mostafa Wael Hey mate, do you remember what the experiment was that you wanted to do recently ?
Was meant to help with smoothness and battery on Android 10?
Click to expand...
Click to collapse
Well, it was a desperate attempt by me to try and squeeze more juice on Android 10 custom ROMs, not sure it will work out on stock ROM. Basically, I am experimenting with different values for the cpusets and stune settings of each cgroup.
I'm still evaluating whether it has a significant impact or not. So far, it is almost the same...
Mostafa Wael said:
Well, it was a desperate attempt by me to try and squeeze more juice on Android 10 custom ROMs, not sure it will work out on stock ROM. Basically, I am experimenting with different values for the cpusets and stune settings of each cgroup.
I'm still evaluating whether it has a significant impact or not. So far, it is almost the same...
Click to expand...
Click to collapse
If you're running Artemis... You're wasting you're time...
Military Dictator @KuranKaname does not allow for the powerhal to accept adjustments from stune other than what HE deems required ...
You MIGHT be able to adjust scheduler values and have them mean something ...
rignfool said:
If you're running Artemis... You're wasting you're time...
Military Dictator @KuranKaname does not allow for the powerhal to accept adjustments from stune other than what HE deems required ...
You MIGHT be able to adjust scheduler values and have them mean something ...
Click to expand...
Click to collapse
Cpuset and stune values are open (besides the top-app stune boost)
I'm using elementalx kernel on android 10 nov update, and my battery drain in deep sleep is unusually high at 2 - 2.5% per hour.
I'm wondering if this script conflicts with anything with the kernel.
I took a look at the script and it looks like some of the settings I can apply in the kernel manager.
A11 & A11 - use v16
A13 - use v16
Hey Coral / Flame Gang!
First off, I'm glad to be here. I just came from Pixel 2 XL after my phone died from hardware issues and I needed to upgrade!
Anyway, here's a script that I put together for my own use, but still develop occasionally; tuned especially for our Coral / Flame devices.
Enjoy!
The Back-Story:
I helped some good guys out with developing the awesome Franco.Kernel tuning parameters "back in the day" (Franco's Dev Team - you can look us up, the great osm0sis still hosts the original file set - but they won't even run on Android Pie or later). What is still applicable to Android 12 is in this file; trimmed and consolidated into a single script, along with some other goodies I've come across since.
Philosophy:
- I don't write untested BS or questionable crap in my scripts. If a given tweak doesn't show an objective improvement in benchmarks or battery life or a subjective improvement in performance that can be turned on or off by running or not running the script in a blind test - it doesn't get added.
- If I do not believe a given tweak is safe to run on everyone's daily driver device, I also won't include it my script, regardless of the benefit.
- This script is biased toward increasing performance - but it takes advantage of battery saving opportunities that don't affect performance.
Notes:
- This script is lean and mean, but it's not rocket science.
- I didn't invent anything here. Feel free to use it (or not), distribute, alter, whatever; to your satisfaction, giving credit for redistribution only to "Franco's Dev Team", and maybe me if you're feeling generous.
- I have verified it works well on my personal Pixel 4 XL, and is compatible with all Android versions, Kernels, and Magisk versions applicable to the device.
- It won't make your phone run any worse, and it should make it feel a bit "snappier", but YMMV.
- Most benchmark scores improve marginally (1% - 4%) on my device with stock or EX kernel. Again, YMMV.
- I do not plan to do heavy maintenance on this, but I will keep it up to date so it at least safely runs on the Pixel 4 / 4 XL as long as I own one. I will post updates with a minimal change log (it's a script, you can read it!). If I stumble across something that helps the community, I'll share it!
Disclaimer:
I can't see how this could possibly cause irreparable harm to any Android device on which it is run.
However, I suppose untested configurations may (rarely) have slow-downs, reboots, or other effects.
REGARDLESS, it is offered as-is with no warranty, and you choose to run this at your own risk.
If you do encounter issues, let me know and stop using the script. I may ask you for further help with debugging.
Requirements:
Root
BusyBox installation (I recommend the Magisk module by osm0sis)
Knowledge of how to execute a linux script and/or where to place it and allow permissions to run on boot
Usage:
Download the linked file to your device
Copy it to /data/adb/service.d
Ensure permissions are correct (0755)
Reboot and wait a three minutes
NOTE: The script will generate a text file called "pksp4_script_result" in the base of your "external storage" directory (/storage/emulated/0). This file will state either "Success!" or "Failure..." indicating if the script completed at the last execution attempt (it will over-write each time the script is run - check the date/time stamp on the file properties) .
Credits:
Franco's Dev Team, esp. osm0sis
Others as noted in the script file header
94pksp4v16.sh
Shared with Dropbox
www.dropbox.com
94pksp4v17.sh
Shared with Dropbox
www.dropbox.com
Change Log
V17 (use for A13)
- Audited script against A13 to ensure compatibility
- Script timing edits to support successful execution on A13 with Magisk 24 (especially ZRAM)
V16 (use for A11 and A12):
Fixed V15!
- Delayed and slowed ZRAM change to enhance the reliability of it "taking" on each boot
- Made Adrenoboost and power-efficient work queues contingent on those modules actually existing in the user's kernel
- (Did the same with the wakelock blocker while I was at it)
- Fixed a script typo that was the likely root-cause of V15 not running to completion or outputting "failure" for some users.
V15:
Enabled power-efficient work queues by default (most kernels have this functionality built in)
Enabled GPU Adrenoboost module by default, set to low boost (many kernels have this available, on/low seems preferred for a slight / smooth gaming boost without battery life detriment)
Changed vm.vfs_cache_pressure to 50 (was 200, wrong-direction from 100, I now believe after more testing)
Changed vm.dirty_ratio to 10 (from 20; avoids latency when having to write-out data to disk asynchronously by halving the amount of data needing to be written; this could reduce occasional "hang-up's" you may have experienced on this device regardless of kernel or mod - including stock!)
V14:
Increased ZRAM capacity by 50% to 3 GB
Turned off TCP timestamps to reduce overhead
Adjusted VM settings for having more memory
Added a couple minor VM tweaks
Added a minor kernel scheduler tweak
Minor code clean-up and re-ordering
V12:
Small core schedutil up/down rate limit tweaks, making small cores more responsive to increasing frequency and maintaining higher frequencies a bit longer. This should keep more load on small cores / reduce offloading to big cores unless big core utilization is truly necessary. I noted a little less latency and a little better battery life in my testing.
V11:
REMOVED.
V10:
Welcome to 2021.
Minor update - now bbr2>bbr>westwood (depends on what your kernel offers) for TCP congestion control algorithm. As an aside, I reconfirmed txquelen of 512 is still optimal for modern wifi and lte networks.
V9:
Happy holidays!
Added some TCP and kernel cfs tweaks that reduce device latency.
V8:
Stable, slightly improved Android 11 release.
Minor CFQ tunable tweaks that very slightly improved IO in benchmark testing.
Now blocks a single wakelock: qcom_rx_wakelock (if your personal philosophy is to never block any wakelocks, feel free to comment that line out in the script).
Changed TCP congestion avoidance algorithm to BBR2 (if available in kernel) - else, Westwood; based on network speed testing (BBR2 > Westwood > BBR).
V7:
Removed mount tweaks - they no longer do anything useful
Increased DBR slightly
Modified write-out file to not list time/date (for some reason it was being written twice on R). Just look at the file properties in your file manager to see when it was last written, if needed.
V6 is deprecated: Use V7 for R, V5 for Q
V6:
- Updated for Android 11 B1, verified to run without outputting any errors and is 100% stable.
- Removed one schedutil tweak that is no longer available on A11.
- Reverted kernel entropy settings to stock; tweaked settings were no longer increasing entropy pool.
- Users on A10 may use v6 without any issues, but v5 will still provide very slightly better performance on A10.
V5:
- A minor kernel overhead reduction from scheduler statistics
- Force CFQ as scheduler (just in case non-stock kernel isn't already set that way)
- Two CFQ tweaks, one that eliminated backward seeking penalty (makes no sense on non-rotational storage) and one that my testing showed sped up throughput and in theory should also reduce latency (so a true win-win!).
V4:
- Reverted foreground app schedtune boost, swappiness, vfs_cache_pressure, and dirty_ratio to stock
- Reverted IO scheduler to CFQ
- Removed wakelock blocking - verified no / minimal effect on deep sleep (I got 0.12%/hr idle drain overnight)
(for all of the above, thanks to @Freak07 for the advice / education!)
- Re-verified tx_queue_len (512) and tcp_congestion_control (westwood+) are optimized for WiFi and LTE networks
V3:
- Remove fstrim commands for /data and /cache since device is F2FS and fstrim doesn't apply (thanks to @woundman for pointing this out to me)
- Changed to Deadline scheduler with Franco Dev Team tunables - I just verified still benchmarks better after all these years
- If your kernel does not have Deadline available (e.g. stock kernel), the script will still keep you on Noop, as before.
V2:
- Reduce schedutil downrate limit to increase battery life.
- Block some safe wakelocks to increase battery life.
- Oh yeah, and a magic trick to turn off vm dirty write back timer (it still happens, just memory based and not every 5 seconds), to also increase battery life.
V1:
- Initial Pixel-4/XL release.
ooh interesting! would this play nice with the blackened mod found in this forum?
pwnsicle said:
ooh interesting! would this play nice with the blackened mod found in this forum?
Click to expand...
Click to collapse
I wouldn't recommend you to mix stuff together because it can introduce values that conflicts with each other to some possible very random extent. Though it's your device - try it out and report back with accurate feedback on how it does perform.
:highfive:
I use this Script with fsociety Kernel 1.27 and it works fine.
Thx for it
Gesendet von meinem Pixel 4 XL mit Tapatalk
Welcome to the Pixel 4 XL community. Also coming from the Pixel 2 XL as well, looking forward to testing this out. ?
I'm on flame using this script and seems to work fine here.
It feels a bit snappier.
Thanks for your work.
Welcome brother... Nice to see another Taimen dev jump into the pool here!
I'm on p4 with kiri, so good so far, let's see how will this improve battery life, thanks
Running great on fsociety!)
Stock ROM only? Or will it work in pixeldust too.
pwnsicle said:
ooh interesting! would this play nice with the blackened mod found in this forum?
Click to expand...
Click to collapse
It should. My script runs after BlakenedMod, so you'll get most of xFirefly93's battery savings, with a little bit of the PK snappiness.
xFirefly93 said:
I wouldn't recommend you to mix stuff together because it can introduce values that conflicts with each other to some possible very random extent. Though it's your device - try it out and report back with accurate feedback on how it does perform.
:highfive:
Click to expand...
Click to collapse
See above. Should be fine to run both... might even be best for some users! Let us know if it doesn't work!
MarcoG: said:
I use this Script with fsociety Kernel 1.27 and it works fine.
Thx for it
Gesendet von meinem Pixel 4 XL mit Tapatalk
Click to expand...
Click to collapse
Glad to hear it!
Curiousn00b said:
Welcome to the Pixel 4 XL community. Also coming from the Pixel 2 XL as well, looking forward to testing this out.
Click to expand...
Click to collapse
Thanks. Hope you like it!
2WildFirE said:
I'm on flame using this script and seems to work fine here.
It feels a bit snappier.
Thanks for your work.
Click to expand...
Click to collapse
Glad to hear it - it should...
CyberpodS2 said:
Welcome brother... Nice to see another Taimen dev jump into the pool here!
Click to expand...
Click to collapse
Thanks! Great to see you again, too. Athouth, technically, I'm not a Dev
bl4dy_pt said:
I'm on p4 with kiri, so good so far, let's see how will this improve battery life, thanks
Click to expand...
Click to collapse
Probably won't help much, but I'm working on some improvements for V2 (probably tomorrow or the day after!)
FlatOutRU said:
Running great on fsociety!)
Click to expand...
Click to collapse
Thanks for letting me know!
chopt51 said:
Stock ROM only? Or will it work in pixeldust too.
Click to expand...
Click to collapse
Any ROM!
New Version - V2
A little Sunday night treat!
V2 available in OP, change log in 2nd post.
Better battery life as I tune this in for Pixel 4/XL...
Any testing with kirisakura's kernel? You said not to mix things
I see your script runs Fstrim. I thought Fstrim doesn't work on F2FS system partitions. Figured I'd mention it.
tlxxxsracer said:
Any testing with kirisakura's kernel? You said not to mix things
Click to expand...
Click to collapse
It should work on any kernel... I've used on on stock and EX on Pixel 4, but I used it on kirisakura on my previous Pixel 2 XL device. If there are any issues, let me know.
woundman said:
I see your script runs Fstrim. I thought Fstrim doesn't work on F2FS system partitions. Figured I'd mention it.
Click to expand...
Click to collapse
Thanks for the heads-up. Running the fstrim command doesn't return any errors, so the script is "safe" to use, but if it's not actually doing anything on the device, I'll remove it in a future release.
woundman said:
I see your script runs Fstrim. I thought Fstrim doesn't work on F2FS system partitions. Figured I'd mention it.
Click to expand...
Click to collapse
AFAIK - only the /data partition is using the "newer" f2fs filesystem on the three latest Pixel line-ups..
xFirefly93 said:
AFAIK - only the /data partition is using the "newer" f2fs filesystem on the three latest Pixel line-ups..
Click to expand...
Click to collapse
Looks like you're right.
That said, I stopped trimming /System to be safe once Android went SAR, and /Cache is sym-linked to another partition anyway. So, I don't think the commands are actually doing anything anymore - at least not anything useful since /cache isn't really used for much on newer Android versions.
I'll be removing the fstrim commands starting with the next version. In the meantime, it's not really hurting anything.
Thanks for the mod. How can one confirm if this is actually running?
sharpz811 said:
Thanks for the mod. How can one confirm if this is actually running?
Click to expand...
Click to collapse
Look for the log as in the pic. Then view it with your text viewer. It should say script successful :good: