Database Users

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.

[resolved] Revisiting egl.cfg

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.

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

[Q] Best settings for WIUI V4

Hello everybody, this is my first post
I'm a Defy user and my favorite Rom was Miui, before than I Knew WIUi v4, It's really great and works so good even if still without a Radio.
I would ask you this question:
what would be better settings for best perfermance with this Rom?
my Defy, with Miui obtains more than 3000 score wit antutu benchmark, while WIUI obtains only 2800 score after a lot of workaround.
Here my settings:
Undervolt / Overclock
VSel1: 22 @ 300
VSel2: 44 @ 600
VSel3: 66 @ 1200
up treshold 90%
Cpu
min free kbytes= 8192,
dirty ratio: 96,
dirty background ratio= 60,
vfs cache pressure = 20,
Memory
Foreground App (mb): 6
Visible App (mb): 12
Secondary Server (mb): 16
Hidden App (mb): 82
Content Provider (mb): 90
Empty App (mb): 98
I Hope someone should suggest me something better.