Related
I am behind on this OP, I started a business and will fix it up later. Read the post from people to get latest news and opinions..
«»«» «»«» «»«»
I like to jump between kernels. Ok truth be told I jump around builds and 'ROM's all the time too. I test govenors and lockup my phone with OCing all the time. It's like a quest, except I enjoy the journey instead of looking for a holy grail.
So I wanted to start a thread to get people finding and using the different kernels.
This OP will be living!
Devs CORRECT me! Users Debate what you are seeing: PROVE it! Time it! Measure it! Log It!
Anyone Can PM me to change something if I am wrong, and otherwise correct me right in the thread, so we can get the explanations!
(I wish to point out that: all of these devs have both influence on each other and have done independent work. So becareful in stating who fixed what, etc. But also I hope the kernel devs realize most of the population doesnt understand compiled from source vs compiled from a branch, etc.., nor do we always hear the news of who Really resolved something...and go easy on us if we incorrectly identify the brains behind some hotness.)
To my knowledge there are 7 offshoots of the DInc .37 kernel as of 3/14/2011
I will categorize them by their LAST known contributor.
As of 3/14/2011 these are all AOSP, but this thread will gather stats on them all (emphasis on GB+ though)
Slayher No Official Thread
----------------------------------------------
Official CyanogenMod HTC Incredible contributor. His kernel style and concepts are most likely going to be stability and quality because the CM7 for DInc built in kernels will be his or approved by him. He also codes for other CM7 DInc projects, and has really helped Gingerbread on the Incredible be a possibility!
LATEST SPECS ONLY -
(Dismally missing this info, sorry)
2.6.37.3
Deadline I/O
CIFS
Ok Slayhers kernels don't number well, because he puts them in CM7, not always in flashable format. I'll try to take some time and open his kernel fork to get a feel for where he stands.
#C 3/2/11 new kernel... I compiled 3/5/11 and it was 2.6.37.2, not sure what other goodies hes done
#D 3/10/11 2.6.37.3 and deadline I/O
======================================================
NEW KERNEL
userjf (Slayher+AudioBoost) http://forum.xda-developers.com/showthread.php?t=958651
---------------------------------------------
userjf has done us a favor and is recompiling Slayher's DEFAULT kernel with just AudioBoost, everything else is in theory perfectly stock. If you need some more volume out of your phone give his kernel a whirl.
Specs follow Slayher's + Audio Boost, see his thread for more details (Mostly just a download link, as he doesn't mess with the rest of the kernel, and does have a list of acronyms for me to put here )
=============================================================
chad0989 (Incredikernel) http://forum.xda-developers.com/showthread.php?t=848453
----------------------------------------------
Chad is the maintainer of the well know Incredikernel, has many 2.6.32.xx updates, and made a thorough investigation into the CWR touchpoint issue, etc. His kernels were generally Sense. Previously he was coordinating with Invisiblek for AOSP kernels.
I used almost all of Chad's sense Kernels before flipping to AOSP build and picking up with Invis. MY OPINION of Chads and Invis kernels: I found their smartass tuning to be impecable for BALANCING wakeup, batterylife, and everyday performance
[But quality of tuning a kernel can make them 'score low' on things like Quadrant, etc. My personal experience and knowledge of kernels (I am a Windows Engineer...but a kernel is a kernel) tell me it is because the tuning is adapting and not focused on perforance... if you want to test performance, use a HAVSless kernel with performance govenor and probably a BFS scheduler because that one just shoots from the hip ]
LATEST SPECS ONLY - Patched up to 2.6.37.3
Any wake issues should be fixed
Audio boost
http://chad0989.dyndns.org/ 03/06/1...d0989.dyndns.org/sysfsinstructions"]READ THIS
Lowered wifi voltage for increased battery life
If you are a tinkerer and love to tweak your voltages, please PM me the voltage table you settle on as most stable for your phone.
Update on sense: Still working on it. The artifacting issue seems to be more complicated than I originally thought
Fast charging.
Working VPN
SmartAss - you need to set min 128 CPU to get full advantage
Wifi sleep policy fixed
Fixed MultiTouch
Changed to V(R) I/O Scheduler
#6 BETA 2.6.37.2-incredikernel-gb-3062011 [03/06/11] (Has FROYO Version)
#7 2.6.37.3-incredikernel-gb-3132011 [03/13/11] (Has FROYO Version)
=================================================
Invisiblek http://forum.xda-developers.com/showthread.php?t=905873
----------------------------------------------
Invisiblek has probably the most well know 2.6.32 Froyo AOSP kernel. Though this OP is my Opinion, I consider it professional. So without having run the calculations MYSELF, i would still stake that If you searched on AOSP froyo kernel's Invis#28 (FROYO) is probably the most established 2.6.32.x. Any kernel could be created to beat it in a particular category, but it was the best well rounded I have seen for AOSP 2.6.32.xx.
LATEST SPECS ONLY -
invisiblek 2.6.37.2: (still just a modified version of slayher's stock cm kernel.) Changes from stock kernel:
- added smartass governor (max cpu freq on screen off: 384mhz)
- added havs
- fast charge (thanks chad0989!)
- removed debugging options (much smaller kernel size)
#0 2.6.37-nodebug-havs-smartass [Along Time Ago]
#1 invisiblek-2.6.37.2-signed.zip [03/09/11]
=================================================
Cayniarb (Tiamat Kernel) http://forum.xda-developers.com/showthread.php?t=885217
Cayniarb is the well know maintainer of the Tiamat Kernel. I have to admit the only time I used one of his kernels is when he was the other choice for GB that had some backports in it. (told you I like to jump around) I found no issues with it, it ran smooth, had good battery life.
If I had to throw out an OPINION of Cayniarb that i like. If you look at his thread, he is very organized, methotical, and straight up. That is good for the community of users, means he is one to do his homework and release good stuff. He also seems to have no problem pushing the kernel settings and contraints so users have options to lock up their DInc to their hearts content... anyway my thoughts.
Cayniarb likes to list his specs as" rolling information" so I can't translate to 100% latest only, because i could be wrong
- cleanup gitub (cayniarb)
- cleanup code (caynairb)
merged updates/changes from CyanogenMod/cm-kernel - brings 2.6.73.2 and various optimizations for GB 2.3.3 (CyanogenMod Team)
[3/2/11][2.6.37.2 CAYNAIRB says 2.6.73.2 but kernel.org disagrees with him ]
Version 3.1.5
implement fast charging for non-SBC versions (chad0989)
add dedicated SBC defconfigs (cayniarb)
- completely update HAVS implementation (intersectRaven)
- tweak HAVS for stability particular to each platform (caynairb)
- add support for 128Mhz CPU clock speed (cayniarb)
- enable JESUS_PHONE mode by default - enables more OC levels (caynairb) -- (I do not recommend overclocking beyond 1.19Ghz and I will not support any problems caused by overclocking. Each device is unique and may or may not be able to clock to different frequencies)
- implement custom defconfig (cayniarb)
- support for the HTC Evo 4G and XOOM (cayniarb) {DINC USERS PAY ATTENTION TO YOUR DOWNLOAD}
- reapplied custom Tiamat tweaks (caynirb)
•enabled multi-touch support (cayniarb) -- CWM 3.0.0.7 works, 3.0.0.5 and 3.0.0.8 do not
#09 Version 3.1.4 [03/02/11]
#10 Version 3.1.5 [03/05/11]
===========================================
bbedward (Savaged Zen-Inc) http://forum.xda-developers.com/showthread.php?t=938790 - PAGE 11
bbedward seems to have picked up the Savaged Zen kernel from 2.6.32.xx I never used the old kernel. Ok He has his latest in his OP (so don't use the page 11 one). FROYO Kernel Available (at this time it is SBC)
LATEST SPECS ONLY -
- HAVS
- BFS + 2.6.37-ck1 - THIS IS CHOOSE-ABLE VIA WHICH DOWNLOAD YOU CHOOSE
- SBC - THIS IS CHOOSE-ABLE VIA WHICH DOWNLOAD YOU CHOOSE
- SLQB Slab Allocator
- MM Preempt 2.6.37 patchset
- Deactivate Pages 2.6.37 patchset
- I/O Less Dirty Throttling 2.6.37 patchset
- Smartass+Savaged-Zen governors
- Tweaked conservative+ondemand governors
- Fixes from CodeAurora
- Tweaks from IntersectRaven
- Froyo compatible build option
- BFS and memory tweaks
- ZRAM Support (new name for compcache/ramzswap)
#1 2.6.37 Savaged-Zen-INC v0.0.1 (CFS/BFS+AVS+SBC+HAVS) - Page 11
#2 2.6.37 Savaged-Zen-INC v0.0.1 (STILL 0.0.1, but now in the OP with updates..please consider this one the most current)
============================================
NEW KERNEL
mwielgosz (Savaged-Zen-INC noSBC) http://forum.xda-developers.com/showthread.php?t=976580
We have been graced with a new kernel. mwielgosz picks up with a dedicated thread for NOSBC Savaged-Zen
I have not given it a whirl because of RC2 and all my hacking i do for my own comforts, i "got" to redo..., so without further ado:
LATEST SPECS ONLY -
BFS OR CFS
- HAVS
- BFS + 2.6.37-ck1 - THIS IS CHOOSE-ABLE VIA WHICH DOWNLOAD YOU CHOOSE
- SLQB Slab Allocator
- MM Preempt 2.6.37 patchset
- Deactivate Pages 2.6.37 patchset
- I/O Less Dirty Throttling 2.6.37 patchset
- Smartass+Savaged-Zen governors
- Tweaked conservative+ondemand governors
- Fixes from CodeAurora
- Tweaks from IntersectRaven
- Froyo compatible build option
- BFS and memory tweaks
- ZRAM Support (new name for compcache/ramzswap)
Watch your downloads! The download page has multiple devices, dont screw up!
#1 Savaged-Zen-INC [2.6.37] noSBC [03/02/11]
---------------------------------------------------------------------------
Kernel Devs I haven't seen, please keep me posted if they popup with a kernel
HeyItsLou
Ziggy
KiNgxKernel
Hydra-kernel
Adrynalyne
Others
I would like to start gathering Kernel Terms here. Please post the definitions of the most common and not so common Terms or Questions you hear out in the wild and I'll put them in the "Second Post"
=============== TO DO Answer What are advantages of this thing over that... ============
--------------------------------
CPU SCHEDULERS
O(1) scheduler - Outdated by the CFS Scheduler
Completely Fair Scheduler (CFS)
++++++++ WHY I WANT THIS? ++++++++
The Brain **** Scheduler (or BFS)
++++++++ WHY I WANT THIS? ++++++++
DISK I/O Schedulers
Budget Fair Queuing IO Scheduler (BFQ)
++++++++ WHY I WANT THIS? ++++++++
Completely Fair Queuing (CFQ)
++++++++ WHY I WANT THIS? ++++++++
V(R) I/O Scheduler
++++++++ WHY I WANT THIS? ++++++++
Deadline IO
miatamx said:
The goal of the Deadline scheduler is to attempt to guarantee a start service time for a request[1]. It does that by imposing a deadline on all I/O operations to prevent starvation of requests. It also maintains two deadline queues, in addition to the sorted queues (both read and write). Deadline queues are basically sorted by their deadline (the expiration time), while the sorted queues are sorted by the sector number.
Before serving the next request, the Deadline scheduler decides which queue to use. Read queues are given a higher priority, because processes usually block on read operations. Next, the Deadline scheduler checks if the first request in the deadline queue has expired. Otherwise, the scheduler serves a batch of requests from the sorted queue. In both cases, the scheduler also serves a batch of requests following the chosen request in the sorted queue.
By default, read requests have an expiration time of 500 ms, write requests expire in 5 seconds.
The kernel docs suggest this is the preferred scheduler for database systems, especially if you have TCQ aware disks, or any system with high disk performance[2].
Click to expand...
Click to collapse
====================================
MODULES YOUR KERNEL MAY OR MAY NOT HAVE (MODULES CAN BE COMPILED INTO KERNEL, or a .ko file)
BCM4329.ko BroadCom One-shot wonder radio chip: BCM4329 - Low-Power 802.11n with Bluetooth® 2.1 + EDR and FM (Tx and Rx)
cifs.ko ability to connect directly to Windows computer: Server Message Block (SMB), also known as Common Internet File System (CIFS) mainly used to provide shared access to files, printers, serial ports, and miscellaneous communications between nodes on a network. Most usage of SMB involves computers running Microsoft Windows, where it was known as "Microsoft Windows Network"
IPTABLES - Linux Firewall (if it has DNAT, it can be part of an integral part of a proxy also) Mostly compiled these days, but if you don't have it you can't do IP Firewall like Droidwall.
TUN - Tunneling, generally compiled in, VPN software needs this.
daftlush said:
http://forum.xda-developers.com/showthread.php?t=976580
In that thread I found...
SBC - Superior Battery Charging. Google "trickle charging" for explanation.
HAVS - Hybrid Adaptive Voltage Scheduling. Voltage drops as CPU speed goes down in order to conserve power."
Click to expand...
Click to collapse
NOTE FROM OP: Is There a negative to HAVS? If so explain? If not why does slayher, who seems to take the time to do a lot of investigation still not include?
=====================================
OC - Over Clock(ing)(ed), using your operating system [Or Motherboard Firmware] to force the CPU or BUS above manufacturer recommendations. I have over-clocked around 100 desktops, and I goof off with my Android all the time in this area.
When you see a Device with a certain Hertz (Hz) or more likely Megahertz (MHz) this is most likely talking about the CPU multiplier Multiplied by the BUS speed (measured in 'heartbeats'... sortof... per second) In general the days of actually changing the the CPU multiplier are gone (AMD used to be able to), so if a device motherboard 'pulses' at 266Mhz and the CPU Multiplier is 3.5, we often say its a 933 Mhz device. Manufacturers build Chips (CPU, GPU, Memory, and I/O bridges (Chipsets) in huge batches. [I grew up 5 miles from Intel in Rio Rancho, New Mexico ] They spot check about 10% of the actual chips, and whatever is the maximum heat, volts, etc they can handle, or tolerate, before becoming damaged or unusable: The whole batch is rated at that speed! (This is important because many chips can FAR Exceed that without ANY VOLTAGE increase at ALL, and some can barely meet that at all (Meet the Intel Centrino's CPU's that failed level 1 or 2 Cache checks, disabled the Cache, and sold as cheap and neutered CPUs))
Over Clocking is when the user attempts to exceed the rating they were told the chip could handle: We can increase that by pushing the motherboard to 'beat' faster. The overall effect is the all data is acted upon, move to memory, moved to i/o [like disk or sound], etc faster, the NEGATIVE is CPU, GPU, Memory, or Chipsets often have brownouts: they need more electricity to operate faster. So many motherboards allow you to tweak the POWER to CPU and Memory, even some I/O Chips. The negative of more power is MORE HEAT. So eventually it is IMPOSSIBLE to maintain stability because the heat cause the chips to shut down. Hence high air cooling, and water cooling, and such. So for instance I can push a 2.4Mhz rated chip to 3.2Mhz or 1.75x its rated capacity IF I am willing to freeze the motherboard in clean nitrogen (or you would be amazed what you can do in motor oil, but i digress)
UC - ?
UV - ?
OCUV -?
GOVERNOR - ?
DEFINITION OF THE GOVERNORS - Thanks to daftlush
daftlush said:
ondemand - Available in most kernels, and the default governor in most kernels. When the CPU load reaches a certain point (see "up threshold" in Advanced Settings of SetCPU), ondemand will rapidly scale the CPU up to meet demand, then gradually scale the CPU down when it isn't needed.
conservative - Available in some kernels. It is similar to the ondemand governor, but will scale the CPU up more gradually to better fit demand. Conservative provides a less responsive experience than ondemand, but can save battery.
performance - Available in most kernels. It will keep the CPU running at the "max" set value at all times. This is a bit more efficient than simply setting "max" and "min" to the same value and using ondemand because the system will not waste resources scanning for CPU load.
powersave - Available in some kernels. It will keep the CPU running at the "min" set value at all times.
userspace - A method for controlling the CPU speed that isn't currently used by SetCPU. For best results, do not use the userspace governor."
From SetCPU FAQ.
SavagedZen governor is just a modified smartass, should minimize or eliminate wake up issues, perhaps a bit snappier.
Click to expand...
Click to collapse
Interactive Quoted from http://android.doshaska.net/interactive
Advantages:
+ significantly more responsive to ramp cpu up when required (UI interaction)
+ more consistent ramping, existing governors do their cpu load sampling in a workqueue context, the 'interactive' governor does this in a timer context, which gives more consistent cpu load sampling.
+ higher priority for cpu frequency increase, rt_workqueue is used for scaling up, giving the remaining tasks the cpu performance benefit, unlike existing governors which schedule rampup work to occur after your performance starved tasks have completed.
Laymans terms: When load starts, it ramps up CPU based on measuring how much IDLE cpu is not used. Versus competing for CPU to measure what everyone else is using. So it keeps increasing speed until the Idle bucket stop being hungrily emptied...thus measuring need without interrogation any process.
Smartass and SZ Governers are Special because they have settings controllable by the kernel Dev. Simply stated they have a range, set by the kernel dev, of MinX to MaxX CPU while screen is off and a different MinY to MaxY while the screen is on. It then operates much like Interactive (however the code was done from scratch)
Quoting http://www.ziggy471.com/2010/11/07/smartass-governor-info/ who was Quoting http://forum.xda-developers.com/showthread.php?t=730471
smartass governor – is based on the concept of the interactive governor.
I have always agreed that in theory the way interactive works – by taking over the idle loop – is very attractive. I have never managed to tweak it so it would behave decently in real life. Smartass is a complete rewrite of the code plus more. I think its a success. Performance is on par with the “old” minmax and I think smartass is a bit more responsive. Battery life is hard to quantify precisely but it does spend much more time at the lower frequencies.
Smartass will also cap the max frequency when sleeping to 352Mhz (or if your min frequency is higher than 352 – why?! – it will cap it to your min frequency). Lets take for example the 528/176 kernel, it will sleep at 352/176. No need for sleep profiles any more!
setCPU, especially in relation to Profiles
nandroid in relation to /boot
---- UNSURE WHERE TO CATEGORIZE ----- This is a file I/O, memory I/O, or DB I/O concept... I'm not sure how to tie it to kernel
"In computer Operating systems, Read-copy-update (RCU) is a synchronization mechanism implementing a kind of mutual exclusion[note 1] which can sometimes be used as an alternative to a readers-writer lock. It allows extremely low overhead, wait-free reads. However, RCU updates can be expensive, as they must leave the old versions of the data structure in place to accommodate pre-existing readers. These old versions are reclaimed after all pre-existing readers finish their accesses."
This should be stickied.
Edit: Suggestion for renaming the title: drop "HTC" and leave it as simply "The Incredible List of .37 Kernels"
just a thought
Hey bud you forgot Tiamat, i see that you have it included in your mirrors but don't have it listed here, still thanks for the post, makes getting at all the kernels much easier
poetzmij said:
Hey bud you forgot Tiamat, i see that you have it included in your mirrors but don't have it listed here, still thanks for the post, makes getting at all the kernels much easier
Click to expand...
Click to collapse
was still writing was a long post and didn't want to lose anything...
Heyitslou has a kernel thread you should check out. He has a number of them listed and some of the Rom dev's are including his in their work.
spence341 said:
Heyitslou has a kernel thread you should check out. He has a number of them listed and some of the Rom dev's are including his in their work.
Click to expand...
Click to collapse
Does he have a 2.6.37.x Kernel?
Thanks for compiling this list!
Sent from my CM7 Incredible.
galaara98 said:
Does he have a 2.6.37.x Kernel?
Click to expand...
Click to collapse
Nope, sorry it s 2.6.32.xx.
In the OP, I'd throw up a link to the respective thread under each individual kernel. Easier to find more info about each kernel.
Just to add to the editorialization, Invisiblek's kernels were regarded as possibly the cream of the crop for AOSP Froyo kernels overall, with a superb balance of performance and battery. Over on the MIUI forums, the #28 was by far the most popular kernel choice to go along with that ROM, and his GB kernel pairs up with CM7 beautifully.
Reopened thread per agreement with OP to increase traffic to Developer's work/thread with providing forum thread link instead of external link. Will continue to moderate as usual.
Incredible list of 2.6.37.xx kernels, Back in Business
Ok, I fixed up the OP... I am happy for now... probably some grammar and typos. But I think this is a great start. Let me know guys!
Aaron
Thanks for this. I was starting to lose track of all the 37.xx kernels.
andrew8806 said:
Reopened thread per agreement with OP to increase traffic to Developer's work/thread with providing forum thread link instead of external link. Will continue to moderate as usual.
Click to expand...
Click to collapse
Seems the sensible solution
galaara98 said:
Ok, I fixed up the OP... I am happy for now... probably some grammar and typos. But I think this is a great start. Let me know guys!
Aaron
Click to expand...
Click to collapse
Kudos. Lookin' good so far.
Yes thanks so much for organizing and explaining these to the best of your knowledge
Now that it has links to all the threads where people can get much more info on the kernels, I linked it to the CM7 Nightly Thread (if that's ok with you, if not, let me know and I'll remove it). Noticed you didn't have the link to your mirror where people can download it on the OP. Was this intentional?
So whats everyones favorite so far? im running the invisiblek kernel, and would like to say it has been the best kernel so far.
It should probably be noted that these are AOSP kernels....not Sense....otherwise a good addition.
cl1ckclack said:
So whats everyones favorite so far? im running the invisiblek kernel, and would like to say it has been the best kernel so far.
Click to expand...
Click to collapse
Been taking Chad's for a test run these last few days.
IMO it's pretty much between Chad's and Invisiblek. The Savaged kernel ANNIHILATED my battery life, and Tiamat just won't turn the screen on unless I hit the power button ten times.
After getting a little annoyed at the runty, poorly mapped-out, scratchy thicket of real and imagined performance tweaks, I decided to embark on a semi-long term project to determine what's real and what's "zomg mega-booster performance pills".
First project was to evaluate existing performance options on stock CM10 for actual gains using experimental design. (tl;dr: for those geeky enough to want to know, it was a main effects only d-optimal design with 32 design points for the 16 parameters listed, including several lack-of-fit and pure-error replicates. I could go on, but do you really want me to?). I ended up with a list of 16 parameters all together, from the Developer Options and Performance settings, based on their showing up in various performance tweaks discussions.
The main challenge was finding a way to measure actual performance instead of perception. I settled on several benchmarking tools: Antutu, Quadrant, SQL Benchmark, and Chainfire's benchmarking app. One of the parameters being tested ("don't keep activities") actually breaks Antutu at the graphics testing step, so I'm not reporting anything from Antutu.
All told, out of the 16 parameters tested, only 9 showed any kind of effect whatsoever, and combining best settings for all 9 simultaneously, total performance only boosted by ~20%, of which fully half was due to switching max speed from 1000 to 1100. this means the other 8 settings combined for a total boost of ~10%, meaning individually they're peanuts. The remaining 7 settings that showed no effect are only so much fluff and unlikely to do a thing for you performance-wise.
Results are summarized below for your reading/teeth-gnashing pleasure:
Max Speed (1000 versus 1100): Very clear, notable difference between the two settings on all benchmarks. This is the expected result, about 10% improvement in all benchmarks on average. Recommendation: set max speed at 1100.
Governor (convservative vs interactive vs ondemand): This only had any impact on Quadrant benchmark, no other benchmarks appeared to care. In Quadrant, conservative was the worst overall, while interactive provided an ~ 5% boost and ondemand gave ~6% boost. Recommendation: use ondemand.
Scheduler (BFQ, CFQ, noop, deadline): I don't know what schedulers do or the differences between these settings, but the only place they had any effect at all was in the SQL benchmark. There were clear differences here though: BFQ was by far the worst. CFQ and deadline were about the same with a 17% increase in SQL activity performance. noop was the best with ~ 20% increase in SQL activity performance. Recommendation: use noop. [update: some have reported stability issues with noop. If thus us the case for you, CFQ would be the next best choice]
Zram (disabled, 18% default, 26%): Zram effects only showed up in Chainfire's benchmark app, specifically for Java activities. Default 18% setting performed worst but disabled setting wasn't significantly different. 26% setting gave a 4% boost, but again, only for the java-specific benchmark. Recommmendation: use 26% setting.
16-bit transparency (off or on): Turning on the 16-bit transparency setting gave a smallish 3% boost to Chainfire's java benchmark. It did not have a measureable effect anywhere else, and I did not visually see any differences anywhere during testing. Recommendation: turn on 16-bit transparency.
Kernel same-page merge (off or on): This had a *negative* effect when turned on, resulting in a 1% performance hit on Chainfire's native benchmark. It did not have any measurable effect anywhere else. Recommendation: Keep off.
Don't keep activities (off or on): This was very problematic: it provided a distinct improvement in quadrant score (+8%) when turned on, but behaved poorly with other apps (Antutu being one). Since it didn't seem to help anywhere else outside of Quadrant and didnt' play well with others, recommendation is to keep off:
The following list are the settings that had no measureable impact anywhere. Any attempt to claim they have "zomg" status should be summarily whipped with placebo pills, or else they should let me know the exact details in which they supposedly work and I can test.
Placebo hall of shame:
Surface improvement (since it had no effect anywhere, why not just set it on banding/blur and have the best pictures?)
Background process limit
Disable HW overlays
Force GPU setting
Any of the animation scale settings (although they look snappier at lower settings, so it at least *feels* faster)
minimum speed (seriously? people think this has an effect? keep at 300 for best battery life)
Allow purging of assets
Hope you like this, y'all! Let me know if there's any other mad-scientist experiments you'd like to see.
Nicely done. How many times did you run each test? Or perhaps the results were very consistent.
FYI; regarding the governor, scheduler and the like, you may want to have a look at this thread;
http://forum.xda-developers.com/showthread.php?t=1369817
I think gives your tests / results some perspective as well.
Re: [CM10] NC Performance (and) Placebos
NCKevo said:
Nicely done. How many times did you run each test? Or perhaps the results were very consistent.
FYI; regarding the governor, scheduler and the like, you may want to have a look at this thread;
http://forum.xda-developers.com/showthread.php?t=1369817
I think gives your tests / results some perspective as well.
Click to expand...
Click to collapse
Thanks for the link. Very informative.
How familiar are you with factorial designs? All parameters were tested simultaneously in such a way that their individual effects can be partitioned out mathematically. That's what allows me to test all those settings with just 32 runs and still get solid estimates of their effects, and more importantly, the amount of variation around them (a requirement for distinguishing real effects from noise).
I suggest googling "factorial design of experiments" if you're interested.
skwalas said:
Let me know if there's any other mad-scientist experiments you'd like to see.
Click to expand...
Click to collapse
Here are some others you could try gauging:
Seeder
http://forum.xda-developers.com/showthread.php?t=1987032
V6 Supercharger
http://forum.xda-developers.com/showthread.php?t=1191747
Lagfix
http://forum.xda-developers.com/showthread.php?t=2104326
OOM/Sysctl tweaks
http://forum.xda-developers.com/showthread.php?p=34123854#post34123854
http://forum.xda-developers.com/showthread.php?p=34448792#post34448792
Re: [CM10] NC Performance (and) Placebos
Good suggestions. Before trying these third party tweaks would be good to know a few things from actual users:
Has anyone tried any combinations of these tweaks simultaneously? If yes, did they all play well together? If no, details please!
Some of these appear to have device specific settings, can anyone share settings being used on the NC?
I intend to sandbox these, as i have little desire to use then in real life just yet. Can anyone confirm that if i restore my current setup, the restore process will clean out whatever settings these tweaks out in place?
Speaking for all scientists, thank you kindly!
skwalas said:
Good suggestions. Before trying these third party tweaks would be good to know a few things from actual users:
Has anyone tried any combinations of these tweaks simultaneously? If yes, did they all play well together? If no, details please!
Some of these appear to have device specific settings, can anyone share settings being used on the NC?
I intend to sandbox these, as i have little desire to use then in real life just yet. Can anyone confirm that if i restore my current setup, the restore process will clean out whatever settings these tweaks out in place?
Speaking for all scientists, thank you kindly!
Click to expand...
Click to collapse
Have only used V6, from my experiences, restoring a Nandroid or flashing a new nightly will clean out everything it changes other than the files you store on the SDcard. This post details how I set it up http://forum.xda-developers.com/showpost.php?p=34991382&postcount=1234
I never really noticed a huge performance boost from V6, it did reduce the lag that was in the Beta's and early nightlies, mostly seemed to keep memory available and avoid the lag issued in the early builds. Have not used for the last few weeks since performance has improved on the newer builds.
Re: [CM10] NC Performance (and) Placebos
I set all recommendations. I get back to you in a couple of days. I am running 20130120 nightly
Sent from my NookColor using Tapatalk HD
Thank you!
Thank you for your measured and logical approach and recommendations! It is appreciated. I have experimented a little with the third party tweaks and haven't found any that fascinating, honestly.
When I install CM10.1, I also flash a script I made to customize to my preference and delete stuff I don't use like language modules, ringtones, quicksearch, boot animation, etc to free up some RAM. Between that and killing memory hungry apps when I'm done, my old Nook is still holding on reasonably well.
Re: [CM10] NC Performance (and) Placebos
Skwalas:
Got to tell you, your suggestions on settings are paying off. My nook is smooooooth. Is working ok there is sometime that lag liittle bit, but my p3113 also doing the same. I will stay with this 0120 nightly for a while with your settings on perfomance. .
I will report later how i am doing
Sent from my NookColor using Tapatalk HD
Re: [CM10] NC Performance (and) Placebos
performance is ok....
Sent from my NookColor using xda app-developers app
Re: [CM10] NC Performance (and) Placebos
Sometimes mook freezes and I have to leave it until it settles. The rest of the time works good
Sent from my GT-P3113 using Tapatalk HD
Re: [CM10] NC Performance (and) Placebos
Ok. Today my nook wakeup crazy. Rebooted, but it stays changing from settings , battery and some icos. It llok like it retains some touches i did to the screen and created like a loop. I have to rebooted again. Then i change the io scheduler to cfq.
Sent from my NookColor using Tapatalk HD
Re: [CM10] NC Performance (and) Placebos
Lakland said:
Ok. Today my nook wakeup crazy. Rebooted, but it stays changing from settings , battery and some icos. It llok like it retains some touches i did to the screen and created like a loop. I have to rebooted again. Then i change the io scheduler to cfq.
Sent from my NookColor using Tapatalk HD
Click to expand...
Click to collapse
Would be hard to know what is settings specific and what is hardware or OS specific. I've had no issues with the settings as described, so let us know if you are able to resolve your issues.
Re: [CM10] NC Performance (and) Placebos
skwalas said:
Would be hard to know what is settings specific and what is hardware or OS specific. I've had no issues with the settings as described, so let us know if you are able to resolve your issues.
Click to expand...
Click to collapse
I know and I am using your settings as a baseline, rigght now I change de io scheduler to cfq. Is working fine. Keep you posed and thanks!
Sent from my GT-P3113 using Tapatalk HD
Lakland said:
I know and I am using your settings as a baseline, rigght now I change de io scheduler to cfq. Is working fine. Keep you posed and thanks!
Sent from my GT-P3113 using Tapatalk HD
Click to expand...
Click to collapse
I have had erratic behavior from schedulers also, especially BFQ, NOOP is not bad, but have had better luck with CFQ.
skwalas said:
Zram (disabled, 18% default, 26%): Zram effects only showed up in Chainfire's benchmark app, specifically for Java activities. Default 18% setting performed worst but disabled setting wasn't significantly different. 26% setting gave a 4% boost, but again, only for the java-specific benchmark. Recommmendation: use 26% setting.
Click to expand...
Click to collapse
I'm surprised that zram enabled IMPROVED things. So between disabled, 18%, and 26% (no idea what default really is without digging in the code), 26% was the best option?
Interesting. I thought zram would improve multitasking (maintaining background activities) at the expense of potential slowdowns (compressed swap to ramdisk).
khaytsus said:
I'm surprised that zram enabled IMPROVED things. So between disabled, 18%, and 26% (no idea what default really is without digging in the code), 26% was the best option?
Interesting. I thought zram would improve multitasking (maintaining background activities) at the expense of potential slowdowns (compressed swap to ramdisk).
Click to expand...
Click to collapse
It might have that effect, but wasn't apparent in the benchmarks i used. It could be that a different benchmark is needed to detect it, or it could be the negative effects are too small to be measurable compared to the normal "noise" of operation.
Any ideas how we could measure this more explicitly, if there is any interest?
skwalas said:
It might have that effect, but wasn't apparent in the benchmarks i used. It could be that a different benchmark is needed to detect it, or it could be the negative effects are too small to be measurable compared to the normal "noise" of operation.
Any ideas how we could measure this more explicitly, if there is any interest?
Click to expand...
Click to collapse
Good question, I'd think it'd require some way to switch activities around and somehow measure their switch rates, but the environment would be quite difficult to keep consistent.
BTW thanks for the scientific work on this stuff, MUCH better than "OMG THIS TURNED MY TABLET INTO A UNICORN" posts we see a lot on tech forums.
skwalas said:
Any ideas how we could measure this more explicitly, if there is any interest?
Click to expand...
Click to collapse
Since it would help most when memory is low (like it ever isn't), running two memory hogs simultaneously should show an effect if there is one. A custom memory-hog app built under two different names, perhaps?
I have a shell script that creates a swapfile and enables its use that would also be well tested this way, since zram creates an in-memory swapfile. I was never able to see any tangible results except for the output of "free", so I don't use it anymore, and haven't tried it under CM10.1.
Sent from my NookColor using xda premium
Hello all, today I will be showing you how to speed up your Nook Color a bit... these methods should work for CM9/CM10/CM10.1/Paranoid Android/etc., but I personally found these out while running PA ICS. The apps you may need to make your phone faster are Ram Manager (Free OR Pro) and No Frills CPU Control (In the case that your ROM doesn't have overclocking in settings). Basically, using these "tweaks" (minus overclock, as whenever I flash a ROM the first thing I do is overclock it), I went from a painfully slow (as in, I was ready to go back to Gingerbread) device to a somewhat faster device. I've seen huge differences in launching games and apps especially, and opening to app drawer seems to be smoother also.
CPU Overclock
Either using No Frills CPU Control or the built-in overclock, set your max CPU speed to the highest on the list (not exceeding 1200, but it shouldn't show anything above that anyhow). Change your governor to either Ondemand or Performance (I personally use Ondemand and have no problems with it). Most of you are probably already overclocked though, so please don't look at me like I'm stupid.
Swap Space
Open up RAM Manager and there should be an option to change your swap space at the bottom. I changed mine to about 48 and am content with that, although I must add it may make your SD card's life shorter. This will increase your RAM, thus allowing you to have more apps open at once.
Force GPU rendering
Open Developer Options in your settings app and check "Force GPU Rendering"... I'm guessing this is one of the biggest factors to my tablet becoming smoother, as from research it helps lower end devices achieve a better framerate, although it may decrease your battery life. Also, I cannot guarantee every app will run great with this. I tested a game (Dynamite Jack) with this setting enabled and it wasn't too shabby at all! But yes, I can definitely see a difference in the overall speed of my Nook Color.
Please tell me how these work for you
I tried these settings, but unfortunately didn't perceive any performance improvement.
Good call on RAM manager. Hadn't seen that before, its going on my NC and RAZR now
Can anyone tell me a good reason for that RAM Manager app to have the permissions it does? Location, Identity, and full network access?
Does NOT work. All this app " no frills CPU" does is provide a GUI front end for the settings already found for our nook color using CM 10+ in its "performace" settings. Also this app does not provide over clocking above our set 1100 MHz. You will need a custom over clocking kernel for the encore for this. Check over on the CM 10 kernel thread n the development section.
I have open this thread for all(me included)user with no idea about ART,so here are some infos about it,what is ART,how does it work,pro+cons.
Maybe its helpfull for some peeps here.Source: Android Police
Link p1
Link p2
-------------
Part 1:
It's fair to say that Android went through some chaotic years in the beginning. The pace of development was frantic as the operating system grew at an unprecedented rate. An as-yet undetermined future led to decisions that were made to conform to existing hardware and architectures, the available development tools, and the basic need to ship working code on tight deadlines. Now that the OS has matured, the Android team has been giving more attention to some of the components that haven't aged quite as well. One of the oldest pieces of the Android puzzle is the Dalvik runtime, the software responsible for making most of your apps run. That's why Google's developers have been working for over 2 years on ART, a replacement for Dalvik that promises faster and more efficient execution, better battery life, and a more fluid experience.
What Is ART?
ART, which stands for Android Runtime, handles app execution in a fundamentally different way from Dalvik. The current runtime relies on a Just-In-Time (JIT) compiler to interpret bytecode, a generic version of the original application code. In a manner of speaking, apps are only partially compiled by developers, then the resulting code must go through an interpreter on a user's device each and every time it is run. The process involves a lot of overhead and isn't particularly efficient, but the mechanism makes it easy for apps to run on a variety of hardware and architectures. ART is set to change this process by pre-compiling that bytecode into machine language when apps are first installed, turning them into truly native apps. This process is called Ahead-Of-Time (AOT) compilation. By removing the need to spin up a new virtual machine or run interpreted code, startup times can be cut down immensely and ongoing execution will become faster, as well.
At present, Google is treating ART as an experimental preview, something for developers and hardware partners to try out. Google's own introduction of ART clearly warns that changing the default runtime can risk breaking apps and causing system instability. ART may not be completely ready for prime time, but the Android team obviously feels like it should see the light of day. If you're interested in trying out ART for yourself, go to Settings -> Developer options -> Select runtime. Activating it requires a restart to switch from libdvm.so to libart.so, but be prepared to wait about 10 minutes on the first boot-up while your installed apps are prepared for the new runtime. Warning: Do not try this with the Paranoid Android (or other AOSP) build right now. There is an incompatibility with the current gapps package that causes rapid crashing, making the interface unusable.
How Much Better Is It?
For now, the potential gains in efficiency are difficult to gauge based on the version of ART currently shipping with KitKat, so it isn't representative of what will be possible once it has been extensively optimized. Thus far, estimates and some benchmarks suggest that the new runtime is already capable of cutting execution time in half for most applications. This means that long-running, processor-intensive tasks will be able to finish faster, allowing the system to idle more often and for longer. Regular applications will also benefit from smoother animations and more instantaneous responses to touch and other sensor data. Additionally, now that the typical device contains a quad-core (or greater) processor, many situations will call for activating fewer cores, and it may be possible to make even better use of the lower-powered cores in ARM's big.LITTLE architecture. How much this improves battery life and performance will vary quite a bit based on usage scenarios and hardware, but the results could be substantial.
What Are The Compromises?
There are a couple of drawbacks to using AOT compilation, but they are negligible compared to the advantages. To begin with, fully compiled machine code will usually consume more storage space than that of bytecode. This is because each symbol in bytecode is representative of several instructions in machine code. Of course, the increase in size isn't going to be particularly significant, not usually more than 10%-20% larger. That might sound like a lot when APKs can get pretty large, but the executable code only makes up a fraction of the size in most apps. For example, the latest Google+ APK with the new video editing features is 28.3 MB, but the code is only 6.9 MB. The other likely notable drawback will come in the form of a longer install time for apps - the side effect of performing the AOT compilation. How much longer? Well, it depends on the app; small utilities probably won't even be noticed, but the more complex apps like Facebook and Google+ are going to keep you waiting. A few apps at a time probably won't bother you, but converting more than 100 apps when you first switch to ART is a serious test of patience. This isn't entirely bad, as it allows the AOT compiler to work a little harder to find even more optimizations than the JIT compiler ever had the opportunity to look for. All in all, these are sacrifices I'm perfectly happy to make if it will bring an otherwise more fluid experience and increased battery life.
Overall, ART sounds like a pretty amazing project, one that I hope to see as a regular part of Android sooner rather than later. The improvements are likely to be pretty amazing while the drawbacks should be virtually undetectable. There is a lot more than I could cover in just this post alone, including details on how it works, benchmarks, and a lot more. I'll be diving quite a bit deeper into ART over the next few days, so keep an eye out!
---------------------------------------------
Part 2 in next post.....
Part 2
---------
By now you've probably heard about ART and how it will improve the speed and performance of Android, but how does it actually perform today? The new Android Runtime promises to cut out a substantial amount of overhead by losing the baggage imposed by Dalvik, which sounds great, but it's still far from mature and hasn't been seriously optimized yet. I took to running a battery of benchmarks against it to find out if the new runtime could really deliver on these high expectations. ART is definitely showing some promise, but I have to warn you that you probably won't be impressed with the results you'll see here today.
Reality Check
Let's be honest, benchmarking apps tend to be inaccurate and unreliable, often giving wildly varying results even when run in precisely identical situations. However, they are the only option available for recording meaningful and measurable values on performance. Further, since most popular benchmarks are built on the NDK (Native Development Kit), they won't gain any benefit from running under ART. Despite these limitations, there are some interesting and unexpected results that help us learn a little more about the current state of performance.
How The Benchmarks Were Run
Each benchmark was run at least 4 times on a completely stock Nexus 5 (it isn't even rooted) with both Dalvik and ART. To ensure there was no interference from apps at startup, a minimum of 5 minutes was given after a reboot before any tests were run. In addition to the 6 benchmarking apps listed below, I also tried 2 browser benchmarks (SunSpider & BrowserMark) in Chrome, but neither displayed significantly different scores. So, let's get to the results.
Linpack for Android
One of the key factors in getting good test results is knowing that the tools are measuring the right thing. While many of the benchmark apps target the NDK, a few stick to the SDK. The first and most consistent among them is Linpack for Android, a port of the already popular benchmarking app used throughout numerous computing platforms. It produces a score by performing a series of calculations on floating point numbers. I think this is an obvious choice after reading the description, "This test is more a reflection of the state of the Android Dalvik Virtual Machine than of the floating point performance of the underlying processor." Thanks to ART, scores are 10%-14% higher than they would be with Dalvik. Not too shabby…
Real Pi Benchmark
Calculating digits of Pi is another popular way of stressing a processor, and particularly suitable because most methods stick to integer calculations and avoid floating-point math entirely. Along with Linpack, this gives us coverage of both basic mathematical operations. On top of it, Real Pi happens to use native code to perform the AGM+FFT formula, but uses Java for Machin's formula. On the native side, ART came out about 3.5% faster, probably due to interface optimizations rather than mathematical performance. More importantly, testing with the java code turned out to be 12% faster. (link) Note: in this test, lower numbers are better.
Quadrant Standard
The previous tests are highly specific to mathematical performance, so it's time to branch out to test more of the system. Both Linpack and Real Pi show some positive improvement with ART, but Quadrant gave a result that borders on the amazing, perhaps even too good. The CPU score is off the charts for ART, almost doubling that of Dalvik, which is substantially better than even the most optimistic estimates we've heard so far... While tests for I/O, 2D, and 3D rendering show fairly negligible differences, Dalvik does take an oddly high 9% advantage in the memory test.
3D Mark
I was leery of using a benchmarking app that clearly focuses on the NDK, as it theoretically shouldn't be affected very much by ART. However, as the tests were run, an interesting pattern emerged where the Dalvik runtime repeatedly held a slight advantage. It's difficult to attribute a reason for Dalvik to do better here, but I'm open to theories.
AnTuTu Benchmark
Breaking performance down even further, AnTuTu helps to expose a pattern. It's increasingly clear that ART is making significant strides with floating-point operations, but doesn't usually turn out huge gains for integers. A strong showing in "RAM Operation" also hints at better use of caching as opposed to just raw memory I/O. These high scores indicate areas where the Dalvik virtual machine was probably very expensive, causing more extensive overhead. The other results weren't particularly remarkable except for the Storage I/O, which might suggest a couple of specific optimizations. One significantly low score appears for UX Dalvik, but it's not clear what AnTuTu is measuring, so this may not be particularly relevant.
CF-Bench
For the ultimate in number production, Chainfire's own benchmark tool takes out a lot of the guesswork by performing tests built on both the SDK and NDK. Again, native code displays a small but curious advantage on Dalvik. Here we can see the integer calculations are swinging back towards Dalvik, as well. Mostly confirming the pattern, floating-point operations demonstrate a significant speed gain, this time in the 23%-33% range.
Other Interesting Measurements
Measuring the first boot after switching runtimes isn't your typical test, no doubt, but the time it takes is quite striking. I wanted to record just how long it took to complete both the App Optimization step and then the total time to actually reach the unlock screen. When I ran this test, I had 149 apps installed.
The Other Stuff
While numbers can be helpful, they don't tell the full story. Benchmarks usually push the hardware to work as hard as possible for a few seconds, then switch to a new test that does the same thing. Sadly, this ignores details that aren't easily measured. I don't have a good way to measure the smarter timing of memory management (especially garbage collection) or better handling of multiple threads. While I can't show numbers for these things, I can demonstrate them. The classic test for a browser simply requires flinging the page as fast as possible and watching it try to keep up. After stress testing Chrome for Android with the mobile version of David's gigantic HTC One review, it turns out that even the supercharged SoC of the Nexus 5 can't quite keep up while running on Dalvik… ART, on the other hand, never lost a pixel. Take a look for yourselves.Videos below.
Fast scrolling with dalvik: http://youtu.be/JGyktLPvORU
with ART: http://youtu.be/L9lpCssSdMc
To be fair, switching to the desktop version and giving a single fling will easily send you into blank screen territory, but it's still obvious that the renderer catches up faster on ART than on Dalvik. When more optimizations are in place, maybe we won't be far off from flawless scrolling even in the desktop version. For another demonstration, a user by the name of spogbiper has posted his own side-by-side comparison with two Nexus 7s. The one running ART seems to be more responsive.
Summary And Conclusions
The numbers and the videos together paint a picture of where ART stands today. It will definitely make a difference, but its current incarnation just hasn't matured enough to deliver significant gains. Floating-point calculations and basic responsiveness are obviously reaping the benefits of the new runtime, but that's about it. There's little or no overall improvement for integer calculations, most regular code execution, or much of anything else. In fact, it looks like gamers would be better served by sticking to Dalvik, for now.
Why aren't the benchmarks blowing us away? If I were to make a guess, it's probably because the first goal in developing ART was to make sure it was functional and stable before the heavy optimizations came into effect. If that's the case, there is probably quite a bit of code for error-checking and logging just to ensure everything is operating as it should, which might even be responsible for more overhead than we had with Dalvik. Even in the places where ART doesn't outperform Dalvik, the numbers tend to remain reasonably close. As subsequent versions of the runtime emerge from Mountain View, we should expect to see the performance gap growing wider as ART pulls ahead.
Now for the real question: is it worth switching to ART right now? Google obviously isn't recommending it for regular users, and I tend to agree. While ART seems very solid and I feel like responsiveness is better - possibly just the placebo effect - there are still circumstances where it is unstable and causes apps to crash. If there is even a single instance where you have to switch back to Dalvik to get an app to run correctly, that inconvenience far outweighs the minimal performance gain you might have had. Once I've finished this series, I will probably stick to Dalvik for the remainder of KitKat; and I imagine most people will be better served by doing the same.
Introducing ART from: source.android.com
ART is a new Android runtime being introduced experimentally in the 4.4 release. This is a preview of work in progress in KitKat that can be turned on in Settings > developer options. This is available for the purpose of obtaining early developer and partner feedback.
Important: Dalvik must remain the default runtime or you risk breaking your Android implementations and third-party applications.
Two runtimes are now available, the existing Dalvik runtime (libdvm.so) and the ART (libart.so). A device can be built using either or both. (You can dual boot from Developer options if both are installed.)
The dalvikvm command line tool can run with either of them now. See runtime_common.mk. That is included from build/target/product/runtime_libdvm.mk or build/target/product/runtime_libdvm.mk or both.
A new PRODUCT_RUNTIMES variable controls which runtimes are included in a build. Include it within either build/target/product/core_minimal.mk or build/target/product/core_base.mk.
Add this to the device makefile to have both runtimes built and installed, with Dalvik as the default:
PRODUCT_RUNTIMES := runtime_libdvm_default
PRODUCT_RUNTIMES += runtime_libart
------------------------------------------------------------
MANY GREEEETZ+STAY ADDICTED!!!!
Were hi find gapps art?thanks
Sent from my LG-E610 using XDA Premium 4 mobile app
velosa said:
Were hi find gapps art?thanks
Sent from my LG-E610 using XDA Premium 4 mobile app
Click to expand...
Click to collapse
look in app section here in l5 forum,i have uploadet a minipack,also there are more infos.
-CALIBAN666- said:
look in app section here in l5 forum,i have uploadet a minipack,also there are more infos.
Click to expand...
Click to collapse
Thanks
Sent from my LG-E610 using XDA Premium 4 mobile app
thank you very much for your work about ART presentation ! very nice and perfect ! :good:
conclusion : don not use ART for the moment on CM11 ! ok ! wait more stability ...
i've downloaded gapps kk from cr3pt thread for cm 11, while i'm waiting for more stability i wanna ask you if they are art compatible.
Best presentation of ART!
When the gapps are odexed than yes.
STAY ADDICTED,GREEEETZ!!!
Guys.. With every Android since the 2.x, you could activate the "Developers Options" and activate an option called "Show CPU usage".
"The numbers show the average load of the CPU in different time intervals. From left to right: last minute/last five minutes/last fifteen minutes"
My doubt: When I install any CM13 ROM (now I'm with Exodus) on my S5 (G900M), the load, after some minutes, are always near 10. Now I'm staring at it, with many apps installed (whatsapp, facebook, uber, maps, messenger, firefox, mx player, es file explorer, foursquare, traceroute, wifi analyzer, gmail, imo, os monitor, tinder, fing, poweramp, mindroid, remote desktop, 99, youtube, andsmb, diskusage, soundhound, photos, dropbox, goseek, instagram, juicessh, google now, picsplay, speedtest, skype, swiftkey, stabilitytest... just to name some...) and it's 11.32 / 14.37 / 23.11
Now the problem: whenever I install Boeffla Kernel or CrazyKernel, the load is ALWAYS higher.. always nearing 20. With default options, or trying to tweak the cpu options in both kernels.. and the bigger problem is that I SENSE that. The phone seems to RUNS SLOWER.
ps: If you LOCK your device (or let it lock by the timeout), this "load" value will raise because the cpu will also run slower.. it doesn't mean it's working more, just that more work is queued to the cpu, as it doesn't NEED to work on it (because it's locked/screen turned off, etc)
Hi,
I guess everyone will have that. So the poll is quite useless.
The reason for it, as I tracked down:
Two governors (intellimm and slim) are adding overhead to the system, even when they are not used.
Why? I do not know, as I am not the developer of these governors.
But for a test, I removed them from beta11 and compiled it as a beta11test1 version, attached here.
Let me know if removal of these governors lowers the cpu utilization for you down to stock levels almost.
Andi
Lord Boeffla said:
Hi,
The reason for it, as I tracked down:
Two governors (intellimm and slim) are adding overhead to the system, even when they are not used.
Why? I do not know, as I am not the developer of these governors.
But for a test, I removed them from beta11 and compiled it as a beta11test1 version, attached here.
Let me know if removal of these governors lowers the cpu utilization for you down to stock levels almost.
Andi
Click to expand...
Click to collapse
Wow that was fast. I'm testing right now and yes, the CPU load is *finally* down to ~11 like it were with vanilla CM13 kernel (which I think is what Exodus uses).
Still I get a little lag here and there mostly when "loading" stuff (like when clicking in a group chat on whatsapp, which needs to open a huge .db to display the history.. I think).....
But nice work.. I wonder what more could be optimized.. it's strange to a vanilla kernel be snappier than a custom .. given the experience you have..
Thanks
fbs said:
Wow that was fast. I'm testing right now and yes, the CPU load is *finally* down to ~11 like it were with vanilla CM13 kernel (which I think is what Exodus uses).
Still I get a little lag here and there mostly when "loading" stuff (like when clicking in a group chat on whatsapp, which needs to open a huge .db to display the history.. I think).....
But nice work.. I wonder what more could be optimized.. it's strange to a vanilla kernel be snappier than a custom .. given the experience you have..
Thanks
Click to expand...
Click to collapse
I am not sure vanilla stock kernel is more snappy. I feel it is the other way round personally. But this is about expectations and perception. Also it is about what is important for one. A custom kernel gives you many other goodies that might of course compromise in other areas. Nothing is for free.
And I personally prefer some other features over pure performance.
But well, that's it. I will not do more, having in mind the s5 kernel is only my #5 kernel in terms of priority. Sorry.
Andi
Lord Boeffla said:
I am not sure vanilla stock kernel is more snappy. I feel it is the other way round personally. But this is about expectations and perception. Also it is about what is important for one. A custom kernel gives you many other goodies that might of course compromise in other areas. Nothing is for free.
And I personally prefer some other features over pure performance.
But well, that's it. I will not do more, having in mind the s5 kernel is only my #5 kernel in terms of priority. Sorry.
Andi
Click to expand...
Click to collapse
Now I'm on boeffla-config trying to tune "interactive" governor and it says it's not tunable. it was before this test version. Maybe the removal of that other governors screwed up boeffla-config listing of whats tunable or not.. ? check this out too please..
fbs said:
Now I'm on boeffla-config trying to tune "interactive" governor and it says it's not tunable. it was before this test version. Maybe the removal of that other governors screwed up boeffla-config listing of whats tunable or not.. ? check this out too please..
Click to expand...
Click to collapse
Well, not such an issue here. I can enter tunable mode.
Reset your app via the apps maintenance menu.
But you know, you are on a completely unsupported test kernel. Just to say that again.
Andi
Lord Boeffla said:
Well, not such an issue here. I can enter tunable mode.
Reset your app via the apps maintenance menu.
But you know, you are on a completely unsupported test kernel. Just to say that again.
Andi
Click to expand...
Click to collapse
Right, but given the test was a success, you'll remove these governors for good, right?
fbs said:
Right, but given the test was a success, you'll remove these governors for good, right?
Click to expand...
Click to collapse
Yes, already announced everywhere (here on xda, as well as on Twitter and on my site).
Andi