[resolved] Revisiting egl.cfg - Milestone XT720 Android Development

Update: Resolved to my satisfaction: http://forum.xda-developers.com/showpost.php?p=14323192&postcount=8
The egl.cfg we've been using:
Code:
1 1 android
0 1 POWERVR_SGX530_121
is functionally equivalent to removing the software renderer:
Code:
0 1 POWERVR_SGX530_121
Original post:
......................................................................................
So, we've been running /system/lib/egl/egl.cfg set as:
Code:
1 1 android
0 1 POWERVR_SGX530_121
This tweaked egl.cfg essentially disables hardware rendering and substitutes software rendering. The default setting is
Code:
0 0 android
0 1 POWERVR_SGX530_121
We do this because this was reported to be much, much faster by just about everyone and I will admit to also experiencing this improvement. However, I've recently run 2.1 and honestly it really puts our 2.2 to shame. Additionally it's never made any sense that the software renderer would outperform hardware acceleration. It makes more sense that there's something wrong with our graphics libraries and that's why software rendering wins. Or we were mistaken in believing things were faster.
In my work-in-progress ROM, I've updated graphics libraries (for other reasons) and then I tried disabling the tweak and performance seems much improved and much closer to what I see in 2.1 (FYI, for some reason I had to wipe dalvik-cache after making the change or boot got stuck, but that could be unrelated).
So, the question is: are the updated graphics libraries the reason it works or was changing egl.cfg a mistake?
Can some adventurous souls try going back to the defaults and report whether they really think the software render really is faster? Please post which ROM you are testing on. If switching egl.cfg back to defaults makes things worse, we can then try whether updating the graphics libraries to the versions I'm testing helps.

RusMod,usyng egl.cfg as soft renderer.
In next version i will try to move egl.cfg to default from 2.1 and will ask people - how it feeling.
For results will post here.
btw, afaik defy uses same video accel?
p.s. http://xt720.fjfalcon.ru/Mods/rusmodv1.14.zip
RusMod users haven't noticed much problem(all usyng fastboot kernel)
But in quadrant when going test with2 planets - scores shows like in 2.1.

I wondered how long it would take for this to come back up. I think that the difference between hardware and software based encoding on our phone is more of a question of "What else is being affected?"
Obviously, there isn't too dramatic of a difference in the overall performance or people would have been screaming about it way back when we made this change. I am more concerned about the possibility of other things, such as battery life or video performance being affected by these settings. Is it possible that other things are being hit? Who knows. I always knew that this change was merely cosmetic, a way to boost quadrant scores.
Mioze7Ae, I switched mine back and have been tinkering with it since. I have not noticed a significant difference. It actually seemed a bit choppier. If you have a test build with new libs, I would be willing to try it out for a while and see if I can break it.
I forgot to add:
I'm running galaxyXTv4. I didn't like the way epicsteelblue looked.

reverendkjr said:
Mioze7Ae, I switched mine back and have been tinkering with it since. I have not noticed a significant difference. It actually seemed a bit choppier. If you have a test build with new libs, I would be willing to try it out for a while and see if I can break it.
Click to expand...
Click to collapse
I also notice it is slightly choppier sometimes but on the other hand the software rendering to me feels sluggish and the hardware rendering feels more responsive. For example scrolling: open something with a long list and throw the list up and down. The software rendering seems to slow this down and lag a bit, but the hardware rendered flows faster and seems to stay underneath my finger. The 3D program list in ADW Launcher is noticeably faster and smoother.
Anyway, as you wish here's the work-in-progress.
http://www.multiupload.com/HYUZG4E3BZ
It's a larger rework of Dexter's 1.3. It's based on an analysis I'm doing where I compare which files change and which files remain identical between Motorola's XT720 2.1, Motoroi 2.1 and 2.2, and Milestone 2.1 and 2.2 releases in order to make predictions about which versions of these files should be on Milestone XT720 2.2. It's a full ROM that applies as an update instead of a nandroid image. I switched the 2nd-init hijack to the simpler bin/sh_hijack.sh+etc/rootfs one that is used on Milestone instead of the mot_boot_mode+lw+lw2+ramdisk.tar method. Not included are the init.d scripts--so the governors, overclocking, ext partition, swap, moving dalvik-cache to /cache are "do it yourself" for now. I'm porting the CM6 scripts to implement that, but they're not ready.

How is the battery life doing Mioze7Ae? And thanks for fixing, will try this weekend when im free. =)

khankuan said:
How is the battery life doing Mioze7Ae? And thanks for fixing, will try this weekend when im free. =)
Click to expand...
Click to collapse
Honestly, I haven't had that ROM running long enough to have an opinion about its battery life. It's quickly evolving and I keep flashing back to an earlier version that's about half-way between bugfix-3 and this version for my everyday use. There's still a lot I need to do with this ROM before I'm ready to "move in" and dogfood it. Anyway it's my feeling that disabling the egl.cfg tweek improves performance on this ROM.
In the mean time, if changing the egl.cfg back actually makes things worse on current ROMs, we can see about testing just these specific libraries in those ROMs. There's just so many of them. I'll see if I can make a library patch for galaxyXTv4 for reverendkjr to test.
Which one do you run?

Hi been useing the rus.mod and it has without error something could not say before very good build.
Sent from my XT720 using XDA Premium App

I think I've figured this out
Ok, here's the scoop: contrary to what I thought, xav's hacked egl.cfg actually disables the software renderer all together. In testing with Quadrant Advance I get identical (best) performance from either of these two egl.cfg's:
Code:
1 1 android
0 1 POWERVR_SGX530_121
and (my recommendation):
Code:
0 1 POWERVR_SGX530_121
More info
The documentation header for egl.cfg says:
Code:
#
# One line per configuration, of the form:
#
# D I TAG
#
# D: display (0: default)
# I: implementation (0: software, 1: hardware)
# TAG: a unique tag
#
# The library name loaded by EGL is constructed as (in that order):
#
# /system/lib/egl/libGLES_$TAG.so
# /system/lib/egl/lib{EGL|GLESv1_CM|GLESv2}_$TAG.so
#
Now, what had me confused in the past is I couldn't make heads or tails of what "D: display (0: default)" means. Somehow when re-reading that today had the obvious revelation that it's referring to "display number" and 0 is the display number of the primary screen (the default screen) the same way that X11 in Unix refers to displays. So:
Code:
1 1 android
means "use the android software renderer as a hardware renderer on the second display" (we don't have a second display and I don't think it can mean the TV or HDMI out, either because Motorola never defined any renderers for a second device). In fact, you can just delete or comment out the entire 0 0 android line and get the same results.
From testing, a tale-tale sign of the software renderer being used is that messed up moon. Hardware rendering doesn't have the messed up moon.
Motorola's default enables both:
Code:
0 0 android
0 1 POWERVR_SGX530_121
It turns out that even making the software renderer available is bad for 3D performance.
So why does having the software renderer around cause trouble? Speculation: I thought OpenGL is supposed to figure out the best way to render things, so why is it getting this wrong? My guess is the software renderer must provide APIs that are preferred compared to what the hardware interface provides so applications or the GL library negotiates to use the software API rather than a less desirable hardware-accelerated library or perhaps they can't tell the difference. Or perhaps Quadrant is a piece of junk. That's my guess anyway.
Here's a bunch of testing I did (default kernel frequencies/voltages):
Code:
egl.cfg: 0 0 android
0 1 POWERVR_SGX530_121
# Has the messed up moon
Tot CPU Mem I/O 2D 3D
------+----+---+---+---+----
1: 573 954 813 630 194 273
2: 590 989 841 648 195 276
3: 627 1029 981 654 195 277
4: 597 1008 842 663 195 275
5: 601 1025 847 662 194 277
egl.cfg: 1 1 android
0 1 POWERVR_SGX530_121
# No messed up moon
Tot CPU Mem I/O 2D 3D
------+----+---+---+---+----
1: 612 925 820 601 194 521
2: 590 935 842 459 195 519
3: 654 949 977 626 196 524
4: 642 1009 822 656 195 527
5: 643 998 854 645 194 524
egl.cfg: 0 1 android
0 0 POWERVR_SGX530_121
# Noticably awful--feels like a Macintosh 512k
# Quadrant warns about using software rendering
# Has the messed up moon
Tot CPU Mem I/O 2D 3D
------+----+---+---+---+----
1: 465 803 730 562 79 151
2: 477 735 784 635 80 152
3: 487 773 791 638 80 153
4: 472 750 757 622 80 153
5: 468 785 773 552 80 152
egl.cfg: 0 0 POWERVR_SGX530_121
# No messed up moon
Tot CPU Mem I/O 2D 3D
------+----+---+---+---+----
1: 613 860 860 626 193 524
2: 635 963 836 658 194 522
3: 641 1014 807 661 196 526
4: 654 989 912 653 194 522
5: 674 1026 977 648 194 525
egl.cfg: 0 1 POWERVR_SGX530_121
# No messed up moon
Tot CPU Mem I/O 2D 3D
------+----+---+---+---+----
1: 609 919 960 452 193 519
2: 601 946 716 620 195 528
3: 664 999 960 647 195 521
4: 627 1014 751 651 194 527
5: 642 1008 820 661 192 529
egl.cfg: 0 1 POWERVR_SGX530_121
0 0 android
# Has the messed up moon
Tot CPU Mem I/O 2D 3D
------+----+---+---+---+----
1: 575 917 872 626 189 269
2: 595 967 890 651 193 273
3: 597 978 901 634 194 277
4: 577 1006 845 571 192 272
5: 591 982 834 665 195 278

I flashed dexter's 1.3, then I installed your update. I'll run it for a while and get back to you on my results. A couple of items though. First, the camera apk doesnt work. I tried deleting and reinstalling, but it will not. Also, Milestone Overclock refuses to load. I am wondering if you have experienced anything along these lines yet.

reverendkjr said:
I flashed dexter's 1.3, then I installed your update. I'll run it for a while and get back to you on my results. A couple of items though. First, the camera apk doesnt work. I tried deleting and reinstalling, but it will not. Also, Milestone Overclock refuses to load. I am wondering if you have experienced anything along these lines yet.
Click to expand...
Click to collapse
Yeah, none of that works yet. It's probably not worth playing with extensively yet. I've only just started getting into the libraries. When it's closer to usable I'll post another.

I changed my egl to
0 1 POWERVR_SGX530_121
completely removed the android line. I was surprised to see that was even possible. I also managed to get the Milestone Overclock v. 1.4.1 to run on this and OC to 1ghz. I was thinking about trying
1 1 android
0 0 POWERVR_SGX530_121
since it doesn't look like that was tried yet. I'll do that later. I have been running the all day and do believe there is a level of "snappiness" that the other versions do not have.

reverendkjr said:
I changed my egl to
0 1 POWERVR_SGX530_121
completely removed the android line. I was surprised to see that was even possible. I also managed to get the Milestone Overclock v. 1.4.1 to run on this and OC to 1ghz. I was thinking about trying
1 1 android
0 0 POWERVR_SGX530_121
since it doesn't look like that was tried yet. I'll do that later. I have been running the all day and do believe there is a level of "snappiness" that the other versions do not have.
Click to expand...
Click to collapse
Not much of a difference. I went back to
0 1 POWERVR_SGX530_121.

Related

Memory/CPU Usage with adb top

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.

Making Nonsense of Sense UI

I have been testing out the Sense UI's released to the G1 recently, and have stuck with using King's Slide at this point and wanted to point out what I have done to see if anyone is interested, or if this is possible to modify in the update.zip before flashing.
Initially on loading, everything worked fine, however the whole system got bogged down as Rosie started doing its thing. I thought I would try running ADW instead and experiment with what I could remove from /system/app to speed up the whole experience. By doing this I was mostly concerned with maintaining the HTC styled experience by keeping all of their apk's except those associated with Rosie.
At this point, I have renamed the following apk's to apr's to see what still works:
243 /system/app/Bluetooth.apr
72 /system/app/FlashLitePlugin.apr
150 /system/app/FlashPlayer.apr
1208 /system/app/Hoops.apr
1113 /system/app/HtcClockWidget.apr
539 /system/app/HtcPhotoWidget.apr
1580 /system/app/Jbed.apr
903 /system/app/LightShow.apr
1423 /system/app/NatureTheme.apr
1248 /system/app/Palazzo.apr
251 /system/app/ProfileManager.apr
1135 /system/app/Surf.apr
81 /system/app/WidgetDownloadManager.apr
993 /system/app/Wildflower.apr
278 /system/app/com.htc.FriendStreamWidget.apr
251 /system/app/com.htc.TwitterWidget.apr
406 /system/app/com.htc.WeatherWidget.apr
326 /system/app/mytouchmusic-signed.apr
556 /system/app/vvm-signed.apr
1611 /system/app/HTCSetupWizard.apr
4459 /system/app/HTC_IME.apr
111 /system/app/HtcDm.apr
181 /system/app/HtcStreamPlayer.apr
1054 /system/app/Rosie.apr
This comes out with about 20 MB of free space with all of the HTC apps like calendar, contacts, weather, and expecially the great dialer still working. The only thing you miss out on is the Sense experience, and flash, which didn't work in this build anyway.
I realize there are a ton of dependancies that still exist in /system/lib which might also be deleted, and will concentrate on that next. What I am hoping for from this experiment is a HTC build that doesn't take a Herculean effort to fit on a G1.
I also would like some advice as to how these modifications might actually be done in the update.zip (will deleting the .apk in the zip be enough) to prevent me from having to modify the rom in ADP the entire time.
As this is less of a developement post and more of a tips/tricks post I'm going to move it to the 'general' section.

Speed up by switching to 16-bit video

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.

[RESULTS] Overclocking with UrukDroid

$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?

Power/performance kernel tuning and tweaks

As suggested in LineageOS thread the discussion on kernel tweaks forks here.
Let's continue!
The recent post:
Zola III said:
Well you can use different profiles in Kernel Auditor but forgot anything turbo especially in GPU intensive games where you actually need to save on CPU power consumption but CPU frequency must stay high enough to allow full speed RAM operations (as that's the way it goes with Snapdragon boards) so that you have better headroom for GPU & less throttling by thermal engine. Think 500MHz is a best achievable sustained frequency & even that is achieved only when CPU power usage is tuned on stock MiUI & otherwise I can get GPU to get throttled down to 450MHz in less than a 30 min. A one GHz for a CPU is really golden middle regarding performance/power consumption no matter what lithographic processes is used to make it, it's simply tied to silicone as essential material.
Click to expand...
Click to collapse
HELIUM, LOCKED bootloader, [ROM][UNOFFICIAL][7.1.1][HYDROGEN/HELIUM]LineageOS 14.1 r.03-27-2017 by*nijel8
This is my Init.d script I presently use, I've cumulated here your previous draft proposals and hints, please forgive me for its deficiencies and help to improve it:
Code:
#!/system/bin/sh
#
sleep 3;
################################# helper functions to allow Android init like script
function write() {
echo -n $2 > $1
}
function copy() {
cat $1 > $2
}
function get-set-forall() {
for f in $1 ; do
cat $f
write $f $2
done
}
################################
# Enable governor for LITTLE CPUs (perrf cluster):
write /sys/devices/system/cpu/cpu0/online 1
write /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor "interactive"
write /sys/devices/system/cpu/cpu0/cpufreq/interactive/above_hispeed_delay 40000
write /sys/devices/system/cpu/cpu0/cpufreq/interactive/go_hispeed_load 96
write /sys/devices/system/cpu/cpu0/cpufreq/interactive/timer_rate 20000
write /sys/devices/system/cpu/cpu0/cpufreq/interactive/hispeed_freq 1017600
write /sys/devices/system/cpu/cpu0/cpufreq/interactive/io_is_busy 1
write /sys/devices/system/cpu/cpu0/cpufreq/interactive/target_loads "80 400000:87 1017600:95 1190400:99"
#1305600
write /sys/devices/system/cpu/cpu0/cpufreq/interactive/min_sample_time 20000
write /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq 400000
# Enable governor for Big CUSs (power cluster):
write /sys/devices/system/cpu/cpu4/online 1
write /sys/devices/system/cpu/cpu4/cpufreq/scaling_governor "interactive"
write /sys/devices/system/cpu/cpu4/cpufreq/interactive/above_hispeed_delay 40000
###interactive/above_hispeed_delay 40000
write /sys/devices/system/cpu/cpu4/cpufreq/interactive/go_hispeed_load 96
write /sys/devices/system/cpu/cpu4/cpufreq/interactive/timer_rate 20000
write /sys/devices/system/cpu/cpu4/cpufreq/interactive/hispeed_freq 1017600
write /sys/devices/system/cpu/cpu4/cpufreq/interactive/io_is_busy 1
write /sys/devices/system/cpu/cpu4/cpufreq/interactive/target_loads "87 400000:90 1017600:95 1382400:99"
write /sys/devices/system/cpu/cpu4/cpufreq/interactive/min_sample_time 20000
write /sys/devices/system/cpu/cpu4/cpufreq/scaling_min_freq 400000
write /sys/devices/system/cpu/cpu4/cpufreq/interactive/max_freq_hysteresis 60000
# Configure core_ctl
write /sys/devices/system/cpu/cpu0/core_ctl/not_preferred "1 0 0 0"
write /sys/devices/system/cpu/cpu0/core_ctl/busy_up_thres 90
write /sys/devices/system/cpu/cpu0/core_ctl/busy_down_thres 80
write /sys/devices/system/cpu/cpu0/core_ctl/min_cpus 1
write /sys/devices/system/cpu/cpu0/core_ctl/max_cpus 4
write /sys/devices/system/cpu/cpu4/core_ctl/not_preferred "1 0 0 0"
write /sys/devices/system/cpu/cpu4/core_ctl/min_cpus 1
write /sys/devices/system/cpu/cpu4/core_ctl/max_cpus 4
write /sys/devices/system/cpu/cpu4/core_ctl/busy_up_thres 90
write /sys/devices/system/cpu/cpu4/core_ctl/busy_down_thres 80
write /sys/devices/system/cpu/cpu4/core_ctl/offline_delay_ms 200
write /sys/devices/system/cpu/cpu4/core_ctl/task_thres 4
write /sys/devices/system/cpu/cpu4/core_ctl/is_big_cluster 1
# set cpu_boost parameters
write /sys/module/cpu_boost/parameters/input_boost_freq "0:1190400 1:0 2:0 3:0 4:0 5:0 6:0 7:0"
write /sys/module/cpu_boost/parameters/input_boost_ms 200
write /proc/sys/kernel/sched_upmigrate_min_nice 15
# set (super) packing parameters
write /sys/devices/system/cpu/cpu0/sched_mostly_idle_freq 400000
write /sys/devices/system/cpu/cpu4/sched_mostly_idle_freq 400000
################################
# IO
echo 'deadline' > /sys/block/mmcblk0/queue/scheduler
# GPU
echo '133333333' > /sys/class/kgsl/kgsl-3d0/devfreq/min_freq
echo '20' > /sys/module/adreno_idler/parameters/adreno_idler_downdifferential
echo 'Y' > /sys/module/adreno_idler/parameters/adreno_idler_active
echo '550000000' > /sys/class/kgsl/kgsl-3d0/max_gpuclk
echo 'simple_ondemand' > /sys/class/kgsl/kgsl-3d0/devfreq/governor
echo '20' > /sys/module/adreno_idler/parameters/adreno_idler_idlewait
################################
Please forgive me its imperfection, treat it as a draft. Please review it. Thank you very much!
HELIUM, LOCKED bootloader, [ROM][UNOFFICIAL][7.1.1][HYDROGEN/HELIUM]LineageOS 14.1 r.03-27-2017 by*nijel8
Their isn't much to continue. Leaking is sustainable up to 1.4GHz (up to 1.6GHz on newer FinFET lithography). So the base & upper range that you don't want to go over for anything more than just burst start is pretty much same for all boards. I already described & wrote what should be done particularly for msm8956 & msm8976.
Script as it is so far; 2+2 core's
S652 octa core
Code:
#!/system/bin/sh
#
################################################################################
# helper functions to allow Android init like script
function write() {
echo -n $2 > $1
}
function copy() {
cat $1 > $2
}
function get-set-forall() {
for f in $1 ; do
cat $f
write $f $2
done
}
################################################################################
# Enable governor for LITTLE CPUs (perrf cluster)
write /sys/devices/system/cpu/cpu0/online 1
write /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor "interactive"
write /sys/devices/system/cpu/cpu0/cpufreq/interactive/above_hispeed_delay 40000
write /sys/devices/system/cpu/cpu0/cpufreq/interactive/go_hispeed_load 90
write /sys/devices/system/cpu/cpu0/cpufreq/interactive/timer_rate 20000
write /sys/devices/system/cpu/cpu0/cpufreq/interactive/hispeed_freq 1017600
write /sys/devices/system/cpu/cpu0/cpufreq/interactive/io_is_busy 1
write /sys/devices/system/cpu/cpu0/cpufreq/interactive/target_loads "87 400000:93 1017600:95 1190400:95"
write /sys/devices/system/cpu/cpu0/cpufreq/interactive/min_sample_time 20000
write /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq 400000
# Enable governor for Big CUSs (power cluster)
write /sys/devices/system/cpu/cpu4/online 1
write /sys/devices/system/cpu/cpu4/cpufreq/scaling_governor "interactive"
write /sys/devices/system/cpu/cpu4/cpufreq/interactive/above_hispeed_delay 40000
write /sys/devices/system/cpu/cpu4/cpufreq/interactive/go_hispeed_load 93
write /sys/devices/system/cpu/cpu4/cpufreq/interactive/timer_rate 20000
write /sys/devices/system/cpu/cpu4/cpufreq/interactive/hispeed_freq 998400
write /sys/devices/system/cpu/cpu4/cpufreq/interactive/io_is_busy 1
write /sys/devices/system/cpu/cpu4/cpufreq/interactive/target_loads "87 400000:93 998400:95 1190400:95 1382400:97"
write /sys/devices/system/cpu/cpu4/cpufreq/interactive/min_sample_time 20000
write /sys/devices/system/cpu/cpu4/cpufreq/scaling_min_freq 400000
write /sys/devices/system/cpu/cpu4/cpufreq/interactive/max_freq_hysteresis 60000
# Configure core_ctl
write /sys/devices/system/cpu/cpu0/core_ctl/not_preferred "1 0 1 0"
write /sys/devices/system/cpu/cpu0/core_ctl/busy_up_thres 78
write /sys/devices/system/cpu/cpu0/core_ctl/busy_down_thres 55
write /sys/devices/system/cpu/cpu0/core_ctl/min_cpus 2
write /sys/devices/system/cpu/cpu0/core_ctl/max_cpus 4
write /sys/devices/system/cpu/cpu4/core_ctl/not_preferred "1 0 1 0"
write /sys/devices/system/cpu/cpu4/core_ctl/min_cpus 2
write /sys/devices/system/cpu/cpu4/core_ctl/max_cpus 4
write /sys/devices/system/cpu/cpu4/core_ctl/busy_up_thres 78
write /sys/devices/system/cpu/cpu4/core_ctl/busy_down_thres 55
write /sys/devices/system/cpu/cpu4/core_ctl/offline_delay_ms 200
write /sys/devices/system/cpu/cpu4/core_ctl/task_thres 4
write /sys/devices/system/cpu/cpu4/core_ctl/is_big_cluster 1
# set cpu_boost parameters
write /sys/module/cpu_boost/parameters/input_boost_freq "0:1017600 1:0 2:0 3:0 4:0 5:0 6:0 7:0"
write /sys/module/cpu_boost/parameters/input_boost_ms 200
write /proc/sys/kernel/sched_upmigrate_min_nice 15
write /proc/sys/kernel/sched_upmigrate 87
# set (super) packing parameters
write /sys/devices/system/cpu/cpu0/sched_mostly_idle_freq 400000
write /sys/devices/system/cpu/cpu4/sched_mostly_idle_freq 400000
S650 hexa core
Code:
#!/system/bin/sh
#
################################################################################
# helper functions to allow Android init like script
function write() {
echo -n $2 > $1
}
function copy() {
cat $1 > $2
}
function get-set-forall() {
for f in $1 ; do
cat $f
write $f $2
done
}
################################################################################
# Enable governor for LITTLE CPUs (perrf cluster)
write /sys/devices/system/cpu/cpu0/online 1
write /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor "interactive"
write /sys/devices/system/cpu/cpu0/cpufreq/interactive/above_hispeed_delay 40000
write /sys/devices/system/cpu/cpu0/cpufreq/interactive/go_hispeed_load 90
write /sys/devices/system/cpu/cpu0/cpufreq/interactive/timer_rate 20000
write /sys/devices/system/cpu/cpu0/cpufreq/interactive/hispeed_freq 1017600
write /sys/devices/system/cpu/cpu0/cpufreq/interactive/io_is_busy 1
write /sys/devices/system/cpu/cpu0/cpufreq/interactive/target_loads "87 400000:93 1017600:95 1190400:95"
write /sys/devices/system/cpu/cpu0/cpufreq/interactive/min_sample_time 20000
write /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq 400000
# Enable governor for Big CUSs (power cluster)
write /sys/devices/system/cpu/cpu4/online 1
write /sys/devices/system/cpu/cpu4/cpufreq/scaling_governor "interactive"
write /sys/devices/system/cpu/cpu4/cpufreq/interactive/above_hispeed_delay 40000
write /sys/devices/system/cpu/cpu4/cpufreq/interactive/go_hispeed_load 93
write /sys/devices/system/cpu/cpu4/cpufreq/interactive/timer_rate 20000
write /sys/devices/system/cpu/cpu4/cpufreq/interactive/hispeed_freq 998400
write /sys/devices/system/cpu/cpu4/cpufreq/interactive/io_is_busy 1
write /sys/devices/system/cpu/cpu4/cpufreq/interactive/target_loads "87 400000:93 998400:95 1190400:95 1382400:97"
write /sys/devices/system/cpu/cpu4/cpufreq/interactive/min_sample_time 20000
write /sys/devices/system/cpu/cpu4/cpufreq/scaling_min_freq 400000
write /sys/devices/system/cpu/cpu4/cpufreq/interactive/max_freq_hysteresis 60000
# Configure core_ctl
write /sys/devices/system/cpu/cpu0/core_ctl/not_preferred "1 0 1 0"
write /sys/devices/system/cpu/cpu0/core_ctl/busy_up_thres 78
write /sys/devices/system/cpu/cpu0/core_ctl/busy_down_thres 55
write /sys/devices/system/cpu/cpu0/core_ctl/min_cpus 2
write /sys/devices/system/cpu/cpu0/core_ctl/max_cpus 4
write /sys/devices/system/cpu/cpu4/core_ctl/not_preferred "1 1"
write /sys/devices/system/cpu/cpu4/core_ctl/min_cpus 2
write /sys/devices/system/cpu/cpu4/core_ctl/max_cpus 4
write /sys/devices/system/cpu/cpu4/core_ctl/busy_up_thres 78
write /sys/devices/system/cpu/cpu4/core_ctl/busy_down_thres 55
write /sys/devices/system/cpu/cpu4/core_ctl/offline_delay_ms 200
write /sys/devices/system/cpu/cpu4/core_ctl/task_thres 4
write /sys/devices/system/cpu/cpu4/core_ctl/is_big_cluster 1
# set cpu_boost parameters
write /sys/module/cpu_boost/parameters/input_boost_freq "0:1017600 1:0 2:0 3:0 4:0 5:0 6:0 7:0"
write /sys/module/cpu_boost/parameters/input_boost_ms 200
write /proc/sys/kernel/sched_upmigrate_min_nice 15
write /proc/sys/kernel/sched_upmigrate 87
# set (super) packing parameters
write /sys/devices/system/cpu/cpu0/sched_mostly_idle_freq 400000
write /sys/devices/system/cpu/cpu4/sched_mostly_idle_freq 400000
You've written the frequency of one GHz is the most optimal because of silicon's physical properties, so this is very universal phenomenon (like e.g. resonance frequency) thus it applies to every silicon chip, is this right?
So I had some free time so I'm bringing back our TWRP flashable tweaks compatible only with ROM's that are based on nijel8 trees. You just have to flash it through TWRP. I also included addon.d script so tweaks will be kept after dirty flashing a ROM.
Which script you should pick?
It all depends on how you use the device. For some Zolla's will work better, for some mine will work better. Test it yourself(with and without core_ctl) and tell us how it goes.
Remember to pick zip for your device! Hydrogen is for Mi Max(2/16GB or 3/32GB) and Helium is for Mi Max Prime(3/64GB or 4/128GB). Don't mess it up or you might end into a bootloop.
Thanks to @Zola III for his tweaks.
@ioy
I don't really think you understand heuristics still.
1401600:99 & 1804800:99 are top frequencies per both clusters & it's a bit funny to try to manage their up scale load as their is no frequency behind it. You need a brick at big cluster at around 1.4GHz so find as I wrote earlier.
above_hispeed_delay "29000 1382400:39000" should be set to 40000 as the main scheduler tick rate is set to 20000 so every two ticks to decide to go over a GHz is perfectly enough. In many cases default scheduler tick rate is set to 40000 for maximum responsiveness that our eay sight can register I put it ti the 20000 rt clock ticks which is equivalent to a time needed for a blink of an eye. Anything in between isn't needed.
# note: Zola III proposed this to be applied to core 5 (cpu5)
Nope! It's understud it will be applied across the cluster & for msm8956 their is no need to apply anything more as their is only one more big core (cpu5) with shared L2 memory with cpu4. However on msm8976 (S652) it needs to be applied to cpu6 so that it is instructed specifically to use that core & keep it idle instead cpu5 as that way it has second L2 cache In use both cores keep exclusive not shared memory access to the L2 cache leading to bigger instruction output. & only with set min_cpus 2 for big cluster & not_preferred "1 0 1 0" instructing that it would be two core's permanently idling and that it should be a first one and third one in the cluster.
Same thing goes for a small cluster but this time around it's universal across both boards.
Edit at the end me by only putting min_cpus 2 & not_preferred "1 0 1 0" is all needed to be done without specific applying anything to cpu2 & cpu6 as core ctr is the one that controls which cores should be online and setup is applied for whole cluster anyway from a first core (cpu0, cpu4).
One more thing don't modify deadline;
echo '1473' > /sys/class/timed_output/vibrator/vtg_level
It's ridiculous & only hurts true output.
Find the script as I wrote on other form & try it.
@Zola III
Could you write here some setting for little cluster core_ctl? I want try it with setting of 2 little + 1 big and don't know with what's values should start on that busy up and busy down.
Anyone have the voltage tables for Hydrogen and Helium? I heard of the Kenzo sources for the SD650 having these tables, I couldn't find them though.
Don't laugh, I'm trying that initial Ghostpepper governor setup with forced steps to efficient frequencies and skipping less efficient ones. The latest version seems to have a more gradual stepping through all frequencies instead of the quick and hard jumps of the initial version.
Jerry08 said:
Did you test your settings? Im using different rom than nijel8, so no not_prefered setting. I test it myself and with this I have no lag. 1382mhz is not used by big cluster for me so 1190mhz is right. And that lovely smoothness and 4900 score on multicolore on Geekbench makes me stay there. Oh and the 99 on 1401600 is leftover from firsts setups. Dunno why I didn't remove it since I removed from 1804mhz.
Edit: Damn didn't see that @ioy, thought it was about my setup.
Another thing is that there is no difference in battery between 400mhz and 691mhz on little cluster so I recommend setting 691mhz.
Click to expand...
Click to collapse
Currently I don't test anything as my max is still locked but in the past I did very much work about it & some of it you can find hire:
https://forum.xda-developers.com/galaxy-s3-neo/orig-development/kernel-n1kernel-t3208957
Well 1.4GHz top is also applied & to your settings, 1.2GHz if you want to save a little more going above it is absurd.
Well even 400 & 691MHz are on the same VVD 691 will still use considerable more power but it will also have less reason to jump up on smaller loads so it's easier to contain. Problem appears more if min is set to 400MHz but not good contained there so that it jumps more frequently to the 691 & in that case it actually do spend considerable more power even than its set to min 691. & I do know that for a fact by experimenting. How ever I find 400 MHz min as more reasonable to save some juice & contain it not to bump over without real need after all we have hi speed load tunable there to make a fast bridge jump over in case of any real significant workload. It's not how 691MHz isn't reasonable if you want to go for more performance orientated setup (it will still use approximately 2x power than set to 400) but it also brings the other part of the problem & that would be how 1GHz & 691MHz are relatively close together so hi speed load should also be adjusted in this case more towards 1.2GHz. I don't intend to push performance metrics so I will remain at the balanced approach (400 min, 1GHz hispeed_freq) as an optimal.
Edit:
By the way 85 for an calculated load for a scaling up frequency or hi speed load is way to aggressive with IO is busy signaling enabled, without it its ok so bump it up a bit.
Zola III said:
Currently I don't test anything as my max is still locked but in the past I did very much work about it & some of it you can find hire:
https://forum.xda-developers.com/galaxy-s3-neo/orig-development/kernel-n1kernel-t3208957
Well 1.4GHz top is also applied & to your settings, 1.2GHz if you want to save a little more going above it is absurd.
Well even 400 & 691MHz are on the same VVD 691 will still use considerable more power but it will also have less reason to jump up on smaller loads so it's easier to contain. Problem appears more if min is set to 400MHz but not good contained there so that it jumps more frequently to the 691 & in that case it actually do spend considerable more power even than its set to min 691. & I do know that for a fact by experimenting. How ever I find 400 MHz min as more reasonable to save some juice & contain it not to bump over without real need after all we have hi speed load tunable there to make a fast bridge jump over in case of any real significant workload. It's not how 691MHz isn't reasonable if you want to go for more performance orientated setup (it will still use approximately 2x power than set to 400) but it also brings the other part of the problem & that would be how 1GHz & 691MHz are relatively close together so hi speed load should also be adjusted in this case more towards 1.2GHz. I don't intend to push performance metrics so I will remain at the balanced approach (400 min, 1GHz hispeed_freq) as an optimal.
Click to expand...
Click to collapse
Well setting of 400mhz as min was making too much jumping to 691mhz just like u said so I keep 691 so it sits there for long time. I will try higher setting of high frequency next battery cycle.
Jerry08 said:
@Zola III
Could you write here some setting for little cluster core_ctl? I want try it with setting of 2 little + 1 big and don't know with what's values should start on that busy up and busy down.
Click to expand...
Click to collapse
OK I will. Tell me which SoC do you have?
Zola III said:
OK I will. Tell me which SoC do you have?
Click to expand...
Click to collapse
652 helium.
Jerry08 said:
Well setting of 400mhz as min was making too much jumping to 691mhz just like u said so I keep 691 so it sits there for long time. I will try higher setting of high frequency next battery cycle.
Click to expand...
Click to collapse
No wonder that it jumps with calculated scaling up frequently set to 85 with IO is busy signaling enabled...
---------- Post added at 08:20 PM ---------- Previous post was at 08:03 PM ----------
Jerry08 said:
652 helium.
Click to expand...
Click to collapse
OK try like this for two little & one big;
# Configure core_ctl
write /sys/devices/system/cpu/cpu0/core_ctl/not_preferred "1 0 1 0"
write /sys/devices/system/cpu/cpu0/core_ctl/busy_up_thres 78
write /sys/devices/system/cpu/cpu0/core_ctl/busy_down_thres 55
write /sys/devices/system/cpu/cpu0/core_ctl/min_cpus 2
write /sys/devices/system/cpu/cpu0/core_ctl/max_cpus 4
write /sys/devices/system/cpu/cpu4/core_ctl/not_preferred "1 0 0 0"
write /sys/devices/system/cpu/cpu4/core_ctl/min_cpus 1
write /sys/devices/system/cpu/cpu4/core_ctl/max_cpus 4
write /sys/devices/system/cpu/cpu4/core_ctl/busy_up_thres 78
write /sys/devices/system/cpu/cpu4/core_ctl/busy_down_thres 55
write /sys/devices/system/cpu/cpu4/core_ctl/offline_delay_ms 200
write /sys/devices/system/cpu/cpu4/core_ctl/task_thres 4
write /sys/devices/system/cpu/cpu4/core_ctl/is_big_cluster 1
This would be for a two + two combo & only on Helium (S652):
# Configure core_ctl
write /sys/devices/system/cpu/cpu0/core_ctl/not_preferred "1 0 1 0"
write /sys/devices/system/cpu/cpu0/core_ctl/busy_up_thres 78
write /sys/devices/system/cpu/cpu0/core_ctl/busy_down_thres 55
write /sys/devices/system/cpu/cpu0/core_ctl/min_cpus 2
write /sys/devices/system/cpu/cpu0/core_ctl/max_cpus 4
write /sys/devices/system/cpu/cpu4/core_ctl/not_preferred "1 0 1 0"
write /sys/devices/system/cpu/cpu4/core_ctl/min_cpus 2
write /sys/devices/system/cpu/cpu4/core_ctl/max_cpus 4
write /sys/devices/system/cpu/cpu4/core_ctl/busy_up_thres 78
write /sys/devices/system/cpu/cpu4/core_ctl/busy_down_thres 55
write /sys/devices/system/cpu/cpu4/core_ctl/offline_delay_ms 200
write /sys/devices/system/cpu/cpu4/core_ctl/task_thres 4
write /sys/devices/system/cpu/cpu4/core_ctl/is_big_cluster 1
Two + two should be most suitable deal performance wise especially regarding inter core (& cross cluster regarding it) communication very important for thread migration between clusters.
Best regards.
Zola III said:
No wonder that it jumps with calculated scaling up frequently set to 85 with IO is busy signaling enabled...
---------- Post added at 08:20 PM ---------- Previous post was at 08:03 PM ----------
OK try like this for two little & one big;
# Configure core_ctl
write /sys/devices/system/cpu/cpu0/core_ctl/not_preferred "1 0 1 0"
write /sys/devices/system/cpu/cpu0/core_ctl/busy_up_thres 78
write /sys/devices/system/cpu/cpu0/core_ctl/busy_down_thres 55
write /sys/devices/system/cpu/cpu0/core_ctl/min_cpus 2
write /sys/devices/system/cpu/cpu0/core_ctl/max_cpus 4
write /sys/devices/system/cpu/cpu4/core_ctl/not_preferred "1 0 0 0"
write /sys/devices/system/cpu/cpu4/core_ctl/min_cpus 1
write /sys/devices/system/cpu/cpu4/core_ctl/max_cpus 4
write /sys/devices/system/cpu/cpu4/core_ctl/busy_up_thres 78
write /sys/devices/system/cpu/cpu4/core_ctl/busy_down_thres 55
write /sys/devices/system/cpu/cpu4/core_ctl/offline_delay_ms 200
write /sys/devices/system/cpu/cpu4/core_ctl/task_thres 4
write /sys/devices/system/cpu/cpu4/core_ctl/is_big_cluster 1
This would be for a two + two combo & only on Helium (S652):
# Configure core_ctl
write /sys/devices/system/cpu/cpu0/core_ctl/not_preferred "1 0 1 0"
write /sys/devices/system/cpu/cpu0/core_ctl/busy_up_thres 78
write /sys/devices/system/cpu/cpu0/core_ctl/busy_down_thres 55
write /sys/devices/system/cpu/cpu0/core_ctl/min_cpus 2
write /sys/devices/system/cpu/cpu0/core_ctl/max_cpus 4
write /sys/devices/system/cpu/cpu4/core_ctl/not_preferred "1 0 1 0"
write /sys/devices/system/cpu/cpu4/core_ctl/min_cpus 2
write /sys/devices/system/cpu/cpu4/core_ctl/max_cpus 4
write /sys/devices/system/cpu/cpu4/core_ctl/busy_up_thres 78
write /sys/devices/system/cpu/cpu4/core_ctl/busy_down_thres 55
write /sys/devices/system/cpu/cpu4/core_ctl/offline_delay_ms 200
write /sys/devices/system/cpu/cpu4/core_ctl/task_thres 4
write /sys/devices/system/cpu/cpu4/core_ctl/is_big_cluster 1
Two + two should be most suitable deal performance wise especially regarding inter core (& cross cluster regarding it) communication very important for thread migration between clusters.
Best regards.
Click to expand...
Click to collapse
Okay I'm a test it tomorrow when I discharge battery. And that not_prefered doesn't work for me cause I'm using AICP and not nijel8's LOS and as I remember right nijel8 fixed something in core_ctl to make it work.
Jerry08 said:
Okay I'm a test it tomorrow when I discharge battery. And that not_prefered doesn't work for me cause I'm using AICP and not nijel8's LOS and as I remember right nijel8 fixed something in core_ctl to make it work.
Click to expand...
Click to collapse
Don't really know about it on AICP, what is & how implemented. Core ctrl is developed originally by Motorola and CAF for CAF obviously (read the CAF as the AOSP) fany part is all for max is based upon Lineage including AOSP alike ROM's. The not_preferred is actually used to mark which core's should be those kept active idling. If not_preferred works as it should please do & post (full) results for PCmark works 2.0 test
If it's not a to big problem for you regarding both 2+1 & 2+2 setup. Thanks in advance.
Zola III said:
Don't really know about it on AICP, what is & how implemented. Core ctrl is developed originally by Motorola and CAF for CAF obviously (read the CAF as the AOSP) fany part is all for max is based upon Lineage including AOSP alike ROM's. The not_preferred is actually used to mark which core's should be those kept active idling. If not_preferred works as it should please do & post (full) results for PCmark works 2.0 test
If it's not a to big problem for you regarding both 2+1 & 2+2 setup. Thanks in advance.
Click to expand...
Click to collapse
I'm sure that not preferred parameters doesn't work for me cause its using Strix los kernel. And yes I'll test both setups just give me few days as I'm testing new setups with at least 1 full battery cycle or more if I don't find it lagging or stuttering.
Zola III said:
@ioy
I don't really think you understand heuristics still.
1401600:99 & 1804800:99 are top frequencies per both clusters & it's a bit funny to try to manage their up scale load as their is no frequency behind it. You need a brick at big cluster at around 1.4GHz so find as I wrote earlier.
Click to expand...
Click to collapse
And what about this:
Code:
write /sys/devices/system/cpu/cpu0/cpufreq/interactive/target_loads "80 400000:87 1017600:95 1190400:99"
write /sys/devices/system/cpu/cpu4/cpufreq/interactive/target_loads "87 400000:90 1017600:95 1382400:99"
BTW what does the first number after "target_loads" mean?
HELIUM, LOCKED bootloader, [ROM][UNOFFICIAL][7.1.1][HYDROGEN/HELIUM]LineageOS 14.1 r.03-27-2017 by*nijel8
ioy said:
And what about this:
Code:
write /sys/devices/system/cpu/cpu0/cpufreq/interactive/target_loads "80 400000:87 1017600:95 1190400:99"
write /sys/devices/system/cpu/cpu4/cpufreq/interactive/target_loads "87 400000:90 1017600:95 1382400:99"
HELIUM, LOCKED bootloader, [ROM][UNOFFICIAL][7.1.1][HYDROGEN/HELIUM]LineageOS 14.1 r.03-27-2017 by*nijel8
Click to expand...
Click to collapse
Actuality try like this:
write /sys/devices/system/cpu/cpu0/cpufreq/interactive/target_loads "87 400000:90 1017600:93 1190400:95"
write /sys/devices/system/cpu/cpu4/cpufreq/interactive/target_loads "87 400000:90 1017600:93 1382400:95"
99 is bit to much & this is also with IO is busy idling enabled considered in.
Why's 99 too much? I have visibly better Ampere readings with this (while reading the forum through TapaTalk).
What does the first number after "target_loads" mean?
About busy idling, do you mean this:
write /sys/devices/system/cpu/cpu0/cpufreq/interactive/io_is_busy 1
is this right?
@Zola III
Well I decided to set up little cluster core_ctl today and it seems that it needs that not_prefered setting as after I set up 2+1(or 2+2 later) I ran into network problems. It was stopping network for few seconds every minute. So sorry but I won't be able to test it.

Categories

Resources