Develop Bugs

[Q] Xandroid vs. Tiad8

Hi all,
I've been a faithful WM user until I saw the beautiful work that matt (xandroid) has been doing. I followed his work since August of last year, and had Android on my touch pro2 (sprint).
I love everything about the work, but low battery part is just a killer for me. The latest Tiad version of froyo only lasts about 8 hours top (with minimum use - just email sync). I think Xandroid (FRX04) is lasting about 9 hours.
I keep going back and forth between FRX03/04 and Froyo work made by Tiad8. What are the relationship between these two work? I know the kernel is the same, but which is the one to go?
Battery life wise, are they any different (one better than the other)? or is that a kernel problem still? Has anybody been successful to run android on rhodium for all day with specific (old) kernel? As you can see, I don't care about camera, bluetooth, and etc.
As a user, I just want my phone to last a day for me. I work from 7 AM to 5 PM. As of right now, my phone won't last unless I charge it through USB during the day.
Let me know! Thanks all.
Mike

Well I dont think that we can compare the job of this 2 guys, tiad is triying to give us the missing parts like a good 3d and camera. and mathews is working righ know on stability and a ported version, both works are great, and im testing rightnow the FRX04 the battery last much longer than other builds. and i haven´t to hardreset the phone even once. on my rhod 500. working with GSM.

Sorry if I came out like comparing two works. I just wanted your two cents on battery; that's all.
Thanks!

There really is no difference with tiad8's build AFAIK. He just takes the latest and bundles them together for newbies. I wish he wouldn't name it different, as that makes it seem like it's completely different - when in reality the differences are minor - you can achieve the same build by dropping in the appropriate files.
With that said, battery life improvements are all going to happen at the kernel level. So you can take whatever build, and drop in a different kernel to improve battery life.
At this time, WisTilt2's test kernel is going to get you the best battery life. He's working on the rest of the devices so he can commit his code (basically our phone's are not sleeping correctly, the panel is still getting/sucking power even tho the screen appears to be off)
See the test kernel thread here.

Thanks for the post, Arrrghhh. You are talking about the wistilt2 kernel stripped version right?
I will try that with FRX04.
Thanks.

mike92585 said:
Thanks for the post, Arrrghhh. You are talking about the wistilt2 kernel stripped version right?
I will try that with FRX04.
Thanks.
Click to expand...
Click to collapse
Not sure what you mean by stripped version. I see now... that's down below in F22's post - focus on the first post . Just download the kernel-pack that's attached to the first post.
There was a discrepancy on the modules that needed to be included. It was sorted out, and the first post has the newest test kernel that WisTilt2 has provided me with.

I think they are "similar", but I must say that I always have issues with XDAndroid... It hangs when appears the Android home screen and I must reboot like 50 times before it works ok, also it's a little slow...In contrast, FroyoX always worked from the first time and is super fast without overclocking...That's my opinion!

nickleby said:
I think they are "similar", but I must say that I always have issues with XDAndroid... It hangs when appears the Android home screen and I must reboot like 50 times before it works ok, also it's a little slow...In contrast, FroyoX always worked from the first time and is super fast without overclocking...That's my opinion!
Click to expand...
Click to collapse
I'd honestly want to know the difference between the system image FRX04 and the 'Froyo X' system image. If there is a tangible difference, we need to change whatever tiad8 changed!
I wish that dude would work with us instead of in parallel to our work....

mike92585 said:
Hi all,
I've been a faithful WM user until I saw the beautiful work that matt (xandroid) has been doing. I followed his work since August of last year, and had Android on my touch pro2 (sprint).
I love everything about the work, but low battery part is just a killer for me. The latest Tiad version of froyo only lasts about 8 hours top (with minimum use - just email sync). I think Xandroid (FRX04) is lasting about 9 hours.
I keep going back and forth between FRX03/04 and Froyo work made by Tiad8. What are the relationship between these two work? I know the kernel is the same, but which is the one to go?
Battery life wise, are they any different (one better than the other)? or is that a kernel problem still? Has anybody been successful to run android on rhodium for all day with specific (old) kernel? As you can see, I don't care about camera, bluetooth, and etc.
As a user, I just want my phone to last a day for me. I work from 7 AM to 5 PM. As of right now, my phone won't last unless I charge it through USB during the day.
Let me know! Thanks all.
Mike
Click to expand...
Click to collapse
I was having a similar experience with my Sprint TP2. I updated to FRX04 and then the camera testing kernel but my battery life was about 6-8 hours.
I had it set to disable satellites but left "Use Wireless Networks" enabled and then last night I turned off all of the location options. Today I'm at 8 hours and the battery is only down to 68%. The other thing I looked at is that if you have Facebook, Twitter, Fourquare or any other apps running that any auto-refresh/updates/notifications are disabled.
Hopefully this helps you out. I've gone from hating my phone with it's constant lag in WM to loving using my phone with Android.

Mizofizo, let me see what you exactly did.
Since you use sprint and also in boston, we are pretty much on the same boat. However, no matter what I do, I can't get my battery to last all day. I always have both use wireless networks off and location options off as well. No facebook or nothing.
I am now at a point where I am even afraid to turn the screen on because of the battery drain.
Could you email me the startup.txt or pm me the detail? So you are using the stock FRX04 with which kernel are you running? Are you running the latest 1253?
This is my startup.txt that I have been using.
set ramsize 0x10000000
set ramaddr 0x10000000
set mtype 2292
set KERNEL zImage
set initrd initrd.gz
set cmdline "lcd.density=240 msmts_calib=0x9f.0x39a.0x35c.0x78 msmvkeyb_toggle=off pmem.extra=1 gsensor_axis=2,1,3 force_cdma=1 physkeyboard=rhod210 hw3d.force=1 htc_battery_smem.fake=1 north_am_dialing=1 pm.sleep_mode=1"
boot
Note pm.sleep_mode=1.
Thanks in advance.
Mike

mike92585 said:
Mizofizo, let me see what you exactly did.
Since you use sprint and also in boston, we are pretty much on the same boat. However, no matter what I do, I can't get my battery to last all day. I always have both use wireless networks off and location options off as well. No facebook or nothing.
I am now at a point where I am even afraid to turn the screen on because of the battery drain.
My email is . Could you email me the startup.txt or pm me the detail? So you are using the stock FRX04 with which kernel are you running? Are you running the latest 1253?
This is my startup.txt that I have been using.
Code:
set ramsize 0x10000000
set ramaddr 0x10000000
set mtype 2292
set KERNEL zImage
set initrd initrd.gz
set cmdline "lcd.density=240 [color=red][b]msmts_calib=0x9f.0x39a.0x35c.0x78[/color][/b] msmvkeyb_toggle=off [color=red][b]pmem.extra=1[/color][/b] gsensor_axis=2,1,3 force_cdma=1 [color=blue][b]physkeyboard=rhod400[/color][/b] hw3d.force=1 [color=red][b]htc_battery_smem.fake=1[/color][/b] north_am_dialing=1 pm.sleep_mode=1"
boot
Note pm.sleep_mode=1.
Thanks in advance.
Mike
Click to expand...
Click to collapse
I'd remove your email from the post - trust me, you'll get a ton of spam because of it. Just do <email> at <domain> dot com if you ever feel the need to put your email address into a forum (which I wouldn't do either )
Anyhoo, I highlighted in red/bold some of the commands you should consider removing. Especially the htc_battery_smem.fake!
Oh, and if you're on Sprint - is it a Sprint-branded phone? If so, that's a RHOD400. RHOD210 wouldn't even work on Sprint, as there's no CDMA radio in that device .

mike92585 said:
Mizofizo, let me see what you exactly did.
Since you use sprint and also in boston, we are pretty much on the same boat. However, no matter what I do, I can't get my battery to last all day. I always have both use wireless networks off and location options off as well. No facebook or nothing.
I am now at a point where I am even afraid to turn the screen on because of the battery drain.
Could you email me the startup.txt or pm me the detail? So you are using the stock FRX04 with which kernel are you running? Are you running the latest 1253?
This is my startup.txt that I have been using.
set ramsize 0x10000000
set ramaddr 0x10000000
set mtype 2292
set KERNEL zImage
set initrd initrd.gz
set cmdline "lcd.density=240 msmts_calib=0x9f.0x39a.0x35c.0x78 msmvkeyb_toggle=off pmem.extra=1 gsensor_axis=2,1,3 force_cdma=1 physkeyboard=rhod210 hw3d.force=1 htc_battery_smem.fake=1 north_am_dialing=1 pm.sleep_mode=1"
boot
Note pm.sleep_mode=1.
Thanks in advance.
Mike
Click to expand...
Click to collapse
I would delete the options that arrrghhh specified.
I'm running FRX04 with the camera testing kernel. My startup.txt is as follows:
set RAMSIZE 0x10000000
set RAMADDR 0x10000000
set mtype 2292
set KERNEL zImage
set initrd initrd.gz
set cmdline "lcd.density=240 msmvkeyb_toggle=off force_cdma=1 gsensor_axis=2,1,3 pm.sleep_mode=1 hw3d.force=1 physkeyboard=rhod400 board-htcrhodium.is_cdma=1"
boot
Note that I don't have a rel_path since I put everything in the root of my SD card.
With my current config, yesterday at about 16 hours of use (including wifi and gps) I had about 38% battery left.

Thanks to both.
I finally see the green led light on my tp2. =D
Hopefully I will get some long battery life now... I will post back once I do!

I have used the startup.txt details above but I still have issues with my phone waking up! The light never turns green and it will not wake up after a while of not being used.... any suggestions?
Using XDAndroid FRX04 1/23/2011
AT&T Tilt2
Kernel 1250

scattaman said:
I have used the startup.txt details above but I still have issues with my phone waking up! The light never turns green and it will not wake up after a while of not being used.... any suggestions?
Using XDAndroid FRX04 1/23/2011
AT&T Tilt2
Kernel 1250
Click to expand...
Click to collapse
Why are you using kernel 1250 instead of 1253 or the one included in FRX04? I'd try just using FRX04 as is. Make sure that all unneeded syncing/services are turned off.

scattaman said:
I have used the startup.txt details above but I still have issues with my phone waking up! The light never turns green and it will not wake up after a while of not being used.... any suggestions?
Using XDAndroid FRX04 1/23/2011
AT&T Tilt2
Kernel 1250
Click to expand...
Click to collapse
SoD issues still ensue - devs are looking into a potential resolution/root cause.

mizofizo said:
Why are you using kernel 1250 instead of 1253 or the one included in FRX04? I'd try just using FRX04 as is. Make sure that all unneeded syncing/services are turned off.
Click to expand...
Click to collapse
Thanks but I've tried all the available kernels... including the one that came with FRX04... its just really annoying because it happens almost everytime I pput my phone down for 5 minutes
arrrghhh said:
SoD issues still ensue - devs are looking into a potential resolution/root cause.
Click to expand...
Click to collapse
Well its good to know that I'm not the only one...

scattaman said:
Thanks but I've tried all the available kernels... including the one that came with FRX04... its just really annoying because it happens almost everytime I pput my phone down for 5 minutes
Click to expand...
Click to collapse
It does happen, but it shouldn't be that frequent. Are you running any apps when you put your phone down...? Post your startup.txt too, just to make sure there's nothing funky in it.
Also, have you tried NOT OC'ing? Are you on pm.sleep_mode=1?

For those of you with decent battery life, how do you setup android when running for the first time?

slapshot30 said:
For those of you with decent battery life, how do you setup android when running for the first time?
Click to expand...
Click to collapse
What do you mean? I formatted my SD card, unrared FRX04 to the root of my SD card. Changed the conf file to point to the root and configured my startup.txt. Afterward, I setup the camera kernel as well. That's about it.

[Q] Setting CPU governor to stop music clicking?

I have a small question regarding setting a CPU Governor. I searched for a while but couldn't find any answer.
I am running AcesMod007-Lite, which has the cpu governor set to smartass. It seems to be okay, but especially when playing music it has some trouble, because it is trying to save too much battery. The music has a small click now and then. And i'm hoping changing the governor will help (if it won't please say so, then I can stop trying ).
So I want to change it to Interactive. This should be possible according to the ROM description (- Available Freqs: CPU interactive, smartass, powersave, ondemand, performance - by snq-)
What I tried to change it:
In recovery (after mounting system):
adb shell echo "interactive" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
(Here I got an error: The system can't find the specified path)
adb echo "interactive" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
(Same error)
adb pull /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor G:\
(This wrote a file with userspace? I changed it to interactive, then pushed it)
adb push G:\scaling_governor /sys/devices/system/cpu/cpu0/cpufreq/
(Upon reboot I checked it, and it was set back to smartass)
When the phone was on:
I tried thesame as in recovery, and got the same errors, only when using adb pull, the content of the file was "smartass".
Does anybody have an idea how to make this work?

I don't have Ace on my phone at the minute, but from what I remember I'm pretty sure there's a scaling script in the system/etc/init.d folder. Use root explorer or similar and long press, open with text editor, then change smartass to the governor you want.
Reboot the phone and it should now be using the one you selected, I hope

Use ondemand governor. Also had problems with music playing with smartass governor in other roms. After switching to ondemand they never occurred again.
Swyped from Oxygen with Transparent XDA App

@mick
Thanks! You were right. Now it automatically switches to ondemand (thanks MatDrOiD).
But for some reason the music still clicks . Should I increase the processor max freq for screen off, or does anybody know any other solutions?

I dont really know any other solution other than to ask, did you change both governors, screen on and screen off?
btw the screen off I use "min 128000" and "max 384000"
yes, try upping the max til the clicking stops

Yes I did changed them both.
My frequencies are for screenoff (in that same file):
SLEEP_GOVERNOR_FREQUENCY_MIN="245000"
SLEEP_GOVERNOR_FREQUENCY_MAX="384000"
So I think that should be okay.
Somewhere I read that it was an possible issue with every Sense HD ROM, because there was an error in the HTC code. Then it would be unsolvable.
I am going to try setting the min to 128, maybe that magically helps.

PerfectLight said:
Somewhere I read that it was an possible issue with every Sense HD ROM, because there was an error in the HTC code. Then it would be unsolvable.
Click to expand...
Click to collapse
I use insertcoin at the moment and don't notice it.
It might not be the cpu settings, I don't know what else is tweaked in the rom, but if there are other things then it could possibly be that, memory etc.
I'm pretty sure I read in the thread when I used Aces that installing setcpu would disable the scaling script. Maybe install it and see if your problem clears, nothing to lose

It has been solved! I now use a different build.prop, which seems optimized in some way.
The clicking is gone, and the entire phone seems more responsive .
Thanks for the great help!

[PATCH] ondemand deep cpuidle detection

[EDIT: Feel free to jump to comment #9]
[EDIT2: last version of the patch to apply to the kernel is in comment #25, applying the patch to the kernel source is all you need to test]
[EDIT3: changed name to deep cpuidle, I figured "deep sleep" is usually meant as "suspend-to-ram" and this has nothing to do with suspend, suspend is entered at fixed SLEEP_FREQ and the cpu frequency is irrelevant during suspend because CPU power is cut-off]
On my galaxy S I've been monitoring my cpufreq stats and the stats/total_trans keeps increasing every second or so with default cpufreq values and ondemand governor, when the screen is off and the cellphone is idle. This means the cpu spends some time spent at the high frequency even if the cellphone is idle and screen off.
I noticed if I increase the ondemand/sampling_rate from the default 40000 (on i9000) to 80000 the total_trans go down to one every 10 or 20 sec. But I want to decrease the sampling_rate to 20000 so it takes only 20msec to jump to 1ghz. 40msec (the default) is too much. 40msec means 25hz but the first image frame would get lost because it'd be rendered at 100mhz instead of 1ghz. at 20msec of sampling_rate the frequency is 50hz so if the first frame is lost we're still down to 25hz which is less noticeable to the eye. I think 20000 is the max that sampling_rate should be set for decent responsiveness.
However if I drop the sampling_rate to 20000 as I prefer, when the screen is off the stats/total_trans increases even faster at a couple per second, than with the default of 40000, so sampling_rate 20000 is ideal for responsiveness but it will waste power when the screen is off.
So my solution is to force the max frequency allowed by the cpu policy to the min frequency when the screen is off. After that I can easily set sampling_rate to 20000 and io_is_busy to 1, by adding this the init.rc of the initramfs. I prefer io_is_busy to be 1, because 100mhz is really slow and the I/O will take some significant percentage of CPU too if set at 100mhz, and especially because after the I/O is complete I'll avoid losing one frame.
write /sys/devices/system/cpu/cpufreq/ondemand/io_is_busy 1
write /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate 20000
I'm also testing with up_threshold 80 but I'm not sure if it is better or worse... need to do more tests on the below one, could be a bad idea.
write /sys/devices/system/cpu/cpufreq/ondemand/up_threshold 80
This way I can tune the ondemand as aggressive as I need without sacrificing the powersaving when the screen is off. In fact it should use less power now when the screen is off than before.
The patch is for the ginger update2 kernel, running 2.3.4 XXJVR using the kernel modules of XXJVS (I rolled back the userland and initramfs to JVR because JVS disconnects wifi for me).
I've noticed there's a smartass2 governor which I didn't try, it may work better than this, but I tend to trust the ondemand governor to be the best for responsiveness, and my approach is much simpler than the smartass2 governor, I'm not in a mood of doing beta testing or risking instability for a feature that can be achieved so simply. If ondemand isn't aggressive enough I prefer ondemand to be improved to be more aggressive. Ondemand is what runs on most laptops/workstations so we can't afford it not to be as fast as it can.... The problem is not specific to cellphones. And when screen is off there is not point to ever increase the frequency over 100mhz on i9000 (and unfortunately it happens and it's not fair to pretend some background service to call usleep(1) just to avoid the frequency jump).
Note, you may want to remove the two printk from the patch, they shouldn't flood but they're only for debug...

I think you need to put a [MOD] in your title.

First, thx you for sharing your work !
Your .zip patch the existant ondemand governor, or it is adding a new governor which can be selected via app like voltage control & such ?

Anyone wanna try this out and share what it does actually? All thoaellse reading above are too technical for most of us I guess. I'd love to try but I'm on JVS now and you said it is for JVR.
Thanks for the share by the way...
Sent from my GT-I9000 using Tapatalk

cnn888 said:
Anyone wanna try this out and share what it does actually? All thoaellse reading above are too technical for most of us I guess. I'd love to try but I'm on JVS now and you said it is for JVR.
Thanks for the share by the way...
Sent from my GT-I9000 using Tapatalk
Click to expand...
Click to collapse
Well I'm running the JVS kernel on top of JVR userland+initramfs. It'll run perfectly on JVS but I only posted the source and it'll work for both
I'm also a bit annoyed often I see mods and tweaks and I try to search the source and it's not so easy to find it. I'd recommend people to post more source and less binaries.
You just need to ask one kernel builder that ships with the ondemand governor to apply my patch, add those 3 lines to the initramfs/init.rc file and rebuild and it'll work for JVS too. Theoretically it will drain less when the screen is off and it'll be a bit more responsive when screen is on.
---------- Post added at 07:42 PM ---------- Previous post was at 07:36 PM ----------
Rootax said:
First, thx you for sharing your work !
Your .zip patch the existant ondemand governor, or it is adding a new governor which can be selected via app like voltage control & such ?
Click to expand...
Click to collapse
The whole point of this approach is not having to change governor and to share the ondemand governor which must provide max performance and max responsiveness on laptop and desktops so I don't see the point of creating a new governor when the screen is on, considering the requirements are the same.
I thought lowering voltage was considered risky, I don't want to change voltage but if you want to change the voltage I think the best place to do it is still my two handlers I added in the patch, no new governor required, I doubt you want to change voltage when the screen is on, and when the screen is off I guess you want always the lowest voltage and lowest freq like me.
A new governor is not needed in short, just a few liner patch to set the max freq at the lowest when screen is off is my preference, especially because it's so much simpler

right... and umm... suppose that i want to apply this mod, how do we apply this patch of yours?
i'm sorry but am not really a linux frenzy...

cnn888 said:
right... and umm... suppose that i want to apply this mod, how do we apply this patch of yours?
i'm sorry but am not really a linux frenzy...
Click to expand...
Click to collapse
re-build kernel source
great work newmail !
another (non-invasive) approach
would be to use a bare screenstate_scaling (well - not really scaling)
init script and limit the max frequency via that + set those values

zacharias.maladroit said:
re-build kernel source
great work newmail !
another (non-invasive) approach
would be to use a bare screenstate_scaling (well - not really scaling)
init script and limit the max frequency via that + set those values
Click to expand...
Click to collapse
Thanks.
I figured with csipsimple with the proximity sensor, 100mhz are not enough.... so I'm now decreasing the max frequency to 800mhz when screen is off, and I'm keeping the default sampling_rate to 10000 msec (setting transition_latency to 10000, equivalent to writing 10000 into ondemand/sampling_rate).
I also changed the code a bit to call all notifiers when the max frequency changes from 1ghz to 800mhz.
Now I did quite a bit more tests and something's going wrong when screen goes off in cpufreq. The cpu is idle, but ondemand raises the frequency more than if the screen is on. That is probably why the cpu isn't very idle when the sampling_rate is reduced go give more responsiveness. If I change get_cpu_idle_time_us to return -1 unconditionally, the trans_total are greatly reduced with screen is off and the ondemand stays at the low frequency when screen is off with sampling_rate 10000 too.
I also tried to measure the cost of a frequency switch (including the overhead caused by ondemand sampling at 1khz) and it seems of the order of 38usec.
I'm wondering if there's some bug in the get_cpu_idle_time_us that is causing the jitters in the ondemand governor when screen goes off.

I found the problem with the ondemand governor while in earlysuspend suspend mode. The problem is that the cpu starts to go in deep sleep, so a sampling_rate of 10000 is applied only once in a while, the real sampling_rate becomes 1second or more.
So when that happens the CPU goes in deel sleep all the time and ondemand tends to stay stuck at the max frequency all the time, by mistake, despite the load is near 0%.
After deep sleep when a wakeup happens we return to the 10000usec sampling rate. ondemand sees activity after the deep sleep wakeup but those wakeups "loads" must be adjusted down if the previous wall_time delta was huge and the current one is tiny. We're too close to deep sleep to ramp up cpu freq.
So my solution is to tweak the ondemand to scale down the "load" according to the decrease in the wall_time delta ratio (deep_sleep_ratio variable).
When screen is on, or during a call or during playback with screen off, the deep_sleep_ratio is 1, so the ondemand behaves as aggressive as always. But the deep_sleep_ratio ramp up when the phone is idle and the idle deep sleep states starts. With this tweak I can use the ondemand governor with the default values and the sampling rate set to 10000 (for max responsiveness) and the cpu freq will stay down to 100mhz with no jitter when the screen is off and the load is near 0% (instead of staying close to 1ghz most of the time with the 10000 sampling rate setting, 40000 of the JVS tends to hide it but it still jitters a lot and it hurts interactivity to be unable to set it below 40000).
In my first post I already noticed this jittering of the ondemand governor with the screen off. And I thought to solve it by lowering the freq to min with the screen off (which screwed csipsimple). I also noticed that a sampling_rate of the order of 100000 would decrease the jittering and with 10000 the cpu freq would be set at the maximum all the time. But the real problem was the ondemand comparing apples to oranges with the deep sleep state, and this explains why the jittering wasn't as bad with the screen on, as opposed to the badness with the screen off and the CPU going in deep sleep at high freq most of the time.
So this heuristic I wrote solves the problem, and I also disabled all those dvfs magics in cpufreq that prevented to use the 100hz frequency most of the time. It works fine for me with screen on, and now with screen off (proximity sensors) voip works perfectly too (I also verified deep_sleep_ratio is 1 during calls with proximity sensor activated). Any real activity will prevent the deep sleeps so it's perfectly ok to ignore the high loads measured just after returning from the deep sleep.
Anyway feel free to experiment. I also wrote another patch to switch the governor to performance automatically when screen goes on, and return to ondemand (with deep sleep detection) when screen goes off. But I think this heuristic is better and ondemand won't be exactly as fast as "performance" but especially at 10000 sampling_rate the difference should not be noticeable. And so I prefer to save a tiny bit of power by using ondemand all the time. Plus it proofs the new logic is good if it works for both scenarios.
I still decrease the max cpu frequency when screen is off to 800mhz (not anymore to 100mhz after I found it screws the voip and playback with screen off). ondemand will immediately jump to max the moment the threshold is exceeded (default threshold is 95% of not idle time). So this helps because all csimpsimple/skype/musicplayer background non-interactive workloads that may run with the screen is off and this will avoid to ever reach 1ghz which isn't needed for any of those background apps. 1ghz returns when screen goes on again.
In addition to this patch you can also consider adding these two lines to init.rc, but they're just to tune it a bit more aggressively. In the end I couldn't measure any difference from either one (default is 0 for io_is_busy, and 95 for up_threshold) so I'm using the default values and I didn't add the below to my currently running kernel. Probably you can ignore this and only apply the patch to the kernel.
write /sys/devices/system/cpu/cpufreq/ondemand/io_is_busy 1
write /sys/devices/system/cpu/cpufreq/ondemand/up_threshold 80
I recall having read of some tweakded ondemand governor in some rom, but there was no link to source... again I recommend folks to post link to source whenever a new cooked rom is published.
Considering this is closer to a bugfix, if this is confirmed to work by others I can try push the deep_sleep_ratio as a core feature in the kernel, maybe under some better name, to enable in sysfs so in future releases changing init.rc would be enough. It may be useful to other than arm as this is a common problem of what happens after the cpuidle governor enter deep sleep and sleeps more than the sampling_rate.
You can use this to monitor the effect before/after.
adb shell 'cd /sys/devices/system/cpu/cpu0/cpufreq; while :; do cat stats/*; sleep 1; done'
With the patch applied (which also sets sampling_rate at 10000, your default currently is 40000) you will get this when screen is off.
3384
1000000 11256
800000 21625
400000 1642
200000 6266
100000 469564
3384
1000000 11256
800000 21625
400000 1642
200000 6266
100000 469669
3384
1000000 11256
800000 21625
400000 1642
200000 6266
100000 469774
3384
1000000 11256
800000 21625
400000 1642
200000 6266
100000 469888
3384
And this with screen on (without touching
3461
1000000 11316
800000 22619
400000 2067
200000 6290
100000 477547
3461
1000000 11316
800000 22619
400000 2067
200000 6290
100000 477652
3461
1000000 11316
800000 22619
400000 2067
200000 6290
100000 477758
3461
1000000 11316
800000 22619
400000 2067
200000 6290
100000 477864
3461
1000000 11324
800000 22619
400000 2067
200000 6297
100000 477956
3464
There is some seldom jitter still but nothing significant anymore (and with sampling_rate set to 10000, it wasn't just a jittering problem but it was at max freq all the time). Some minor jittering like above is just unavoidable if some userland run a bit longer, and at 100mhz it doesn't take much CPU load to run longer.
I also measured the raw performance by calculating PI and it's within the measurement range error if compared to performance governor. quadrant just fine too unchanged over 1600 at the 3rd run, so I'm optimistic it's not degrading perf.

cnn888 said:
right... and umm... suppose that i want to apply this mod, how do we apply this patch of yours?
i'm sorry but am not really a linux frenzy...
Click to expand...
Click to collapse
I could upload a .tar file to flash in odin somewhere... but I worry about the redistribution of a zImage with an initramfs including those annoying binary modules that aren't GPLv2 (or we would have the source of those too) and I can't easily get rid of.

Dividing the load by deep_sleep_ratio was too aggressive. I noticed some app was more laggy than with "performance" governor. The better approach to the long deep sleeps is to ignore jitters until the wall_time_delta converges. I added comments on the reason why this is better, and it seems also better to ignore time jitters in both directions (so also to ignore measurement of long wall_time when the wall_time_delta average is short, with screen on). I attached an update, it still avoids the jittering with the screen off and phone idle, and it works better with the phone on.
With this one phone sits at 100mhz with screen off (freq range with screen off 100mhz-800mhz), works fine when doing voip calls with proximity sensor as before. With screen on the freq range is now 200mhz-1ghz, considering that without the patch the phone may never reach 100mhz even with screen off, it is most certainly not going to make a difference and 100mhz is way too slow and we've to run at least 10msec at 100mhz before we can ramp up the freq. So this will double speedup those first 10msec compared to the prev version. The jittering with screen off completely goes away and the phone stays at 200mhz fixed if you disable the rotation sensors, otherwise there are 2 jitters from 200mhz to 1ghz and back per second, which is certainly fine.
I've been using for a while and I'm pretty happy and should work better than the previous version. That app were I noticed an higher lag with previous version, now seem to be as responsive as performance or at least I can't see a difference anymore.
If you test it let me know and please check when screen is off and phone not awake, if the battery is lasting longer or not. By looking the chart I attached (running the sleep2 version in this post) it seems my battery went down 2/3% in 6 hours with this. Frankly I don't remember if it was as good before... all I know for sure is that what happened before with ondemand didn't make much sense: a proper governor allowed to use a range from 100-800mhz must keep the cpu at 100mhz when screen is off and phone is idle, and with the deep sleep detection fix, ondemand finally behaves well, and it works fine with voip with screen off, it doesn't require to rump up the min freq from 100mhz to 200mhz with screen off, and it seems more responsive than before thanks to the 4 times more frequent sampling rate (and maybe also thanks to ignoring the long deep sleep cycles during interactive behavior but that I'm not entirely sure if it helped but it still looks good idea to ignore the infrequent wall_time_delta jitters). It's also likely that the cpu goes into very long deep sleep shutting down the cpu harder and maybe the freq it enters those states don't matter, but at least this should help if you play music in the background with the screen off, it manages to do that now at 100hz without skips.

It's certainly refreshing to see good research being done in a consistent manner. Keep up the good work

pikachu01 said:
It's certainly refreshing to see good research being done in a consistent manner. Keep up the good work
Click to expand...
Click to collapse
Thanks well it all started with my phone being 80% dischared for two mornings in a row and that annoyed me enough to look into this. I was pretty certain it wasn't a kernel problem (I think it was the broken update of the facebook app that has "keep phone awake" privilege and is buggy, I uninstalled it since then) but that still made me look into this... and what I found looking at the cpufreq stats with screen off wasn't too pretty, it just become utterly ugly if I decrease the sampling_rate to 10000, and so I spent the weekend trying to fix it. In any case I'm unlikely to post further updates until next weekend .
Another possible way to fix this would have been to have the cpuidle governors interacting with the cpufreq governors through some notifier call... but adding a small heuristic to ondemand to detect the wall_time_delta jitters was certainly simpler.

newmail said:
Thanks well it all started with my phone being 80% dischared for two mornings in a row and that annoyed me enough to look into this. I was pretty certain it wasn't a kernel problem (I think it was the broken update of the facebook app that has "keep phone awake" privilege and is buggy, I uninstalled it since then) but that still made me look into this... and what I found looking at the cpufreq stats with screen off wasn't too pretty, it just become utterly ugly if I decrease the sampling_rate to 10000, and so I spent the weekend trying to fix it. In any case I'm unlikely to post further updates until next weekend .
Another possible way to fix this would have been to have the cpuidle governors interacting with the cpufreq governors through some notifier call... but adding a small heuristic to ondemand to detect the wall_time_delta jitters was certainly simpler.
Click to expand...
Click to collapse
well, I don't know how motivated or how much time you want to spend in investigating this
but if want to dedicate some more time
make sure you also take a look how ondemandx works
(cpufreq_ondemandx.c in my repo)

zacharias.maladroit said:
well, I don't know how motivated or how much time you want to spend in investigating this
but if want to dedicate some more time
make sure you also take a look how ondemandx works
(cpufreq_ondemandx.c in my repo)
Click to expand...
Click to collapse
Thanks for the pointer! Appreciated . I won't have much time to look into this until the next weekend (I'll look into it ASAP , but with the last version I posted in comment #11 (ondemand-deep-sleep2.patch) things are going absolutely great. In fact it works much better with skype than the stock unpatched kernel: when I iconize skype during a call it won't degrade the audio anymore. I'm sure it degraded audio for a little if I iconized skype and started another app during a call. I guess it's the faster sampling rate, or maybe the fact I now ignore the long idle times if the average wall_time is short. Both are good.
The sampling_rate not being constant with long cpuidle times that disregard software timers, really requires this fix to the ondemand to perform great. So I'm super happy about this change so far. 100-800/200-1000mhz also works great. And this change won't have any effect on laptops/workstations where the timers should fire as expected. (I also tried 100-400/400-1000 for a while but there's no point it seems, 100-800/200-1000 is enough so I'm back to the exact values in the last patch I posted)
I doubt it's worth to stop the sampling like interactive governor does while cpu is idle, considering cpuidle will disregard the timers so there's no risk to wakeup too early because of a timer it seems.... I think this changes will improve ondemand in general and it is required fix for these phones IMHO.
The fact background apps like music player with screen off now run 95% of the time at 100mhz also looks great. I didn't have any sign of instability, and I run a lot of load on it (though only for the last few days...). I sent my patch to some samsung engineer who added the SLEEP_FREQ to the cpufreq upstream code (to enter suspend to ram at 800mhz which I didn't alter, that sure is fine change considering the cpu is cut off the power during suspend to ram, it'll speedup suspend to ram too in addition to not crashing phone as described in the patch . In my patch I only handle the frequency changes right when cpuidle runs for long and I doubt the cpu is cut off the power for only 60msec or 500msec when screen is off, that's too fast to cut the power completely I guess so I think it's worth it. And if it doesn't help to save power when idle, for it sure won't hurt either and the statistics now look sane and this change should help while using the phone too by allowing to lower the sampling_rate and avoiding interactive usage to be fooled by long cpuidle samplings started at high freq that decrease the freq just before the real loads come in and idle is exited (ignoring those long wall_times during interactive usage is also good and should save power too as the load will complete faster and cpu will be allowed to spend more time in idle at low freq then).

Deep Sleep
Hi, you said that you first came to this topic because some app was keeping your CPU from deep sleep, probably FB app. This night I also experienced that the phone did not go into deep sleep, it was awake all the time according the battery status. So is there a way to check, which app causes this behaviour?
See attachment for a screenshot.

newmail, against what kernel base does your patch apply ?
samsung kernel sources JVB & JVH (1st release + 1st update) ?

zacharias.maladroit said:
newmail, against what kernel base does your patch apply ?
samsung kernel sources JVB & JVH (1st release + 1st update) ?
Click to expand...
Click to collapse
Thought you were on time-out??

dachau said:
Thought you were on time-out??
Click to expand...
Click to collapse
This is his time out, wait till you see him on his kernel dedication time.
^^
Sent from my GT-I9000 using XDA Premium App

newmail said:
I could upload a .tar file to flash in odin somewhere... but I worry about the redistribution of a zImage with an initramfs including those annoying binary modules that aren't GPLv2 (or we would have the source of those too) and I can't easily get rid of.
Click to expand...
Click to collapse
Newmail, first of all your analysis + the mod for governor was awesome !
basically actually not a dev and i can't patch my kernel myself (hmm.a noob kinds when it comes to kernel stuff )
i'm wondering how would be your patch's results vs Smartassv2's coz your patch includes the stuff directly in Ondemand Governor that's a perfect approach making it more effective .
So, please could you prepare a CWM flashable if possible on behalf of those GPLv2 (idk what are those btw ) or a step by step procedure to perform the FIX .. ?
Thankyou again for your approach on CPU freq tweak !!

SetCPU... is it needed for CM7?

I searched for answers but didn't get satisfactory results, so I wanna ask my G2 peeps.
CM7 has an OC daemon, right?
Since it does, is SetCPU still needed?
How does one configure the OC daemon with profiles for screen off, battery>50% etc etc?
I am running CM7.1

convolution said:
I searched for answers but didn't get satisfactory results, so I wanna ask my G2 peeps.
CM7 has an OC daemon, right?
Since it does, is SetCPU still needed?
How does one configure the OC daemon with profiles for screen off, battery>50% etc etc?
I am running CM7.1
Click to expand...
Click to collapse
CM7 does have an OC daemon but it does not have profile settings like SetCPU. Most feel that using profiles kills the battery faster than not using profiles as the device is having to poll the system so frequently. If you just set the min and max speeds, you'll be fine.
Sent from my HTC Vision using XDA App

Just a question though. What does ONDEMAND govenor do?
Like when the phone is not doing anything, the phone will automatically go to the minimum clockspeed, and if you are playing intense games, the phone will max out?
Does that mean when the phone is screen off, the clockspeed will be minimum?
Because the only reason I have setcpu is to set the profile so it goes to 500/200 mhz screen off...

I think the CM7 included OC/UC manager is pretty darn good. I wouldn't worry about using SetCPU it'll just interfere.
convolution said:
Just a question though. What does ONDEMAND govenor do?
Like when the phone is not doing anything, the phone will automatically go to the minimum clockspeed, and if you are playing intense games, the phone will max out?
Does that mean when the phone is screen off, the clockspeed will be minimum?
Click to expand...
Click to collapse
Yes. You can see the exact way that each governor works, but that's pretty much the case with ONDEMAND.

convolution said:
CM7 has an OC daemon, right?
Click to expand...
Click to collapse
No, there is no background process (daemon) controlling the cpu min/max.
It only applies the settings at boot, aside from that, it does nothing.
on our devices, there are three (main) files that effect the cpu overclocking:
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
writing a value to these files will make the cpu do what you want. (which is what the CM7 controls do)
You can still use SetCPU if you want... all it does is write the values to these files & the kernel handles the rest.
For example, it can be a slightly more convenient method of cranking up the max frequency if you are about to play a particularly cpu intensive game.
I also find SetCPU handy to do a quick check on the "time in state" & "memory" stats
If you want to use the SetCPU profiles, then, as OriginalGabriel pointed out, it could lead to slightly increased battery usage as SetCPU has to remain running in the background monitoring the variables.
If you don't use the profiles, then SetCPU won't consume any battery.
virtuous_oc, andrev_oc & ilwt_oc are a background process (daemon) that react to a change in screen state & write their defined settings to the above mentioned files.
The difference:
SetCPU runs in Android userspace & has to wait for the android system to send out a broadcast intent that the screen has been turned on/off before it can react & write the values to the files mentioned above.
The OC daemons do not run in userspace & detect the change in screen state at a kernel level... they will have written the values to the files well before the intent gets broadcast.
convolution said:
Just a question though. What does ONDEMAND govenor do?
Like when the phone is not doing anything, the phone will automatically go to the minimum clockspeed, and if you are playing intense games, the phone will max out?
Does that mean when the phone is screen off, the clockspeed will be minimum?
Because the only reason I have setcpu is to set the profile so it goes to 500/200 mhz screen off...
Click to expand...
Click to collapse
The governor controls how the cpu steps up or down the available frequencies based on the current load.
Each of the governors use a slightly different algorithm in how the cpu steps up or down. (within Max & Min as specified by scaling_max_freq & scaling_min_freq)
The well known governors from the mainline Linux kernel:
Ondemand: at the onset of load, jumps straight to max frequency & then steps down through the frequency table.
Conservative: steps up through the frequencies & back down.
Performance: this governor just keeps the cpu at scaling_max_freq & doesn't scale down
Powersave: this keeps the cpu at scaling_min_freq & doesn't scale up
Also, there are a number of governors that have come about from the Android community, I don't have the time right now to write about all the others that I know of... but can do at a later stage if it helps?
The important thing to note, is that unless you device is staying awake when the screen turns off, the screen off profiles are somewhat pointless, as the cpu effectively gets turned off.
Sorry bout the wall of text... am at work & typed it out in a bit of a hurry... hope it all makes sense

Its not needed but u can use it
Sent from my HTC Vision using xda premium

[Tutorial] Undervolting (Full Throttle)

**DISCLAIMER** What you do to your phone is your responsibility and this guide will instruct properly but the extra input of a 0, or any number for that matter, can cook your CPU so move forward with caution!!
For now, this is dedicated to those of us still using HO!NO! Full Throttle AND HO!NO! V20F Mod ROM (thomas.raines is working on his LZ oc/uv kernel). The extent to whether the stock uv (undervolt) settings are intact are not entirely sure, but what I do know is with proper undervolting I've been able to get 1d 12hrs out of the stock battery with 1 1/2 screen on time. Let me begin by describing what undervolting/overvolting is:
Dynamic voltage scaling to increase voltage is known as overvolting; dynamic voltage scaling to decrease voltage is known as undervolting. Undervolting is done in order to conserve power, particularly in laptops and other mobile devices, where energy comes from a battery and thus is limited. Overvolting is done in order to increase computer performance, or in rare cases, to increase reliability.
To get the most out of our batteries, uv'n is a key component. All of this is done in Full Throttle under /ect/init.d/99ocvoltcontrol. My tutorial will be done using RE (Root Explorer). It's quite simple, to be honest, and will get you some serious battery life!
Step 1.
Navigate to /ect/init.d/99ocvoltcontrol and set RE to R/W. Hold down the 99ocvoltcontrol file and 'Open in Text Editor'.
Step 2.
You're going to see a lot of 'rubbish', if you will, but the only sets of numbers we worry about are the first two sets in each line. The first number, i.e. 192000 is the clock speed and the 800000 is the current voltage.
What you're going to do from here is select the 800000 and change it to something like 750000, which would result in a -50 uv for that clock speed, which in turn uses less power when in sleep mode or resting at that clock speed.
Example: echo "192000 800000" > /sys/devices/system/cpu/cpufreq/vdd_table/vdd_levels
subtracting 50 from the 800000
Result: echo "192000 750000" > /sys/devices/system/cpu/cpufreq/vdd_table/vdd_levels
That's it! Simple, right? You just do that to the remaining clock speeds; adjusting each clock speed to your liking and what works best w/ your phone.
Step 3.
Hit the 'Menu' key on your phone and select 'Save and Exit' and reboot your phone and profit!
Example: My uv settings are as such: -75 from 192Mhz to 1080Mhz; -50 from 1134Mhz to 1566Mhz; and -25 upto 1728Mhz
Keep in mind, in my experience, the higher the clock speed, the more voltage it needs, obviously, so be careful going too low at higher levels.
So try different voltage settings and see what works best for your phone. I've found that going -100 at 192Mhz causes reboots, for example.
Screenshot of battery time in 2nd post...

Stock battery w/ the settings I posted in the OP.
Sent from my LG-P930 using xda premium

Very helpful and clear instructions, but is the current undervolt set by the Full Throttle ROM not enough?

Technocian said:
Very helpful and clear instructions, but is the current undervolt set by the Full Throttle ROM not enough?
Click to expand...
Click to collapse
That's why I made mention if they're stock voltages or not in FT but if your phone will take lower settings, do it..just be careful! Don't add an extra number. I can't stress that enough! If you set them too low, the worse that will happen, in my experience, is a reboot. Just change the value back to a more stable setting. Have fun w/ it!

X0dus said:
That's why I made mention if they're stock voltages or not in FT but if your phone will take lower settings, do it..just be careful! Don't add an extra number. I can't stress that enough! If you set them too low, the worse that will happen, in my experience, is a reboot. Just change the value back to a more stable setting. Have fun w/ it!
Click to expand...
Click to collapse
I'll give your values a try. Is there a cellphone equivalent to Intel Burn Test or Prime 95? Something to ensure stability would be nice. Also, I never looked into it... but how much more of an undervolt is this compared to stock Full Throttle?

Technocian said:
I'll give your values a try. Is there a cellphone equivalent to Intel Burn Test or Prime 95? Something to ensure stability would be nice. Also, I never looked into it... but how much more of an undervolt is this compared to stock Full Throttle?
Click to expand...
Click to collapse
I use stability test from the play store. The stock FT voltage settings are: #! 800000 825000 825000 850000 850000 875000 875000 900000 900000 925000 950000 975000 975000 1000000 1000000 1025000 1025000 1050000 1075000 1100000 1125000 1150000 1150000 1175000 1200000 1225000 1250000 1275000 1300000 1325500 1350000 1375000 ... So, subtracting 50, 75, or even 100 from any of those in their respective spots will result in such an uv.
Sent from my LG-P930 using xda premium

Updated Step 2 to clarify any confusion.
I also changed my UV settings from -75 @ 192Mhz to -100 up to 486Mhz. The max CPU value while in sleep mode is set @ 486Mhz by default so I figured if I can get lower voltage scales in those few than I'm gonna. Passed 6 runs of Stability Test (Play Store).

at normal temperature, your phone should be worked ok with UV. the default voltage from stock manufacture make sure it's work on more wide range of environment's condition. when you put it down, it's mean you narrow the range condition. sometime it work ok, normally, sometime will have some issue. take care with your UV value.
---------- Post added at 07:56 PM ---------- Previous post was at 07:48 PM ----------
one more thing, this voltage will feed to one by one each transistors on components of your phone's chip. hope that your change not affect too much to operating of your chip. I guess manufacturer had set limit range value to restrict users who are "tamper limbs"

Bump for HO!NO! V20F Mod ROM. This tutorial is good for his ROM, too, but his is already undervolted atleast -25 already compared to FT v9, fyi.

X0dus said:
[...]
Click to expand...
Click to collapse
Wow, very good guide!
I've always been kind of intimidated by the oltage settings for our phone but your guide has helped me to better understand the settings and files required to edit.
+Thanks