5,595,339 Members 47,969 Now Online
XDA Developers Android and Mobile Development Forum

[KERNEL] Fancy Kernel r49 [Android 4.2/4.3/4.4] [Linux 3.0.101] [APR-13-2014]

Tip us?
 
RAD1XS
Old
#381  
Member
Thanks Meter 7
Posts: 53
Join Date: Feb 2011
Default Re: [KERNEL][4.2.x] Fancy Kernel (r7) (FEB-23-2013)

Quote:
Originally Posted by AznInertia View Post
One issue that I am having on r6 is that I get a WOD issue (wake of death). Sometimes when I initially boot up my phone it gets stuck on lock screen and I must do a battery pull. As always I always do a dalvik flash / cache before moving to any new kernel.
Try to install r7 version

Enviado desde mi Galaxy Nexus usando Tapatalk 2
Android Devices: Samsung Galaxy I5500 >> Motorola Defy >> Samsung Galaxy Nexus

 
AznInertia
Old
#382  
Senior Member
Thanks Meter 57
Posts: 431
Join Date: Jun 2010
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...
 
gwindlord
Old
#383  
gwindlord's Avatar
Senior Member
Thanks Meter 137
Posts: 376
Join Date: Oct 2012
Location: Minsk
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
The Following User Says Thank You to gwindlord For This Useful Post: [ Click to Expand ]
 
Fenvarien
Old
(Last edited by Fenvarien; 24th February 2013 at 12:47 PM.)
#384  
Fenvarien's Avatar
Senior Member
Thanks Meter 310
Posts: 593
Join Date: Dec 2010
Default AW: [KERNEL][4.2.x] Fancy Kernel (r7) (FEB-23-2013)

Quote:
Originally Posted by anarkia1976 View Post
Franco have removed 3.4 driver because breaking tethering, no for wep authentication (obsolete and support removed from 3.4.x kernel branch).
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!
Google Nexus 4
Kernel: Semaphore 2.0.9
ROM: Purity ROM 4.4.2

Samsung Galaxy Nexus

Kernel: franco.Kernel 395
ROM: VanirAOSP 4.4.2

Samsung Galaxy Tab P1
Kernel: Humberos Kernel 1.54 3.0.101
ROM: CM 11 by terenceng

"Democracy, which is a charming form of government, full of variety and disorder, and dispensing a sort of equality to equals and unequaled alike." Plato; Book VIII; 558-C
The Following User Says Thank You to Fenvarien For This Useful Post: [ Click to Expand ]
 
boype
Old
#385  
boype's Avatar
Recognized Contributor - OP
Thanks Meter 7648
Posts: 888
Join Date: Apr 2012
Location: Düsseldorf

 
DONATE TO ME
Quote:
Originally Posted by gwindlord View Post
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
Quote:
Originally Posted by Fenvarien View Post
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!
I think sticking to the 3.0 Wifi driver is the way to go. I favor stability over experimental stuff...


Please be aware that I'm getting a lot of PMs. Therefore, I probably won't answer yours if I simply have no answer for your concern or if I don't agree with your suggestion.
The Following 7 Users Say Thank You to boype For This Useful Post: [ Click to Expand ]
 
7175
Old
#386  
7175's Avatar
Senior Member
Thanks Meter 206
Posts: 166
Join Date: Feb 2013
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.

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]
|Device| = Galaxy Nexus 'toro' |Batt's| = 1850, 2100b |Radio's| = FA02(4.04a) |Bootloader| = PRIMEMD04
|ROM's| = CFX, Vanir, Other |RECOVERY| = TWRP |SU| = SuperSU
|Kernels| = Grakern, Vanir, Fancy, also anything sketchy -based <&-FIOPS'd BFQ; Core:307; 64M ZRAM; VAUX3:2500; +{-10; -5; -10}; x{175; 175; 208}


Excellent GNEX[Ref][Guide] -- Useful-4.3-DLs -- ART Compatible Apps -- 4.3-Xposed FW/Updater/Repo
The Following 5 Users Say Thank You to 7175 For This Useful Post: [ Click to Expand ]
 
lippol94
Old
#387  
lippol94's Avatar
Recognized Developer
Thanks Meter 2655
Posts: 2,184
Join Date: Nov 2010
Location: Cremona

 
DONATE TO ME
Default R: [KERNEL][4.2.x] Fancy Kernel (r7) (FEB-23-2013)

Quote:
Originally Posted by 7175 View Post
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.

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]
Thank you so much!! I'm trying your settings and so far they're extremely stable!

Cheers!!

Sent from my Galaxy Nexus
“The computer is incredibly fast, accurate, and stupid. Man is unbelievably slow, inaccurate, and brilliant. The marriage of the two is a force beyond calculation.”

These are my XDA Projects. Check them out!

RasBeanJelly Googleize MOD (maguro) - [link]
CyanogenMod9 Blueberry EDITION (I9000) - [link]
MIUI Mintberry EDITION (I9000) - [link]
Ultimate Kernel Cleaning Script (I9000) - [link]
Vexillum Theme Project (MIUI) - [link]
CyanogenRevamped Theme (ADW) - [link]
If you like my work
and you want to see it growing
consider a small donation :)
 
ptmax13
Old
#388  
ptmax13's Avatar
Member
Thanks Meter 11
Posts: 89
Join Date: Mar 2012
Location: Heraklion

 
DONATE TO ME
@Boype
What is the next best thing after "ondemandplus" in terms of performance/battery usage ratio....
I found "ondemandplus" a little bit laggy where with "interactive" the phone seems more snappy.
(maguro) Galaxy Nexus
Stock 4.3
latest Franco kernel
TWRP recovery
 
boype
Old
#389  
boype's Avatar
Recognized Contributor - OP
Thanks Meter 7648
Posts: 888
Join Date: Apr 2012
Location: Düsseldorf

 
DONATE TO ME
Quote:
Originally Posted by ptmax13 View Post
@Boype
What is the next best thing after "ondemandplus" in terms of performance/battery usage ratio....
I found "ondemandplus" a little bit laggy where with "interactive" the phone seems more snappy.
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...


Please be aware that I'm getting a lot of PMs. Therefore, I probably won't answer yours if I simply have no answer for your concern or if I don't agree with your suggestion.
The Following 4 Users Say Thank You to boype For This Useful Post: [ Click to Expand ]
 
boype
Old
(Last edited by boype; 17th June 2013 at 03:42 PM.)
#390  
boype's Avatar
Recognized Contributor - OP
Thanks Meter 7648
Posts: 888
Join Date: Apr 2012
Location: Düsseldorf

 
DONATE TO ME
Default 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.


Please be aware that I'm getting a lot of PMs. Therefore, I probably won't answer yours if I simply have no answer for your concern or if I don't agree with your suggestion.

The Following 55 Users Say Thank You to boype For This Useful Post: [ Click to Expand ]
Tags
boype, fast, galaxy nexus, kernel, smooth
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes