Related
I'd like to come up with a list of performance and battery optimizations for AOSP android devices. I will base this off of cyanogen, and it's derivatives, like evodeck, which is what I use.
I have a few questions. I will edit when I get answers, to include them.
For raw performance, which is better, Yaffs, or EXT2. Also, does that question actually fluctuate depending on which partition? I just became aware that EXT4 will be the new standard partition, but that's just EXT2, with extents (which on flash is worthless overhead), and journaling, which uses a lot of write cycles.
Does 3g turbocharger affect battery usage? Does it actually work?
What is people's opinion on v6 supercharger and 3g turbocharger?
Basic optimizations that I start off with for pure battery
Setup power control widget. Disable autosync on disable wifi, have 2g/3g disable or enable based off of background data.
Use HAVS custom kernel, with undervolt as far as you can go while maintaining stable, using vipermod. Use smartass governor. Some people perfer interactiveX.
If for whatever reason, you can not use a HAVS kernel, use setCPU to set your screen off settings to go to powersaver governor, just so it doesn't have to monitor use. Underclock your lowest speed to comfort level. I like 128MHZ on my evo.
For amoled screens, use black as often as you can, while for LCD screens, use white as often as you can.
Shut off haptic feedback, and other input based sounds.
Performance and battery
Disable Animations, of nearly any kind in settings. Set transparency to 16bit.
Consider lowering VM heap size, to prevent garbage collection, experiment as necessary.
If you have sufficent memory (512+), then lock messenger and homescreen in memory.
Consider using v6 supercharger to make android properly setup for the amount of ram that you have, instead of a generic value.
Remove DSP, since it increases processing usage.
Set noatime and nodiratime, to prevent disk writes.
Use push mail instead of polling to save battery.
Use a static wallpaper, or no wallpaper.
Given the recent hoopla in the blogosphere about how iOS places higher priority on User Interface actions than Android. I was wondering what ideas can be implemented in current Android or Linux kernels to get better UI response.
Overclocking or upgrading to a faster phone is the brute force way, a smarter way would be to give higher priority to user input instead of benchmark/multitasking score numbers. I think it makes sense to give the User input highest priority because in computation timeframes, user input is rare, and considering how important smoothness affects overall perception & enjoyment of a device, it's a good idea to allow other OS background tasks to take a backseat when the User wants to do something.
I'll start the discussion with two ideas I've implemented in a kernel recently that has shown improvements in UI response.
1. Switched to using SIO (Simple IO) scheduler (similar, but slightly lower benchmarks than Noop). Main difference is SIO prevents the system from hogging resources when large amounts of data needs to be read/written. It has a timeout so UI threads has a chance to run also.
2. Switched the touchscreen driver interrupt service request from using the general events workqueue (schedule_work()) to a dedicated workqueue (queue_work()). Touchscreen generated actions get to ride in the fast lane.
Any other ideas people have?
How bout some NSA IN THAT KERNEL
via Dan swagger
Usefull links, that clear things out:
https://plus.google.com/100838276097451809262/posts/VDkV9XaJRGS
https://plus.google.com/105051985738280261832/posts/XAZ4CeVP6DC
http://blog.crazybob.org/2011/12/truth-about-android-ios-ui-performance.html
the thing is i may be using a note but when using ICS with apps that are updated for ICS, i feel its smooth enough. the real difference is i think ios uses completely different method for scrolling i.e. the bounce function and slight delay in finger recognition. same with ios touch recognition, it just somehow is better no doubt.
btw when i was miui with bounce it definitely felt smoother but although it wasnt ios smooth.
Sent from my Galaxy Note using XDA App
The main difference between ios and android is the fact they use ram in two totally different ways. Ios handles ram in a manner to make the user interface smooth as possible all the time while android frees ram to make multitasking better. The problem that android has is changing the way android handles ram to make the interface smoother for the user. They wont be able to for a long time because they have to do a total overhaul on the whole dalvik cache type setup that android uses.
Sent from my Incredible 2 using Tapatalk
i recently started using supercharger v6 which messes around with the ram and how it should be allocated for desired operations. I don't know if it's relevant but do you think it makes a difference and which setting would get you a better scrolling experience?
I liked the supercharger when I used the Droid Eris but since I've upgraded I get more redraws than without it. I used the 768hp I think.
Sent from my Incredible 2 using Tapatalk
you could edit the ramdisk to set more of a priority to rosie.apk or whatever launcher you use...just a thought
That would be the same as locking home in memory.
Sent from my Incredible 2 using Tapatalk
shad0wboss said:
i recently started using supercharger v6 which messes around with the ram and how it should be allocated for desired operations. I don't know if it's relevant but do you think it makes a difference and which setting would get you a better scrolling experience?
Click to expand...
Click to collapse
There are a number of issues that contribute to a "sluggish experience". The supercharger v6 script mainly keeps more memory free so that switching to new apps cuts down on the garbage cleanup of older apps. One of the downsides I've noticed with more aggressive lowmemkiller settings is a lot of apps get killed in the background when they need to stay for when users want to multitask.
The hardware acceleration route has downsides too from what I've heard, it requires more RAM per app just to have it enabled.
One of the articles posted earlier has good insight. Mainly because a lot of apps share a general events queue, and developers should not have a lot of blocking code in there, but developers make mistakes. The tools available for Android to develop and tweak UI performance seems lacking at this point.
How about SIGSTOPping everything else when you touch?
Questions or Problems Should Not Be Posted in the Development Forum
Please Post in the Correct Forums
Moving to General
does it work with samsung i9000?
Supercharger?
Sent from my Sabotaged Droid Incredible 2.
I find that either turning off cpufreq (by using the Performance governor) or increasing the lower frequency makes things a bit more snappy. For most governors, there's a delay between CPU load and the frequency being increased. This delay is usually noticeable if the CPU load is due to me working with the interface. By increasing the min frequency to, say 800mhz on a Nexus S, this makes things a lot more snappy than the default setting of 200mhz.
Another thing that helps with the smoothness (at least for me, in ICS) is the setting that forces GPU acceleration for all apps. For example, apps these days (well twitter and Facebook) have that pull down to refresh widget from iOS. Without forcing GPU acceleration, the rotating arrow animation usually hitches quite a bit, but is smoothed out with this setting on. This setting can be found in the developer options in the settings.
Hope these help,
- chris
Turning up the min CPU can cause freezes on some peoples phone though and using the performance governor can drain the battery quick. The reason the CPU scales up the way it does before it gets to max frequency is to save battery.
Sent from my Sabotaged Droid Incredible 2.
System tuner pro has alot of tweaking options that on memory use
those that use launcher pro can find a memory usage setting in launcher pro to.
disconnecktie said:
Turning up the min CPU can cause freezes on some peoples phone though and using the performance governor can drain the battery quick. The reason the CPU scales up the way it does before it gets to max frequency is to save battery.
Sent from my Sabotaged Droid Incredible 2.
Click to expand...
Click to collapse
Agreed, but the whole point here was to help improve UI responsiveness. Without rearchitecting the OS, a good way is to allow the CPU (which is busy sharing its resources with non-UI work) to react more quickly is to ensure the CPU is at a higher clock rate before the UI needs it.
As for battery life, it really depends on your usage pattern. If you have a lot of background processing going on, preventing the CPU from going to sleep when idle, you may be better off scaling back the minimum cpufreq frequently. If your CPU actually goes to sleep, give scaling things up a try. A handy tool you can use to see how often the CPU is sleeping is CPU Spy. To see which apps are keeping the CPU awake, there's a program called Better Battery Stats available on XDA and market.
As for stability, I don't mean over clocking the CPU...all I'm suggesting is to increase the frequency the CPU goes to when the screen is on, but nothing much is happening. This should still keep things within safe limits.
Hope this helps,
- chris
I find the interactive governor does a very good job of ramping to max right from idle (instead of waiting even a few ms like ondemand does). It assumes coming out of idle the CPU is starved. Then scales back once demand lowers. No fancy locking to min freq when screen is off (which can stutter some background apps).
There is many thing what can be done in the code of the applications. For example once I had a really sluggish app. It turned out that while I was dragging an item in the UI, the UI needed to be relayouted, and the draw calls were simply postponed: in android (at least that was the case before ICS) the drawing of the UI is delayed while the UI thread is too busy with events and layout requests.
To find these issues it's really useful to use traceview.
Alright so here's the first release of this kernel for codeworkx's CM9 with hardware acceleration.
Again this is for codeworkx's cm9.
Also, this is for codeworkx's cyanogenmod 9.
One more time, this is for cm9 only.
Finally, this is for cm9 and cm9 only!
Don't let the "alpha" title fool you into thinking it's not stable... it is... It's only alpha because it's still in the "testing" phase.
FEATURES/CHANGES
Overclockable to 1.38GHz
Underclockable to 150MHz
GPU overclocked to 384MHz (highest possible without bottlenecking and battery waste)
Tuned OnDemand Governor (recommended)
Interactive Governor with time view concept (learns from your use and adjust parameters accordingly)
Wheatley Governor (optimized use of C4 state)
Hotplug Governor (turns of one of the cpus to save power when load is very low)
Pegasusq Governor (A better version of Hotplug, but experimental and not designed for our devices)
SIO scheduler for speed/performance with flash storage
Linaro Toolchain
Linaro optimizations and patches
Linaro makefile compiler flags
Makefile Optimizations to boost performance
Optimized CRC32
Optimized ARM RWSEM algorithm
Tiler Memory increased to 32MB (linaro)
Other Tiler patches/tweaks to improve 2D gpu performance
SLQB allocator
lib/string use glibc version for speed
lib/memcopy use glibc version for speed
lib/sha1: use the git implementation of SHA-1 and removed ARM sha1 routines
I/O backport from 3.2 linux kernel for less dirty throttling
Tweak CPUIDLE to enter deep sleep faster thus saving battery
LowMemoryKiller backported from 3.4 kernel
Disable GENTLE_FAIR_SLEEPERS for improved performance
Allow Deep Sleep to occur when media decoder is active allowing the cpu to shut off when playing music or video.
Allow MPU logic to power down when in deep sleep to save power.
Increased default readahead value to 1024KB for faster sdcard reads
A lot of stuff I probably forgot I did.
Also includes a ridiculous amount of bugfixes, patches, and tweaks that can found on my github commit log.
***Read Me***
DO NOT, UNDER ANY CIRCUMSTANCE, USE SETCPU PROFILES OF ANY KIND OR ANYTHING SIMILAR WITH THIS DEVICE. Things like screen off max frequency, temperature throttling, and others are already built in to the OMAP architecture. Using ANY profiles will ONLY lead to problems, instabilities, and battery drain.
***************
Let me know how it "feels" especially by default without overclocking or underclocking. Also I'd be interested in how the battery treats you. Thanks!
DOWNLOAD
a1 - Only for 7 inch
a2 - Only for 7 inch - Changes to: Wifi, GPU, Low Memory Killer, others
a3 - Only for 7 inch - Changes to: ondemand, interactive, add wheatley, add pegasusq, deep idle, compiler flags, SDcard read, others
a4 - not working... fix soon - Changes to: Compiler flags, CPUidle, RCU, others.
a5 - http://goo.im/devs/Metallice/Tab2/MetalliKernel_10.1_CM9_a5.zip - reverts and bugfixes, use 10.1 ramdisk in 10.1 version.
a6 - http://goo.im/devs/Metallice/Tab2/MetalliKernel_10.1_CM9_a6.zip - CLASSIFIED change, NEED feedback on speed, slowness, smoothness, and lag compared to stock and a5. Reverted some revets. Reverted changes to RCU to fix SODs. For 10.1 fixed overclocking.
Thanks go out to - CodeworkX, Ezekeel, Francisco Franco, Imoseyon, Faux123, Fugumod, Sonicxml, Texas Instruments, Samsung, Google, and all the others I probably forgot about. Sorry!
Source
https://github.com/Metallice
______________________________________________________________________________________________________________________
So, I'm a broke college student without a job this summer - instead taking extra classes and studying like crazy for the MCAT. If you like my work and want to thank me, feel free to buy a coffee or an energy drink so I can continue to stay up late studying and working on Android stuff (or help me pay for med school ). I don't want to have to choose! Thanks and I appreciate your support!
Metallice said:
Alright so here's the first release of this kernel for codeworkx's CM9 with hardware acceleration.
Again this is for clockworkx's cm9.
One more time, this is for clockworkx's cyanogenmod 9.
Finally, this is for cm9 and cm9 only!
Don't let the "alpha" title fool you into thinking it's not stable... it is... It's only alpha because it's still in the "testing" phase.
NO CLUE IF THIS WILL WORK AT ALL. I DO NOT HAVE THIS DEVICE.
***Read Me***
DO NOT, UNDER ANY CIRCUMSTANCE, USE SETCPU PROFILES OF ANY KIND OR ANYTHING SIMILAR WITH THIS DEVICE. Things like screen off max frequency, temperature throttling, and others are already built in to the OMAP architecture. Using ANY profiles will ONLY lead to problems, instabilities, and battery drain.
***************
Let me know how it "feels" especially by default without overclocking or underclocking. Also I'd be interested in how the battery treats you. Thanks!
DOWNLOAD
a1 - Only for 7 inch
a2 - Only for 7 inch - Changes to: Wifi, GPU, Low Memory Killer, others
a3 - Only for 7 inch - Changes to: ondemand, interactive, add wheatley, add pegasusq, deep idle, compiler flags, SDcard read, others
a4 - http://goo.im/devs/Metallice/Tab2/MetalliKernel_10.1_CM9_a4.zip - Changes to: Compiler flags, CPUidle, RCU, others.
If you would like to overclock but your device can't handle it... and are willing to suffer through extreme battery drain to try this - Link
Thanks go out to - CodeworkX, Ezekeel, Francisco Franco, Imoseyon, Faux123, Fugumod, Sonicxml, Texas Instruments, Samsung, Google, and all the others I probably forgot about. Sorry!
Source
https://github.com/Metallice
______________________________________________________________________________________________________________________
So, I'm a broke college student without a job this summer - instead taking extra classes and studying like crazy for the MCAT. If you like my work and want to thank me, feel free to buy a coffee or an energy drink so I can continue to stay up late studying and working on Android stuff (or help me pay for med school ). I don't want to have to choose! Thanks and I appreciate your support!
Click to expand...
Click to collapse
I LOVEEEEEE YOU i absulutely love you MAN!~~~~~~~~~~~~~~~
His kernels and ROM's for the 7 are right on.
Good luck with this Metallice.
Thanks, but it didn't seem to go past the boot screen for me.
Sent from my Galaxy Nexus using Tapatalk 2
kuronosan said:
Thanks, but it didn't seem to go past the boot screen for me.
Sent from my Galaxy Nexus using Tapatalk 2
Click to expand...
Click to collapse
Which boot screen. I think I know the issue if its not the cyanogenmod one.
Sent from my GT-P3113 using xda premium
I have this issue too and it's the Tab2 10.1 screen. (the first one that shows during boot)
It's the Tab 2 Splash screen. I can adb, go into DL, and get into CWM so it's fine... it just won't boot.
Yeah its probably because I forgot to use the 10.1 ramdisk. I'll upload a fixed version shortly.
Sent from my GT-P3113 using xda premium
No worries man.
Thanks for getting started anyway, a lot of devs can use your fork now.
New version up. In addition to some bugfixes and reverts, this time the espresso10 ramdisk is actually used instead of the 7 inch version
Now it installs fine. What app should I use to control it? NSTools, Voltage Control, CPU Master, etc...
MultipleMonomials said:
Now it installs fine. What app should I use to control it? NSTools, Voltage Control, CPU Master, etc...
Click to expand...
Click to collapse
Glad to hear it. Let me know how it runs.
Really doesn't matter what you use as they all modify the same sysfs entries. I like no frills CPU control because its simple and only does what I need it to do.
Sent from my GT-P3113 using xda premium
Changing OC settings with NSTools or CPU control causes reboot. Settings don't change.
I can change min freq and governor (tried it with interactive and wheatly), just not max freq.
Works like a charm now. I'll keep you up to date on performance once I've done some testing.
Works fine in voltage control, and stable at 1380 so far with little heat. I haven't really stressed it though but it does run smoother and more responsive than before. The GPU seems snappier too. Great job.
Sent from my GT-P5113 using Tapatalk 2
Can you post a complete "feature list" with next version ? Oh, and can Voodoo sound be integrated for better (sound) quality ? I'll keep pressing the thanks button.
Thanks for the kernel, will test it later this day.
Maybe you can add an how to flash guide for the n00bs who want to flash but don't know how to do it?
works works works!!!!!!!!!! like an awsomeness thing! hehe i know that i can trust on you m8, but i did ask for it..yet and you made it! thx really THX!!!!!!
Hi,
Thank you for work but is what I am to have a problem of hangs and of connection with WIFI
Been testing the kernel with default settings for some hours now ... started using it since 11.oo this morning and started with a full battery. After playing some games (tablet/battery temperature stayed normal) and browsing the net, checking emails and some more stuff i must say the kernel works smooth and my tablet runs faster. Am using the kernel for 3.5 hours and the battery is at 71%. No weird things happened so far. WiFi and bluetooth both work fine in other words...
the kernel feels goOOOood
Hello everyone,
I've been using the cm9 release candidate since it was released, and still can't figure out how to make it snappy (I was on Apex before, and found it much more responsive). I'm not sure which the performance/memory management settings the Nexus S can handle well (there are lots of other threads for other phones, but I'm not sure if some of the settings require better hardware), so I'd appreciate it if anybody could tell me what they've found to be good for the following options:
Performance settings:
- Surface dithering
- 16bit transparency
Memory management:
- Allow purging of assets
- Kernel samepage merging
Misc. information that may or may not be relevant:
- Using Matr1x kernel (CFS, v21.0 I think)
- Processor is running at 200/1200 most of the time, ondemand governor (same settings that used to give me great performance on Apex).
- Also tried running Supercharger script, but it didn't seem to change things as much as it usually does
- Fixing permissions didn't fix it
- Battery life seems fine
- What I mean by "unresponsive" is that the launcher takes longer than usual to redraw and is laggy switching between windows, apps often force close or take forever to start up, and the browser reacts much more slowly to pinches, swipes, etc.
Thanks!
tl;dr: CM9 users, please share your performance + memory management settings. Explanations not required, though appreciated.
niiiiick said:
Hello everyone,
I've been using the cm9 release candidate since it was released, and still can't figure out how to make it snappy (I was on Apex before, and found it much more responsive). I'm not sure which the performance/memory management settings the Nexus S can handle well (there are lots of other threads for other phones, but I'm not sure if some of the settings require better hardware), so I'd appreciate it if anybody could tell me what they've found to be good for the following options:
Performance settings:
- Surface dithering
- 16bit transparency
Memory management:
- Allow purging of assets
- Kernel samepage merging
Misc. information that may or may not be relevant:
- Using Matr1x kernel (CFS, v21.0 I think)
- Processor is running at 200/1200 most of the time, ondemand governor (same settings that used to give me great performance on Apex).
- Also tried running Supercharger script, but it didn't seem to change things as much as it usually does
- Fixing permissions didn't fix it
- Battery life seems fine
- What I mean by "unresponsive" is that the launcher takes longer than usual to redraw and is laggy switching between windows, apps often force close or take forever to start up, and the browser reacts much more slowly to pinches, swipes, etc.
Thanks!
tl;dr: CM9 users, please share your performance + memory management settings. Explanations not required, though appreciated.
Click to expand...
Click to collapse
You don't need to mess with those settings.
Besides, if your applications FC, it's likely because of:
a) instability regarding your overclock
b) instability regarding the undervolt that matr1x kernel comes with
c) the fact v21 was canned due to being judged unstable by so many, upgrade to v22
d) all of these
Cheers
If you don't know what a setting does, don't change it. Messing with the CM performance settings if you don't know what you're doing is a great way to mess your phone up.
063_XOBX said:
If you don't know what a setting does, don't change it. Messing with the CM performance settings if you don't know what you're doing is a great way to mess your phone up.
Click to expand...
Click to collapse
are you completly retarded? there doesnt happen much when you change the settings there. you are talking like the settings are just for pros and he is a kid, lol. kernel samepage merging for example just "bonding" two similiar proccesses so they dont need too much ram.
Fensterbank said:
are you completly retarded? there doesnt happen much when you change the settings there. you are talking like the settings are just for pros and he is a kid, lol. kernel samepage merging for example just "bonding" two similiar proccesses so they dont need too much ram.
Click to expand...
Click to collapse
Are you? This thread has been dead for almost 3 months. The OP had his answer. Resurrecting this thread just to argue is incredibly pointless.
I have an idea to replace some stuff from kernel tweaks and make dynamic virtual memory based on screen state. So kernel tweaks will be much more than light, and i will probably remove them due to pointless after we do dynamic stuff.
I have an idea fine tuning them.
I have not voted but will simply note the desirability/effectiveness of "dynamic virtual memory" will depend on what is done. Virtual memory settings can have a noticeable impact on performance (responsiveness), both positive and negative. Good luck!
Exactly @Davey126
I have some ideas
Initial stuff is under testing, i'll see how it'll work.