Related
Hi,
I was curious why the Hero sometimes is blazing fast, and sometimes so incredible slow. That is why I decided to root the device to see what's going on in the device with top and other tools...
This is what is showing up, right after booting the device (sorted on memory usage and not showing kernel processes:
Code:
PID CPU% S #THR VSS RSS UID Name
123 12% S 12 239468K 43276K nobody com.htc.launcher
67 5% S 50 212448K 35532K system system_server
119 0% S 14 140420K 24796K misc android.process.acore
36 0% S 1 72644K 21680K root zygote
121 0% S 18 120660K 21200K radio com.android.phone
383 0% S 15 118140K 20328K app_40 com.htc.android.mail
214 0% S 13 109376K 17696K app_3 com.google.process.gapps
258 3% S 8 108124K 17636K app_5 com.android.mms
363 0% S 9 182892K 16784K app_25 com.android.calendar
336 0% S 8 95792K 16384K app_22 com.htc.android.psclient
301 0% S 7 102784K 15392K app_12 com.google.android.apps.maps:FriendS
ervice
486 0% S 5 177860K 15364K app_78 org.koxx.pure_calendar
271 0% S 8 95904K 15264K app_6 android.process.media
346 0% S 8 97212K 15120K app_15 com.htc.dcs
495 0% S 6 110632K 15056K app_68 com.tunewiki.lyricplayer.android:pla
yer
460 0% S 6 96336K 14688K app_41 com.htc.android.footprints
477 0% S 6 95972K 14496K app_24 com.htc.album
390 0% S 6 102280K 13956K app_25 com.htc.calendar
176 0% S 7 100340K 13928K app_26 com.htc.socialnetwork.provider
443 0% S 5 94192K 13912K app_53 net.rgruet.android.g3watchdog
448 0% S 6 96240K 13616K app_59 com.biggu.shopsavvy
293 0% S 5 93400K 13492K app_9 com.htc.htctwitter
469 0% S 6 100004K 13488K system com.android.settings
328 0% S 6 94660K 13316K app_17 com.htc.android.worldclock
249 0% S 5 93420K 13280K app_80 com.socialnmobile.hangulkeyboard
524 0% S 6 94024K 13248K app_48 com.htc.htclocationservice
376 0% S 6 93772K 13204K app_32 com.htc.providers.uploads
515 0% S 6 94324K 12620K app_13 com.google.android.gm
318 0% S 6 92960K 12460K app_21 com.htc.provider.weather
306 0% S 8 94976K 12140K app_19 com.htc.provider.settings
431 0% S 5 92016K 11708K app_73 com.rechild.advancedtaskkiller
417 0% S 6 99156K 11684K app_45 com.google.android.partnersetup
37 0% S 9 29752K 5360K media /system/bin/mediaserver
100 0% S 2 3124K 1156K wifi /system/bin/wpa_supplicant
35 0% S 9 11068K 1152K radio /system/bin/rild
38 0% S 1 1180K 740K bluetoot /system/bin/dbus-daemon
41 0% S 1 1196K 580K compass /system/bin/akm8973
131 0% S 1 856K 428K dhcp /system/bin/dhcpcd
33 0% S 1 852K 400K root /system/bin/vold
538 4% R 1 916K 376K shell top
537 0% S 1 740K 332K shell /system/bin/sh
39 0% S 1 800K 308K root /system/bin/installd
32 0% S 1 808K 268K system /system/bin/servicemanager
34 0% S 1 668K 268K root /system/bin/debuggerd
1 0% S 1 292K 204K root /init
43 0% S 4 3332K 164K shell /sbin/adbd
What I don't understand is why for example tunewiki has a memory intensive task in resident memory while i've never started it up. Also these processes I maybe (almost) never use , why on earth start them for me?:
com.android.mms
com.htc.htctwitter
com.biggu.shopsavvy
Also the android calendar seems unnessesary because of the HTC calendar?
Why is the system keeping these processes in memory when they are not used? That seems like a waste of memory to me..
I know Android has a particular view on proces lifecycle management, however when I start a program, it may not use many CPU cycles but it does use and keep memory for itself...
I read somewhere that when a program/process is not used the memory is "unloaded" on the internal memory to free up some space, and reloaded when you use the program again.
But i can be wrong, I don't remember where I saw that.
Yeah... But top tells me otherwise.. I think the application stays resident (RSS) but CPU cycles are kept to a minimum. I think this is design when you leave an application with no service:
- Stop CPU cycles
- Leave memory footprint until needed otherwise
sorry my previous message was not clear (and my english is quite bad)
What I remember is that the process is still active (so you can see it with top) but the memory (RAM) is unloaded and saved on the internal storage. When you start the process again it just reload the data to the RAM
Why are you worried about memory usage? These days many operating systems pre-fetch apps so they load quicker. I imagine Android has just selected certain apps to pre-fetch. Remember, empty RAM is wasted RAM!
I would be more concerned with cpu cycles if I were you.
kiz said:
Why are you worried about memory usage? These days many operating systems pre-fetch apps so they load quicker. I imagine Android has just selected certain apps to pre-fetch. Remember, empty RAM is wasted RAM!
I would be more concerned with cpu cycles if I were you.
Click to expand...
Click to collapse
pre-fetching apps is somewhat different than keeping programs in RSS. What I see in top is that programs stay in resident memory, which is not easely reclaimable. It then will take (a lot) of CPU cycles to free up and re-fill this memory, so there is a relation...
What I do see in practice is that android is sometimes slow and sometimes quite fast, without changing anything obvious. I was/am looking for a reason for this symptom.
That is why I rooted the thing to be able to see some low level system stat's. In top I see that a lot of programs stay in resident memory which is normaly not good in linux/unix land..
If there is an detail design of how Android does this, I would really like to see it (and hope that i'll understand it). By the way, I have seen the presentation of process lifecycle management, but this describes inactive applications as "saved" which i presume is not keeping it in memory.
And indeed emtpty ram will probably never happen with a linux kernel because of caching an buffering...
just use taskiller app all the time
darkpython666 said:
just use taskiller app all the time
Click to expand...
Click to collapse
Hmm.. i would like to approach it a more scientific way.. A good OS should not need you to do that..
http://linux.derkeiler.com/Mailing-Lists/Kernel/2009-01/msg05142.html
As I can see it, tuning could be done in the init.rc scripts and in particular this section which adresses the out of memory (oom) killer:
Code:
# Define the oom_adj values for the classes of processes that can be
# killed by the kernel. These are used in ActivityManagerService.
setprop ro.FOREGROUND_APP_ADJ 0
setprop ro.VISIBLE_APP_ADJ 1
setprop ro.SECONDARY_SERVER_ADJ 2
setprop ro.HOME_APP_ADJ 4
setprop ro.HIDDEN_APP_MIN_ADJ 7
setprop ro.CONTENT_PROVIDER_ADJ 14
setprop ro.EMPTY_APP_ADJ 15
# Define the memory thresholds at which the above process classes will
# be killed. These numbers are in pages (4k).
setprop ro.FOREGROUND_APP_MEM 1536
setprop ro.VISIBLE_APP_MEM 2048
setprop ro.SECONDARY_SERVER_MEM 4096
setprop ro.HOME_APP_MEM 4096
setprop ro.HIDDEN_APP_MEM 5120
setprop ro.CONTENT_PROVIDER_MEM 5632
setprop ro.EMPTY_APP_MEM 6144
# Write value must be consistent with the above properties.
# Note that the driver only supports 6 slots, so we have HOME_APP at the
# same memory level as services.
write /sys/module/lowmemorykiller/parameters/adj 0,1,2,7,14,15
write /proc/sys/vm/overcommit_memory 1
write /proc/sys/vm/min_free_order_shift 4
write /sys/module/lowmemorykiller/parameters/minfree 1536,2048,4096,5120,563
2,6144
# Set init its forked children's oom_adj.
write /proc/1/oom_adj -16
I'm wondering the same thing lately as I try to speed up my Droid. With OSMonitor's new cpu graph in the notification area, I noticed my cpu usage was very high a good deal of the time. So I rebooted and watched it stay at 99% for a while. I went to watch the processes and it was tunewiki, mixzing and camera (android.media) taking up all the cpu. I hadn't started any of them. Tunewiki was over 90% for several minutes. I would understand an initial scan, but it's been installed for over 24 hours so I don't know what the hell it could still be doing. I have about 14GB of music on the SD right now, so I'm wondering if it has to scan through that on every reboot.
I wouldn't get too hung up about memory usage. The most important thing that will chew battery and slow down your device is CPU. And that is going to be up to the app developer and how they design things. Ideally, you want to write your program so that it doesn't run all the time - that is, it has a sleep state. If all your apps play nice and sleep when they are put in the background, your OS can then go into a hibernate mode when not being used by you (not tapping on the keyboard or doing other things interactively with it). This saves battery because hibernate allows halting the CPU cycles (when the CPU is awake, when it is not doing anything related to any app, it will be executing the equivalent of a NOP, which still chews battery). Also, if you have programs that don't allow a sleep (or rarely) , other apps get starved of cycles, hence you see a slow down.
As for your question as to why you have other processes at boot, some apps are written to start at boot. That was how the developer intended it to work. And some of these things, you don't want to kill. Some of these are even part of the core Android or HTC Sense, and if you kill it, Android will die an ugly death - try killing HTC Checkin and see how your Hero takes that!
If your system needs RAM, it will start swapping inactive app data out of active memory onto the swap. Use "free" in busybox, to gauge if anything got moved out to swap.
what is this "top" process ?
This issue has been covered in great detail and length throughout this thread:
http://forum.xda-developers.com/showthread.php?t=622666
I think most recent ROMs use higher values for the low memory killer. The trick is to find values that will on the one hand keep as much free memory for fast loading of new apps and disk caching. But on the other hand, you don't want apps too close to fast - i.e. switch from your browser to check an SMS and return to find it has been killed and needs to reload. Even worse, since the hero has a relatively low amount of physical memory, it is pretty easy to reach values which kill background services like your SMS program and then you start missing messages....
I will also say, that to the best of my knowledge, you are wrong that apps you never used open up. It might not kill apps which are not in use any more, but any app which see there was loaded for a reason. For example for the calender, I assume HTC's calender app still uses the stock calender under the hood - try to remove it and see what happens.
erasmux said:
This issue has been covered in great detail and length throughout this thread:
http://forum.xda-developers.com/showthread.php?t=622666
I think most recent ROMs use higher values for the low memory killer. The trick is to find values that will on the one hand keep as much free memory for fast loading of new apps and disk caching. But on the other hand, you don't want apps too close to fast - i.e. switch from your browser to check an SMS and return to find it has been killed and needs to reload. Even worse, since the hero has a relatively low amount of physical memory, it is pretty easy to reach values which kill background services like your SMS program and then you start missing messages....
I will also say, that to the best of my knowledge, you are wrong that apps you never used open up. It might not kill apps which are not in use any more, but any app which see there was loaded for a reason. For example for the calender, I assume HTC's calender app still uses the stock calender under the hood - try to remove it and see what happens.
Click to expand...
Click to collapse
In my option, for the little hero to run Sense 2.1 you need a lite version (Salsa Lite), so you can use whatever you like... But it seems that from the lack of processor power, hero lags.
On the other hand, if you want a new version of android, a stock version is more of use, but if you miss Sense(like i do), you get bored of it.
@ erasmux => can you make a .zip file that removes recent applications in the Sense 2.1 status bar, i think it's one of the sources that make the rom laggy...
stefpaul said:
In my option, for the little hero to run Sense 2.1 you need a lite version (Salsa Lite), so you can use whatever you like... But it seems that from the lack of processor power, hero lags.
On the other hand, if you want a new version of android, a stock version is more of use, but if you miss Sense(like i do), you get bored of it.
@ erasmux => can you make a .zip file that removes recent applications in the Sense 2.1 status bar, i think it's one of the sources that make the rom laggy...
Click to expand...
Click to collapse
I am not currently actively supporting any Android 2.3+ Sense ROMs. If and when I release future Sense ROMs, I will see if I find the time for this.
I've been playing with my Archos 43, and found a cool way to almost double the speed of 2D graphics and somewhat increase 3D graphics speed (as measured with AnTuTu), and probably decrease memory usage, at the expense of display quality.
Just switch the device into 16-bit display mode.
Code:
su
fbset -fb /dev/graphics/fb0 -g 480 854 480 854 16 -n ; killall zygote
One could set this up on boot, but I haven't figured out how to run any scripts before zygote starts using Chulri's rw root.
To switch back to 32-bit, just do a normal reboot, or:
Code:
su
fbset -fb /dev/graphics/fb0 -g 480 854 480 854 32 -n ; killall zygote
---------- Post added at 05:38 AM ---------- Previous post was at 05:18 AM ----------
Alas, 16-bit breaks the Archos video player and Youtube. On the other hand, Netflix works fine.
HI,
what is the difference with chainfire 3D?
As far as I know, ChainFire3D switches texture bit depth, but still leaves the bit depth of the screen as a whole unchanged. In particular, setting to 16-bit textures in CF3D may help with some 3D apps, but will have no effect on 2D performance. Setting to 16-bit mode in the above way almost doubles 2D performance, at the expense of quality and complete loss of Youtube/Archos Video. One should be able to combine the 16-bit setting above with CF3D.
Of course, if you've got a different device, you'll need different resolution numbers. You can find out your numbers with:
Code:
su
fbset -fb /dev/graphics/fb0
Further investigation: the fbset command doesn't require root on Gen8 if executed in adb, so you can do this on a non-rooted device.
I did some more benchmarks. In these, the performance gain is more moderate, probably because I was previously comparing to a system that was configured less well in other ways.
There is still a 38% performance gain for 2D applications with CF3D off.
Some AnTuTu benchmarks on the A43:
32-bit display, CF3D off:
2D: 344
3D: 718
32-bit display, CF3D set to reduce textures to 16-bit:
2D: 378
3D: 726
32-bit display, CF3D set to unroll textures to 32-bit:
2D: 432
3D: 712
16-bit display, CF3D off:
2D: 478 (average of two tests)
3D: 711
16-bit display, CF3D set to reduce textures to 16-bit:
2D: 408
3D: 756
16-bit display, CF3D set to unroll textures to 32-bit:
2D: 426
3D: 716
I can not confirm any positive affect of the 16bit setting on my A70s. The scripts seem to work, the system reboots and the fbset reports 16 bit as expected. But the 2D benchmark staid the same around 275 in Antutu for both 16 and 32 bit settings. Worse: my system needed a cold reset to get archos video back working.
old_pocket said:
I can not confirm any positive affect of the 16bit setting on my A70s. The scripts seem to work, the system reboots and the fbset reports 16 bit as expected. But the 2D benchmark staid the same around 275 in Antutu for both 16 and 32 bit settings. Worse: my system needed a cold reset to get archos video back working.
Click to expand...
Click to collapse
Oh, well.
I wonder, by the way, why your 2D benchmark is so much lower on your A70 than on my A43. Is your max CPU speed set to 1ghz?
I used uruk 1.6b1 with 1200/300 setting via setcpu. I tried different constant settings to see if there would be a dependency:
I got more or less constant 275 for frequencies from 1200 to 800, 365 for 600 MHz and 300 for 300 MHz. Very strange.
I'm also seeing the CPU speed as not mattering much. I just got 353 with 300MHz and 419 with 1000MHz.
What is your debug.sf.hw setting? You can do:
Code:
getprop | grep debug.sf.hw
to check.
Normally, I have it set to debug.sf.hw=1.
If I set debug.sf.hw=0, I get a maximum of 200 on AnTuTu 2D, and the value seems to vary more with CPU speed. I am guessing that with hardware acceleration enabled, it's the GPU speed and memory bus speed that matter, not the CPU speed.
I'm also using this script to optimize memory management. I haven't tested enough to see if it makes a difference.
Good idea. I tried out your grep. As you might have expected: nothing, means that =1 is active by default. Tried out =0 by editing build.prop resulting in around 100 values. No real improvement...
I tried something different, booted stock 2.4.19 Archos Android and here you go: values around and above 400. In comparison you can see that it is a lot faster.
Maybe this is caused by the increased clock rate / "fluidity" of the new Archos firmware. Hopefully sauron will get his pad back soon. This seems to be a good chance to get even better performance on uruk.
old_pocket said:
Good idea. I tried out your grep. As you might have expected: nothing, means that =1 is active by default. Tried out =0 by editing build.prop resulting in around 100 values. No real improvement...
I tried something different, booted stock 2.4.19 Archos Android and here you go: values around and above 400. In comparison you can see that it is a lot faster.
Maybe this is caused by the increased clock rate / "fluidity" of the new Archos firmware. Hopefully sauron will get his pad back soon. This seems to be a good chance to get even better performance on uruk.
Click to expand...
Click to collapse
Have you tried the Sibere kernels that are based on the 2.4.19 source but with uruk additions?
I just now tried Sibere_OCUV_SB from: http://forum.xda-developers.com/showpost.php?p=17443339&postcount=2069
No problem with the undervolting, but something in his newer kernels seems to render my USB port useless, like the one I tried a few weeks before. On the other hand no positive effect with this on the 2D benchmark, around 275 as before. I remember a conversation between sauron and sibere speculating that Archos modification was not in the kernel but in the firmware.
old_pocket said:
I just now tried Sibere_OCUV_SB from: http://forum.xda-developers.com/showpost.php?p=17443339&postcount=2069
No problem with the undervolting, but something in his newer kernels seems to render my USB port useless, like the one I tried a few weeks before. On the other hand no positive effect with this on the 2D benchmark, around 275 as before. I remember a conversation between sauron and sibere speculating that Archos modification was not in the kernel but in the firmware.
Click to expand...
Click to collapse
I wouldn't be surprised if some of the changes were in the libraries, especially libsurfaceflinger, libskiahw and libskia. You could try pulling in new versions of these libraries.
$aur0n said:
It would be good to start another topic for overclocking (with values that works, perhaps scores) - anyone willing to gather this data?
With this it will be easier for people to setup their values...
Click to expand...
Click to collapse
Please post your results by using overclocking under UrukDroid here. For benchmark results please use Quadrant Standard Edition. You can download it for free on Android Market. And don't forget to say if you think your configuration is stable.
A70it
Board Version: A70S-V6
Uruk:
1.6RC4
settings:
max_vsel=65
max_rate=1100000
I think the results may be different because the fabrication of the CPU's is also a reason.
stable: yes
tested: browsing, games like Angry Birds, Dungeon Hunter....
Quadrant Score: 1706-1460
UrukDroid:
1.6RC4
settings:
max_vsel=60
max_rate=1100000
stable:yes
tested apps : games (angry birds , NFS , air attack , dragon fly , racingmoto ) , browsing , music , videos
quadrant Score:1581-1162
Uruk:
1.6RC4
settings:
max_vsel=60
max_rate=1050000
stable:yes
tested apps : games (My Country)
A101IT
Board Version: A101IT-V6
Uruk:
1.6RC4
settings:
max_vsel=60
max_rate=1050000
stable:yes
tested apps: games (angry birds, flick soccer, homerun battle, 3d bowling, basketball shoot)
quadrant score: 1465
i always fail to overclock. whats the forum thread to a successful overclock on archos gen8. i use setcpu it only remains on 1000, urukdroid 1.6rc4
thx
You first need to configure the kernel module, as SetCpu is only there for switching the maximum down from what the tables are saying.
@All:
Please also state Model ( A101,A70S,A70H,A43,A28) and if possible boardversion.
rc4
archos 70 it
I use text editor to change the values to 65 and 1100000 but the editor won't let me save the changes
You need one that has Root when editing.
fzelle said:
You need one that has Root when editing.
Click to expand...
Click to collapse
Yes, one like Root Explorer
A70it
Board Version: A70S-V6
Uruk:
1.6RC4
settings:
max_vsel=67
max_rate=1100000
stable: yes or almost (see below)
tested: browsing, games like Angry Birds, YouTube, Market....
Quadrant Score: not tested
Remarks: [email protected] did not seem stable: FC's, strange behaviour. So I bumped the volts a notch. This seems stable, but not yet entirely sure. It may need just a bit more, 68, 69 or even 70...
For understanding more, I did the calc how much volts the different vsels really yield (based on $auron's formula )
vsel
60 = 1,35V (default for 1Ghz)
65 = 1,4125V
67 = 1,4375V
70 = 1,475V
---------- Post added at 11:41 AM ---------- Previous post was at 11:40 AM ----------
rapunzel11 said:
Yes, one like Root Explorer
Click to expand...
Click to collapse
Well I have some strange issues with that too. Before updating to RC4 it would always be ok to use FileExpert in root mode to edit the file. But now, that leads to error when saving, ie no rights.
I have to go into FileManager or what the other thing is called (also root capable), rename the cpugovernor to cpugovernor.txt, edit it, then I can save. Then rename it, (re)start CPUGovernor: then the settings DO take succesfully.
Archos 70it.
I have tried 1.6rc4 both with 1.6b1 kernelocuv and with 1.6rc4 at 60& 1100000.
Both were stable and fast. I may prefer the first one.
Are there any advantages- disadvantages to either of them?
arie_i said:
Archos 70it.
I have tried 1.6rc4 both with 1.6b1 kernelocuv and with 1.6rc4 at 60& 1100000.
Both were stable and fast. I may prefer the first one.
Are there any advantages- disadvantages to either of them?
Click to expand...
Click to collapse
Well yes - second on is better You can do ALL what was done in OCUV (just rewrite cpu table) in RC5+ - but you may disable it with few clicks and test configuration that suits you best.
ps. I've added link to this thread in manual for overclocking.
ps2. Free "root capable" file explorer is FileExpert (default file manager since UrukDroid 1.5) - you just need to enable this feature in it's configuration menu.
@$aur0n
I have installed UrukDroid 1.6.4 and wanted to overclock the Archos 101 with the help of you manual.
My current cpugovernor stats output:
Code:
Uruk-CPUGovernor statistics:
Current governor: interactive
Overclock module: Enabled
Current max vsel: 66
Current max rate: 1000000
CPU Max: 1000000
CPU Min: 300000
Available frequencies: 1000000 800000 600000 300000
CPU statistics (tick spend in every frequency range):
1 GHz had 17458 ticks (8.18%)
800 MHz had 20275 ticks (9.50%)
600 MHz had 31112 ticks (14.58%)
300 MHz had 144634 ticks (67.75%)
Then I try to manualy set the vsel and rate with:
Code:
echo 66 > /proc/overclock/max_vsel
echo 1000000 > /proc/overclock/max_rate
and whatever numbers I set, the Archos reboots instantly. I even tried setting max_rate to 900000 and it also rebooted!?
What am I doing wrong?
Thanks
Edit:
I did the rest in your manual and set the right memory addresses... damn, I thought these are automatically set - it seems they could be. Now lets try to set the real max
Edit2:
OC = 1.1Ghz ; Max_vsel=68 == Enough for me.
I have just installed Urukdroid 1.6 on my Gen8 A101T.
Sorry to be a bit thick, but how to I know test how much it can be overclocked?
Hi there!
I broke my main phone, so nexus my daily driver again. And I was wondering what firmware is the fastest for now. Is android pie usable?
So i did some tests, maybe someone will be interested. I don't pretend that these tests are ideal, maybe they should have been done differently. I just share the results with you. So this is 3 points: 1 - antutu benchmark total score, CPU and GPU scores (not for all). 2 - time (in seconds) of cold start apps, there are google maps, opera, youtube. 3 - just my impressions of surfing UI.
Every time I set up phone the same (as new device, update only essential google services). All ROMs are last version (on post date) and tested with Francos Kernel.
Stock google firmware 7.1.1 - 1. Antutu total score 87218, CPU - 28808, GPU - 15845. 2. G maps - 7, Opera - 4.5, Youtube - 2.6 3. Working perfect.
Pure Nexus 7.1.2 - 1. Antutu total score 78437 2. G maps - 11.5, Opera - 7, Youtube - 5.5. 3. lags a little, not critical.
Lineage 15 8.1 - 1. Antutu total score 89129, CPU - 34635, GPU - 15803. 2. G maps - 8.2, Opera - 5.7, Youtube - 3.3. 3. Pretty fast almost like stock.
Lineage 16 9 - 1. Antutu total score 51110, CPU - 12170, GPU - 11277. 2. G maps - 8.5, Opera - 6.4, Youtube - 4.7. 3. Extremely lagging and freezing
Carbon 9 - 1. Antutu total score 85854, CPU - 29425, GPU - 15917. 2. G maps - 13.2, Opera - 7.8, Youtube - 5.3. 3. Lagging, but much better then Lineage 16
So I stopped at Lineage 15, I installed all my apps e.t.c. and for now - 1. Antutu - 102262. CPU - 44223 GPU - 15747. 2. G maps - 8.9. Opera - 5.6, Youtube -4.2. 3. start lagging a little, but usable.
Hope someone thought it was interesting. I apologize if I made mistakes, English isn't my native language, but I'm trying
eatmystyle said:
Lineage 16 9 - 1. Antutu total score 51110, CPU - 12170, GPU - 11277. 2. G maps - 8.5, Opera - 6.4, Youtube - 4.7. 3. Extremely lagging and freezing
Carbon 9 - 1. Antutu total score 85854, CPU - 29425, GPU - 15917. 2. G maps - 13.2, Opera - 7.8, Youtube - 5.3. 3. Lagging, but much better then Lineage 16
So I stopped at Lineage 15, I installed all my apps e.t.c. and for now - 1. Antutu - 102262. CPU - 44223 GPU - 15747. 2. G maps - 8.9. Opera - 5.6, Youtube -4.2. 3. start lagging a little, but usable.
Hope someone thought it was interesting. I apologize if I made mistakes, English isn't my native language, but I'm trying
Click to expand...
Click to collapse
I guess something is wrong with your test, as Carbon 9 uses Lineage's sources for shamu. So the score should be about the same.
How long did you wait after the flash? Was the device in thermal throtteling mode?
Edit:
Oh I just read, that you use Franco Kernel which isn't meant to be used on Lineage as it is outdated as hell.
Leaving Antutu scores aside, what i feel for my experience, is that Pure Nexus 7.1.2 still the most faster N6 rom.
Another "kernel optimizer"?
No. Well, yes. However, a "kernel optimizer" is a poor way to put it. KTweak performs kernel adjustments based on facts and evidence, unlike other optimizers with poorly written or heavily obfuscated code. For example:
LSpeed is almost 4000 lines long; completely unnecessary.
NFS Injector uses compiled binaries that are closed source... yuck. Not to mention the typos in the README. This one is hard to look at.
LKT sets random nonsensical build.props that likely don't even exist.
MAGNETAR uses (you guessed it) compiled binaries that install themselves to your /system/etc/ directory (???). Great idea, install an external closed source, compiled binary to the system partition.
Need I go on?
What's different about KTweak?
Unlike other "kernel optimizers", KTweak is:
Concice, at around 200 lines long,
Entirely open source with no compiled components,
Backed by logic and evidence,
Designed by an experienced kernel developer,
Non-intrusive, being completely systemless.
Benchmarks
The following benchmarks were performed on a OnePlus 7 Pro running the stock kernel provided by the OEM on Android 10.
hackbench -pTl 4000 (lower is better)
Without KTweak: ~20-50 seconds on average
With KTweak: ~4-6 seconds on average
perf bench mem memcpy (lower is better) (average of 50 iters)
Without KTweak: 14.01 ms
With KTweak: 10.40 ms
synthmark (voicemark) (higher is better)
Without KTweak: 374.94
With KTweak: 383.556
synthmark (latencymark little) (lower is better)
Without KTweak: 10
With KTweak: 10
synthmark (latencymark big) (lower is better)
Without KTweak: 12
With KTweak: 10
The Tweaks
In order to remain genuine, I have commited to explaining each and every kernel tweak that KTweak applies. Grab your coffee, this could take a while.
kernel.perf_cpu_time_max_percent: 25 --> 5
This is the maximum CPU time long perf event processing can take as a percentage. If this percentage is exceeded (meaning perf event processing used too much CPU time), the polling rate is throttled. This is reduced from 25% to 5%. We can afford inaccuracies with perf events in exchange for more time that a foreground task can use.
kernel.sched_autogroup_enabled: 0 --> 1
The Linux Kernel scheduler (CFS) distributes timeslices to each active task. For example, if the scheduling period is 10ms, and there are 5 tasks running, CFS will give each task 2ms of runtime for that scheduling cycle. However, this means that a SCHED_OTHER task may compete with a SCHED_FIFO task. Autogrouping groups task groups together during scheduling. For example, if the scheduling period is 10ms, and there are 6 SCHED_OTHER tasks running and 4 SCHED_FIFO tasks running, the SCHED_OTHER tasks will get 50% of the runtime and the SCHED_FIFO tasks will get the other 50%. For each task group, the timeslices are once again divided. The SCHED_FIFO tasks will get 12.5% runtime and the SCHED_OTHER tasks will get ~8.3% runtime. This usually offers better interactivity on multithreaded platforms. See scheduling priority documentation: https://man7.org/linux/man-pages/man7/sched.7.html See autogrouping off: https://www.youtube.com/watch?v=uk70SeGA7pg See autogrouping on: https://www.youtube.com/watch?v=prxInRdaNfc
kernel.sched_enable_thread_grouping: 0 --> 1
To my knowledge using the limited documentation of this tunable, this is basically autogrouping for thread groups.
kernel.sched_child_runs_first: 0 --> 1
When forking a child process from the parent, execute the child process before the parent process. This usually shaves down some latency on task initializations, since most of the time the child process is doing some form of heavy lifting.
kernel.sched_downmigrate: 20 20
Do not allow tasks to migrate back down to a lower-power CPU until the estimated CPU utilization would go below 20% on said CPU. This means tasks will stay on higher-performance CPUs for longer than usual.
kernel.sched_upmigrate: 80 80
Similar to the previous tunable, do not allow CPUs to migrate to the higher-performance CPUs unless the utilization goes above 80%.
kernel.sched_group_downmigrate: 20
The same as kernel.sched_downmigrate, except for whole task groups.
kernel.sched_group_upmigrate: 80
The same as kernel.sched_upmigrate, except for whole task groups.
kernel.sched_tunable_scaling: 0
This is more of a precaution than anything. Since the next few tunables will be scheduler timing related, we don't want the scheduler to scale our values for multiple CPUs, as we will be providing CPU-agnostic values.
kernel.sched_latency_ns: 10000000 (10ms)
Set the default scheduling period to 10ms. If this value is set too low, the scheduler will switch contexts too often, spending more time internally than executing the waiting tasks.
kernel.sched_min_granularity_ns: 1000000 (1ms)
Set the minimum task scheduling period to 1ms. With kernel.sched_latency_ns set to 1ms, this means that 10 tasks may execute within the 10ms scheduling period before we exceed it.
kernel.sched_migration_cost_ns: 500000 (0.5ms) --> 1000000 (1ms)
Increase the time that a task is considered to be cache hot. According to RedHat, increasing this tunable reduces the number of task migrations. This should reduce time spent balancing tasks and increase per-task performance. See RedHat: https://www.redhat.com/files/summit...tuning-of-Red-Hat-Enterprise-Linux-Part-1.pdf
kernel.sched_min_task_util_for_boost: 25
This value effects if tasks should be migrated to a higher performant CPU if it's utilization is above this amount. Allow tasks to be migrated upwards if the user is triggering a touch boost and the task is above 25% utilization.
kernel.sched_min_task_util_for_colocation: 50
This value is the same as the former, except it occurs when the user is not touching the screen. We shouldn't upmigrate tasks if the user isn't actively interacting with them (i.e. video streaming).
kernel.sched_nr_migrate: 32 --> 64
When migrating tasks between CPUs, allow the scheduler to migrate twice as many as usual. This should increase scheduling latency marginally, but increase the performance of SCHED_OTHER tasks.
kernel.sched_schedstats: 1 --> 0
Disable scheduler statistics accounting. This is just for debugging, but it adds overhead.
kernel.sched_wakeup_granularity_ns: 1000000 (1ms) --> 5000000 (5ms)
Require the current task to be surpassing the new task in vmruntime by 5ms instead of 1ms before preemption occurs. This should reduce jitter due to less frequent task interruptions.
kernel.timer_migration: 1 --> 0
Disable the migration of timers among CPUs. Usually, when a timer is created on one CPU, it would be able to be migrated to another CPU. However, this increases realtime latencies and scheduling interrupts. It can be turned off.
net.ipv4.tcp_ecn: 2 --> 1
Enable Explicit Congestion Notification for incoming and outgoing negotiations. This reduces packet losses.
net.ipv4.tcp_fastopen: 3
Enable data transmission during the SACK exchange point in TCP negotiation. This reduces packet latencies. Enable it for senders and receivers.
net.ipv4.tcp_syncookies: 1 --> 0
This tunable, when enabled, prevents denial of service attacks by allowing connection ACKs to be tracked. However, this is more-or-less unnecessary for a mobile device. It is more applicable for servers. Disable it.
net.ipv4.tcp_timestamps: 1 --> 0
RedHat claims that TCP timestamps may cause performance spikes due to time accounting code on high-performance connections. Disable it. See RedHat: https://access.redhat.com/documenta...ml/tuning_guide/reduce_tcp_performance_spikes
vm.compact_unevictable_allowed: 1 --> 0
Do not allow compaction of unevictable pages. With this set to 1, more compactions can happen at the cost of small page fault stalls. Turn this off to compact less but avoid aforementioned stalls.
vm.dirty_background_ratio: 5 --> 10
Start writing back dirty pages (pages that have been modified but not yet written to the disk) asynchronously at 10% memory dirtied instead of 5%. Writing dirty pages back too early can be inefficient and overutilize the storage device.
vm.dirty_ratio: 20 --> 30
This tunable is the same as the former, but it is the ceiling for synchronous dirty writeback, meaning all I/O will stall until all dirty pages are written out to the disk. We usually won't need to worry about hitting this value, as the background writeback can catch up before we reach 20% memory dirtied. But as a precaution (i.e. heavy file transfers), increase this value to a 30% ceiling to prevent visible system stalls. We are sacrificing available memory in exchange for a reduced change of a brief system stall.
vm.dirty_expire_centisecs: 300 (3s) --> 1000 (10s)
This is the longest that dirty pages can remain in the system before they are forcefully written out to the disk. By increasing this value, we can allow the dirty background writeback to take its time asynchronously, and avoid unnecessary writebacks that can clog the flusher thread.
vm.dirty_writeback_centisecs: 500 (5s) --> 0 (0s)
Do not periodically writeback data every 5 seconds. Instead, leave it to the dirty background writeback to wake up when the dirty memory of the system hits 10%. This allows the dirty pages to stay in memory for longer, possibly increasing cache locality as the page cache is still available in memory.
vm.extfrag_threshold: 500 --> 750
Compact memory more often, even if the memory allocation was estimated to be due to a low-memory status. This lets us put more data into RAM at the expense of running compation more often. This is a worthy tradeoff, as it reduces memory fragmentation, which is incredibly important for ZRAM.
vm.oom_dump_tasks: 1 --> 0
Do not dump debug information when (or if) we run out of memory. If we have a lot of tasks running, and are OOMing often, then this overhead can add up.
vm.page-cluster: 3 --> 0
Disable reading additional pages from the swap device (in most cases, ZRAM). This is the same philosophy as disabling readahead.
vm.reap_mem_on_sigkill: 0 --> 1
When we kill a task, clean its memory footprint to free up whatever amount of RAM it was consuming.
vm.stat_interval: 1 --> 10
Update /proc/stat information every 10 seconds instead of every second, reducing jitter on loaded systems.
vm.swappiness: 100 --> 80
Swap to ZRAM less often if we don't have to. ZRAM can become expensive due to constant compression and decompression. If we can keep some of the memory uncompressed in regular RAM, we can avoid that overhead.
vm.vfs_cache_pressure: 100 --> 200
This tunable controls the kernel's tendency to reclaim inodes and dentries over page cache. Inodes and dentries are information about file metadata and directory structures, while page cache is the actual cached contents of a file. By increasing this value to 200, we tell the kernel to prefer claiming inodes and dentries over the page cache, increasing the chance of a cache hit when referencing recently used data, while not polluting the RAM with less-important information.
Next Buddy
By scheduling the last woken task first, we can increase cache locality since that task is likely to touch the same data as before.
No Strict Skip Buddy
Usually, the scheduler will always choose to skip tasks that call yield(). However, these yeilding tasks may be of higher importance than the last or next buddy that are available. Do not always skip the skip buddy if we don't have to.
No Nontask Capacity
The scheduler decrements the perceived CPU capacity that longer the CPU has been idle for. This means that an idle CPU may be skipped during task placement, and a task can be grouped with a busier CPU. Disable this to improve task start latency.
TTWU Queue
Allow the scheduler to place tasks on their origin CPU, increasing cache locality if the CPU is non-local (i.e. a cache hit would definitely have been missed).
Governor Tweaks
hispeed_load: 90 --> 80: Jump to a higher frequency if we are approaching the end of the frequency list, where a task may begin to starve or begin to stutter.
hispeed_freq: : Set the "higher freq" (referencing hispeed_load) to the maximum frequency available to take advantage of Race-To-Idle.
CAF CPU Boost Tweaks
input_boost_freq: 1.4 GHz (closest freq) as a generic, universal boost frequency to the little cluster.
input_boost_ms: 250 ms, not consuming too much power but boosting for important, interactive events such as clicking on things.
I/O
iostats: 1 --> 0: Disable I/O statistics accounting, which adds overhead.
readahead: 0: Disable readahead, which is intended for disks with long seek times (HDD), whereas mobile devices use flash storage with zero seek time.
nr_requests: 128 --> 512: Allow more I/O requests to be issued before flushing the queue, slightly increasing latencies but allowing more requests to be executed before being put to sleep.
noop / none: Use a scheduler with little CPU overhead to reduce I/O latencies, which is essential for fast flash storage (eMMC & UFS).
ZRAM
ZRAM reduces disk wear by reducing disk writes, and also increases cache locality by allowing more data to fit in RAM at once. KTweak configures ZRAM to take up at most half of the available RAM on the system, which is a good ratio of RAM to ZRAM for a mobile device.
Other Notes
You should know that KTweak applies after 60s of uptime as to prevent Android's init from overwriting any values.
Contact
You can find me on telegram at @tytydraco. Feel free to email me at [email protected].
Downloads
All releases and the entire source code for KTweak is available on GitHub:
Downloads
XDA:DevDB Information
KTweak, Tool/Utility for all devices (see above for details)
Contributors
tytydraco, tytydraco
Source Code: https://github.com/tytydraco/ktweak
Version Information
Status: Stable
Current Stable Version: v1.0.7
Stable Release Date: 2020-08-16
Created 2020-08-16
Last Updated 2020-08-16
What are the requirements to use this? Root with Magisk is a given - but Linux kernel version, Android OS version, device, etc?
MishaalRahman said:
What are the requirements to use this? Root with Magisk is a given - but Linux kernel version, Android OS version, device, etc?
Click to expand...
Click to collapse
The script adjusts only the tweaks that are compatible with your version. It contains tweaks for EAS, HMP, and supports 3.18 and above in testing. It likely supports even lower. Otherwise, it's totally universal.
KTweak now has an official Telegram channel for release information and changelogs: @ktweak
Thank you for your work and great explanation ?
This will work on lineage kernel?
Hello there. Im using ver 1.0.9. I updated and tried 1.1.0 but ended up in reboots after boot complete. I am using NX kernel which seta vfs cache pressure to 100. May that be the case?
Now back to 1.0.9 and everything seems fine. However, I had to uninstall and reinstall magisk, because when Ive flashed 1.0.9 ober 1.1.0, I was still experiwncing problems.
lapirado said:
Thank you for your work and great explanation ?
This will work on lineage kernel?
Click to expand...
Click to collapse
This should work on any kernel
myaslioglu said:
Hello there. Im using ver 1.0.9. I updated and tried 1.1.0 but ended up in reboots after boot complete. I am using NX kernel which seta vfs cache pressure to 100. May that be the case?
Now back to 1.0.9 and everything seems fine. However, I had to uninstall and reinstall magisk, because when Ive flashed 1.0.9 ober 1.1.0, I was still experiwncing problems.
Click to expand...
Click to collapse
Hi! Thanks for the report. Which device and Android version are you using? I have an idea of why this could be happening.
myaslioglu said:
Hello there. Im using ver 1.0.9. I updated and tried 1.1.0 but ended up in reboots after boot complete. I am using NX kernel which seta vfs cache pressure to 100. May that be the case?
Now back to 1.0.9 and everything seems fine. However, I had to uninstall and reinstall magisk, because when Ive flashed 1.0.9 ober 1.1.0, I was still experiwncing problems.
Click to expand...
Click to collapse
Hi myaslioglu,
I've released v1.1.1 which adds an additional 20 second sleep after Android reports that it has been initialized. This should prevent init and any post-boot init scripts from running alongside ktweak. I believe your issue stems from ZRAM resizing itself alongside bootup, where memory is most scarce, possibly causing your device to think it failed to bootup correctly.
Please let me know if v1.1.1 fixes your issue. It is live on GitHub releases and Telegram.
tytydraco said:
Hi myaslioglu,
I've released v1.1.1 which adds an additional 20 second sleep after Android reports that it has been initialized. This should prevent init and any post-boot init scripts from running alongside ktweak. I believe your issue stems from ZRAM resizing itself alongside bootup, where memory is most scarce, possibly causing your device to think it failed to bootup correctly.
Please let me know if v1.1.1 fixes your issue. It is live on GitHub releases and Telegram.
Click to expand...
Click to collapse
Hello. Sorry I forgot to report my device, it is s8 exynos just in case. But 1.1.1 fixed the issue. Works perfect! Thanks
myaslioglu said:
Hello. Sorry I forgot to report my device, it is s8 exynos just in case. But 1.1.1 fixed the issue. Works perfect! Thanks
Click to expand...
Click to collapse
1.1.2 got me reboots again. What has changed? Only the swappiness? Worked fine on 1.1.1 and did not work on 1.1.0 as aforementioned.
Can zram be the issue?
1.1.1 made my op7pro freeze with weeb kernel ??* and we have the same device draco
Doesn't work on stock kernel of redmi note 9s, freezes a few seconds after boot,forcing me to hard restart
It compatible with j5 (2015)?
To those of you getting freezes, I have identified the cause to be related to ZRAM. I will push an update today that will remove ZRAM tweaking from the script.
The reason I believe this is happening is because ktweak tries to resize the ZRAM. That requires all data that is currently in ZRAM to decompress and enter your main memory unit. If we run out of memory during this process, we will freeze.
The solution is to not adjust the zram size when using ktweak. Sorry for the inconveniences that may have been caused. I'll get straight to fixing this as soon as possible.
I've heard about your work from xda Telegram channel.
I read the info and thought to test it, but as some users reported as latest update having freeze issue. I'll test with freeze issue fixed update.?
tytydraco said:
To those of you getting freezes, I have identified the cause to be related to ZRAM. I will push an update today that will remove ZRAM tweaking from the script.
The reason I believe this is happening is because ktweak tries to resize the ZRAM. That requires all data that is currently in ZRAM to decompress and enter your main memory unit. If we run out of memory during this process, we will freeze.
The solution is to not adjust the zram size when using ktweak. Sorry for the inconveniences that may have been caused. I'll get straight to fixing this as soon as possible.
Click to expand...
Click to collapse
I ever disabled ZRAM on my OP7 PRO feels more fluid
Is working on mi 10 pro?
Vivo v9
How can I root vivo v9 1723?
I tried many methods but nothing work for me.
Please help
tyagis777 said:
How can I root vivo v9 1723?
I tried many methods but nothing work for me.
Please help
Click to expand...
Click to collapse
Really? You created an account for this post?