Re: [KERNEL][4.2.x] Fancy Kernel (r7) (FEB-23-2013)
Try to install r7 version
Enviado desde mi Galaxy Nexus usando Tapatalk 2
Try to install r7 version
Enviado desde mi Galaxy Nexus usando Tapatalk 2
[KERNEL] Fancy Kernel r60 [Android JB+KK] [F2FS/EXT4] [Linux 3.0.101+] [OCT-24-2014]
- Thread starter boype
- Start date
What causes WOD issues? Usually SOD (Sleep of death) issues arises from voltages being too low (from my understanding). Correct me if I am wrong. Going to flash this over Leankernel 6, phone gets too hot during a call...
AW: [KERNEL][4.2.x] Fancy Kernel (r7) (FEB-23-2013)
Yes, I forgot about the tethering problems back then... But losing WEP was a huge problem for some users too, which have to use this insecure protocol for compatibility reasons.
R7 runs great here, I really like the performance, options and battery life of this kernel! :good:
Yes, I forgot about the tethering problems back then... But losing WEP was a huge problem for some users too, which have to use this insecure protocol for compatibility reasons.
R7 runs great here, I really like the performance, options and battery life of this kernel! :good:
Last edited:
W-Fi drivers sound promising, just to ensure if they will work on 4.2.1 - not everyone is aimed on cutting edge like AK
I think sticking to the 3.0 Wifi driver is the way to go. I favor stability over experimental stuff...Yes, I forgot about the tethering problems back then... But losing WEP was a huge problem for some users too, which have to use this insecure protocol for compatibility reasons.
R7 runs great here, I really like the performance, options and battery life of this kernel! :good:
Really enjoying fancy r7. Battery life is consistently excellent just like previous releases. I've recently been retesting my phone's limits for custom undervoltage with MPU=OFF. I last ran tests 1.5 months ago on franco kernel on 4.2.1. It seems that I can run my phone with more undervoltage now! There's enough difference from SmartReflex to give some noticable battery life improvements. With screen-on use, there's about 1-2% less battery consumption per hour. Including regulator undervoltage, it ends up being about 2-4% less battery per hour.
These are the current voltages I've been using, stable so far. CORE and IVA are left at default with SR=ON.
These are the current voltages I've been using, stable so far. CORE and IVA are left at default with SR=ON.
Code:
//Fancy r7 kernel on liquidjb-v2.1-rc1 4.2.2) with trickster mod
//MPU SR-OFF ([freq]: volt_setting||~volt_measured --- "" Fancy's_stock_with_SR-ON)
[1420]: 1200||~? --- 1275||~1270
[1228]: 1150||~? --- 1225||~1210
[1036]: 1050||~? --- 1150||~1110
[729]: 890||~? --- 1050||~990-1000
[537]: 860||~? --- 900||~890
[384]: 810||~? --- 850||~850
[192]: 780||~? --- 800||~800
//Regulator (UV'd---Fancy stock---[default stock])
VAUX3_6030: 2500---3100---[3100]
VMMC: 1200---1800---[1800]
R: [KERNEL][4.2.x] Fancy Kernel (r7) (FEB-23-2013)
Thank you so much!! I'm trying your settings and so far they're extremely stable!
Cheers!!
Sent from my Galaxy Nexus
Thank you so much!! I'm trying your settings and so far they're extremely stable!
Cheers!!
Sent from my Galaxy Nexus
You can try ondemandplus with these two tuneables:
echo 30 > /sys/devices/system/cpu/cpufreq/ondemandplus/down_differential
echo 1 > /sys/devices/system/cpu/cpufreq/ondemandplus/inter_staycycles
Or you can tweak interactive to be a little more aggressive...
Knowledge base: ondemandplus guide
This post serves as additional information about ondemandplus and its variables. It is linked to the OP's knowledge-base.
ondemandplus is an ondemand- and interactive-based governor that has additional power-saving capabilities while maintaining very snappy performance. While the interactive governor provides a modern and sleek framework, the scaling logic has been been re-written completely.
Basics about the governor's scaling logic
When the screen is on: First of all, the governor checks the CPU load for the currently set CPU frequency during the last timer cycle. If the CPU load (measured in percent) is higher than the up_threshold, the governor will increase the CPU frequency. Originally in plain ondemand, the CPU frequency is immediately increased to the maximum supported frequency. If the CPU load is lower than up_threshold - down_differential, the governor will decrease the CPU frequency. The frequency to scale down to is calculated like this: (current CPU frequency * CPU load) / up_threshold - down_differential.
In ondemandplus, the downscaling behavior is only very slightly modified. However, the upscaling has been modified to not scale up to maximum frequency immediately. By means of the inter_lofreq, inter_hifreq and inter_staycycles sysfs variables, upscaling is 'dampened' to save battery - a kind of 'barrier' is set, which first has to be breached. For example: inter_lofreq is 729 MHz, inter_hifreq is 1036 MHz and inter_staycycles is 3. This will result in the following behavior when a frequency increase is triggered: In the first timer cycle with high CPU load, the frequency will be set to inter_lofreq (729 MHz). If the load remains high in the next timer cycle, the frequency will be further increased to inter_hifreq (1036 MHz). If the CPU load is still high, inter_hifreq is kept until the inter_staycycles value is reached. In this example, the CPU has been scaled up twice so far, so one more timer cycle of high CPU load is necessary to scale to the maximum CPU frequency. And now - as already indicated - after the a third timer cycle with high CPU load, inter_hifreq can finally be left behind for higher CPU frequencies.
The sysfs variable staycycles_resetfreq merely controls when the staycycle counter is reset to 0, thus effectively re-applying the 'barrier'. So, if staycycles_resetfreq is set to 500 MHz (which equals a sysfs value of 500000), the upscaling barrier is re-established when the CPU is scaled down below 500 MHz.
Information added June 17, 2013: Ondemandplus now uses an algorithm to dynamically set the timer_rate in order to save battery in low- and constant-load-scenarios. The way the governor does this is simple but effective:
Each 5 timer cycles, the governor checks the last 5 requested CPU frequencies and calculates the average of them. When the next requested CPU frequency is within a 15% range of this average, the timer_rate is throttled. This only counts for all CPU frequencies below the inter_lofreq. For frequencies above inter_lofreq, the next requested CPU frequency has to match the average exactly to throttle the timer_rate.
When the next requested frequency is not close enough to the average anymore, the timer_rate is set back to its normal value.
When the screen is off: CPU scaling is way simpler when the screen is off. When the CPU load is higher than up_threshold, the governor will simply scale up to the next-highest frequency. Of course, it can not be scaled to a higher CPU frequency than the maximum screen-off frequency.
Downscaling works pretty much the same way. When the CPU load is below up_threshold - down_differential, the next lower CPU frequency will be the target.
Governor sysfs tuneables and their effects
timer_rate: The interval in microseconds in which the CPU load is measured. If set to 30000 for example, there will be a check (and maybe a frequency change if necessary) every 0.030 seconds.
up_threshold: If the measured CPU load is higher than this value, the governor will scale the frequency up. Value is in percent. Higher values can cause slower upscaling and maybe slight lags.
down_differential: If the measured CPU load is lower than up_threshold - down_differential, the governor will scale the frequency down. Lower values will cause faster downscaling.
inter_lofreq: The first intermediate frequency to scale to if the CPU load is high.
inter_hifreq: The second intermediate frequency to scale to if the CPU load is high. Can be equal to inter_lofreq.
inter_staycycles: The amount of timer cycles under consistently high CPU load that are necessary to be able to finally scale up to the maximum CPU frequency. 1 timer cycle equals the timer_rate value. If set to 0, the intermediate frequencies are not used, instead the governor will scale up to the maximum CPU frequency immediately.
staycycles_resetfreq: When the CPU frequency goes below this value, the timer cycle counter (counting the high-load-cycles until inter_staycycles is reached) is reset to 0. This effectively re-establishes the intermediate frequency barrier. Value cannot be set higher than inter_lofreq.
This post serves as additional information about ondemandplus and its variables. It is linked to the OP's knowledge-base.
ondemandplus is an ondemand- and interactive-based governor that has additional power-saving capabilities while maintaining very snappy performance. While the interactive governor provides a modern and sleek framework, the scaling logic has been been re-written completely.
Basics about the governor's scaling logic
When the screen is on: First of all, the governor checks the CPU load for the currently set CPU frequency during the last timer cycle. If the CPU load (measured in percent) is higher than the up_threshold, the governor will increase the CPU frequency. Originally in plain ondemand, the CPU frequency is immediately increased to the maximum supported frequency. If the CPU load is lower than up_threshold - down_differential, the governor will decrease the CPU frequency. The frequency to scale down to is calculated like this: (current CPU frequency * CPU load) / up_threshold - down_differential.
In ondemandplus, the downscaling behavior is only very slightly modified. However, the upscaling has been modified to not scale up to maximum frequency immediately. By means of the inter_lofreq, inter_hifreq and inter_staycycles sysfs variables, upscaling is 'dampened' to save battery - a kind of 'barrier' is set, which first has to be breached. For example: inter_lofreq is 729 MHz, inter_hifreq is 1036 MHz and inter_staycycles is 3. This will result in the following behavior when a frequency increase is triggered: In the first timer cycle with high CPU load, the frequency will be set to inter_lofreq (729 MHz). If the load remains high in the next timer cycle, the frequency will be further increased to inter_hifreq (1036 MHz). If the CPU load is still high, inter_hifreq is kept until the inter_staycycles value is reached. In this example, the CPU has been scaled up twice so far, so one more timer cycle of high CPU load is necessary to scale to the maximum CPU frequency. And now - as already indicated - after the a third timer cycle with high CPU load, inter_hifreq can finally be left behind for higher CPU frequencies.
The sysfs variable staycycles_resetfreq merely controls when the staycycle counter is reset to 0, thus effectively re-applying the 'barrier'. So, if staycycles_resetfreq is set to 500 MHz (which equals a sysfs value of 500000), the upscaling barrier is re-established when the CPU is scaled down below 500 MHz.
Information added June 17, 2013: Ondemandplus now uses an algorithm to dynamically set the timer_rate in order to save battery in low- and constant-load-scenarios. The way the governor does this is simple but effective:
Each 5 timer cycles, the governor checks the last 5 requested CPU frequencies and calculates the average of them. When the next requested CPU frequency is within a 15% range of this average, the timer_rate is throttled. This only counts for all CPU frequencies below the inter_lofreq. For frequencies above inter_lofreq, the next requested CPU frequency has to match the average exactly to throttle the timer_rate.
When the next requested frequency is not close enough to the average anymore, the timer_rate is set back to its normal value.
When the screen is off: CPU scaling is way simpler when the screen is off. When the CPU load is higher than up_threshold, the governor will simply scale up to the next-highest frequency. Of course, it can not be scaled to a higher CPU frequency than the maximum screen-off frequency.
Downscaling works pretty much the same way. When the CPU load is below up_threshold - down_differential, the next lower CPU frequency will be the target.
Governor sysfs tuneables and their effects
timer_rate: The interval in microseconds in which the CPU load is measured. If set to 30000 for example, there will be a check (and maybe a frequency change if necessary) every 0.030 seconds.
up_threshold: If the measured CPU load is higher than this value, the governor will scale the frequency up. Value is in percent. Higher values can cause slower upscaling and maybe slight lags.
down_differential: If the measured CPU load is lower than up_threshold - down_differential, the governor will scale the frequency down. Lower values will cause faster downscaling.
inter_lofreq: The first intermediate frequency to scale to if the CPU load is high.
inter_hifreq: The second intermediate frequency to scale to if the CPU load is high. Can be equal to inter_lofreq.
inter_staycycles: The amount of timer cycles under consistently high CPU load that are necessary to be able to finally scale up to the maximum CPU frequency. 1 timer cycle equals the timer_rate value. If set to 0, the intermediate frequencies are not used, instead the governor will scale up to the maximum CPU frequency immediately.
staycycles_resetfreq: When the CPU frequency goes below this value, the timer cycle counter (counting the high-load-cycles until inter_staycycles is reached) is reset to 0. This effectively re-establishes the intermediate frequency barrier. Value cannot be set higher than inter_lofreq.
Last edited:
UV
Awesome. Everyone needs to understand that not all chips and boards are equal. What works with on one may not on others. Mine goes lower in some, but I keep some points higher for stability with certain apps:
Compared to yours, more conservatively on the higher frequencies, and more aggressively on lower frequencies, and more conservative regulator. No SOD and as I mentioned in the earlier days fancy release, this kernel can tolerate UV much better than others.
These are UV values that I've kept from earlier releases. r7 seems to be even more tolerant
---------- Post added at 10:24 AM ---------- Previous post was at 10:16 AM ----------
Boype, great writeup.
What are the default values of the above tuneables? I understand if you don't want to document them if you think they might change from one release to the next.
Awesome. Everyone needs to understand that not all chips and boards are equal. What works with on one may not on others. Mine goes lower in some, but I keep some points higher for stability with certain apps:
Code:
MPU
[1420]: I don't use
[1228]: 1180
[1036]: 1060
[729]: 940
[537]: 820
[384]: 780
[192]: 720
Regulator
VAUX3_6030: 2600
VMMC: 1300
Core
v1, v2, v3 - fancy stock
v4 820
IVA
v1, v2 - fancy stock
v3 1090
v4 820Compared to yours, more conservatively on the higher frequencies, and more aggressively on lower frequencies, and more conservative regulator. No SOD and as I mentioned in the earlier days fancy release, this kernel can tolerate UV much better than others.
These are UV values that I've kept from earlier releases. r7 seems to be even more tolerant
---------- Post added at 10:24 AM ---------- Previous post was at 10:16 AM ----------
Boype, great writeup.
What are the default values of the above tuneables? I understand if you don't want to document them if you think they might change from one release to the next.
You can check them with either a file browser under the path /sys/devices/system/cpu/cpufreq/ondemandplus/ or you can take a look at lines 88 - 115 at https://github.com/boype/kernel_tuna_jb42/blob/fancykernel/drivers/cpufreq/cpufreq_ondemandplus.c
Re: [KERNEL][4.2.x] Fancy Kernel (r7) (FEB-23-2013)
new trickstor mod
http://d2tvn.com/thuanle/trickster/TricksterMOD_20130225.apk
Sent from my Galaxy Nexus using xda premium
new trickstor mod
http://d2tvn.com/thuanle/trickster/TricksterMOD_20130225.apk
Sent from my Galaxy Nexus using xda premium
Nice APK, can I ask how the ADB over WiFi is controlled ? I'd like to add a toggle widget for that in my app.
You should have link to the G+ post.
You need to call three commands in order to do that:\
Code:
setprop service.adb.tcp.port <x>
stop adbd
start adbdwith x is either the port number or blank string to start adb wireless on x port or stop adb wireless respectively.
The toggles widget in Trickster is a donated feature.
was r6 good then? or r5? There's one thing I have in mind that may cause this behavior. However, everything is good on my end with r7
was r6 good then? or r5? There's one thing I have in mind that may cause this behavior. However, everything is good on my end with r7
It will be unfair to compare because r7 is the only version I've used with 4.2.2. The previous versions was on 4.2.1.
The 4.2.2 stock kernel was really snappy for me, but it lacked the battery life I find in Fancy.
It's weird though that you are not experiencing any lag. What rom are you using?
Similar threads
Top Liked Posts
-
There are no posts matching your filters.
-
598
Hi and welcome to fancy kernel. My name is Boy Petersen and I'm building this kernel with the following three main goals: good battery life, reliability and a smooth and snappy user experience.
Feature list:
Download links:
Notes:
- Compatible to:
- all Galaxy Nexus devices (maguro, toro, toroplus)
- all Android 4.2, 4.3, 4.4 based ROMs
- both EXT4 and F2FS filesystems
- Installation:
- Flash the provided zip file with TWRP or CWM. If you're in doubt which file (fixed RAMdisk or anykernel2) is the right one for you, read this post
- Having problems? Please give informative feedback, so that I or other users can understand what exactly is wrong and under which circumstances.
Changelog:
Knowledge-base:
Chit-chat:
Credits for code: Cyanogenmod, Google, kernel.org, Texas Instruments
bsmitty83, edoko, Ezekeel, faux123, franciscofranco, gokhanmoral, gwindlord, Huexxx, imoseyon, mpokwsths, osm0sis & Franco Dev Team, TeamHorizon
Credits for the Fancy Updater app: Parthipan Ramesh
Credits for the logo/artwork: DaNi_!
Source (including defconfig and RAMDISK): https://github.com/boype/kernel_tuna_kk44
A shout-out to the donators who help me pay the file hosting and buy me beer: 1haumann1, aaamador, agritux (2x), akaria, Bastian L., bigknowz, Blackcrx, creeve4, Fabio A., Ferhat Uğur C., James F., jsage, kuyam, Lancez, mpokwsths, n2rjt, nailz420 (2x), okanb3, omid900, rcozzi, Taomyn, teleplasma
Do you like my work? Hit 'thanks' and/or rate this thread with 5 stars.
Has my work improved your user experience? Consider a small donation.
Please do not PM me with questions, post in the thread instead.
XDA:DevDB Information
[KERNEL] Fancy Kernel r60 [Android JB+KK] [F2FS/EXT4] [Linux 3.0.101+] [OCT-24-2014], Kernel for the Samsung Galaxy Nexus
Contributors
boype
Kernel Special Features:
Version Information
Status: Stable
Current Stable Version: r60
Stable Release Date: 2014-10-24
Created 2014-10-12
Last Updated 2014-10-2487r35 up
Hi all,
after a very sunny week on the beach I finally got to build and release r35. Even though I did not post very much in the thread, I followed all the comments. r35 is pretty similar to pre35-06, which was reported to run really good. Here's the change log:
- updated Linux to version 3.0.86
- reverted "lowmemorykiller: Use asynchronous compaction when killing processes" (fixes SODs that were introduced with r34)
- introduce Tuna optimized VMSPLIT of 2.5G/1.5G (what I used to call 'memory mapping optimization')
- updated LZO compression to current upstream version
- reverted a few commits that may have been responsible for higher battery drain
- re-introduced 3.4 lowmemorykiller (rest of the staging driver stays 3.0 though!)
- RAMdisk: fix interactive boostpulse permissions (thx to franco-c)
- RAMdisk: tweak TCP buffer sizes the AOSP way (thx to franco-c)
Best regards!86Hey folks, it's been some time since I last checked in here.
First of all: sorry for my long absence, but many things in my life changed and this was a classic 'first things first' situation for me.
I have moved to a new city, got a good job and had to do many things that go along with these things.
Second: thanks to charamacas for posting a few updates on my situation here.
I'm planning on making an update on the upcoming weekend. for the sake of kitkat compatibility and boosting the sources to the latest Linux version, that is. Probably I'll also implement some new stuff that was introduced elsewhere while I was away, I'll try to find out what is a good addition and think about it.
I'm currently still on cm10.2 from mid-september and have not rebooted my phone for over a month
Best,
boype79r32 up
Hi all,
r32 is now available. Here's the change log:
- updated to Linux 3.0.83
- enable trim_override to allow >= 1.4Ghz frequencies without lagging the device (credits to francisofranco)
- removed simple GPU governor (it wasn't working as it should. You can still pick from 307, 384 and 512 MHz like you can on other kernels)
- several mostly power management related fixes and also a cache tweak from Texas Instruments
- SIOplus/deadline: Allow 0ms deadline latency
- implement temperature control (extended version only; credits to imoseyon)
- WiFi drop workaround improvement (no need to disable / enable WiFi manually anymore)
- switched compiler toolchain to Linaro Android GCC 4.7 (current version: 13.05)
- few other things
As you can see, I switched the toolchain. While I said earlier that Google's toolchain is supposed to be very stable, Linaro's should be equally stable. Plus it gives builds with better performance (e.g. in some 3D applications) and is updated more frequently.
Enjoy and best regards!78r44 (Android 4.4)
Hi all,
it has arrived Change log:
- updated kernel tree and RAMdisk from Cyanogenmod repo for Android 4.4 compatibility
- updated Linux to 3.0.101
- change default governor to interactive (it's an awesome governor and is maintained by google on a regular basis)
- slightly modified default colors, since I came to notice there was a green tint
- BIGMEM: increase GFX VRAM to stock 16MB again (apparently less problems for bigmem versions; this was already there in the pre-44 versions)
- removed standalone busybox binary from RAMdisk. Therefore, it is absolutely necessary to have a ROM with busybox pre-installed (all custom ROMs have this, even most stock ROM repacks)
Note: I assume it is compatible with all Android 4.4 ROMs, but I only tested with CM11. Reports for compatibility on other ROMs are welcome.
I'm currently pushing the new sources to github... Should not take too long, since my upload is 10 times higher than before
I might also be building an updated 4.3 version in the following days - but we'll see about that.
Merry christmas to all of you (at least to those who actually celebrate it) - Compatible to:
New posts
-
[ROM][OFFICIAL][hotdogb][14] LineageOS 21
- Latest: SickCuriosity
-
