Related
If you are using one of the Over-Clocked Undervolted Kernels please uninstall set-cpu and observe your battery life for 3 days and compare it to what you got when you used set-cpu. Then report as to if it is better, worse, or the same.
Just compare to what how long your battery lasts with your normal usage. Please do not give replies like "I only used 30% in two days with normal use."
Just reply with either better, worse, or same. Because usage is relative and that is not the purpose of this.
I think that set-cpu is interfering with the built in govenor and its ability to scale the freq of the phone. I think that it is staying on what-ever freq you set in set-cpu and scaling properly and thus reducing the battery life, and making the undervolting useless.
IF YOU BELIEVE YOU HAVE BETTER BATTERY LIFE WITHOUT SETCPU, THEN GET LOGS WHILE IT IS RUNNING AND SEND THEM TO THE DEV.
I have also noticed lag on the home screen with setcpu, I started using Overclock Widget to detect the values and to diff freq screen off 245-576 and put the phone on sleep while charging so will stay cool. Battery life has been great so far! I'm using 2.6.33.4 [email protected] #1 about to upgrade to his newest 2.6.34...I think SetCpu has flaws!
Will let you know my results.
this thread may be of some help. im currently trying pershoots 5.12vfp release without setcpu at all.
i do, however, remember getting 37 hours with moderate use with setcpu and profiles set, but i cant remember which kernal it was exactly. i think it may have been IRs 4.29 release..
Just uninstalled SetCPU and I'm running Pershoot's newest 2.6.33.4 925 Kernel. I will report back my findings in a couple of days...
Been curious about this for a while, but does the Nexus automatically throttle CPU speed by itself when SetCPU is not installed?
paulk_ said:
Been curious about this for a while, but does the Nexus automatically throttle CPU speed by itself when SetCPU is not installed?
Click to expand...
Click to collapse
Nope, incredible and onwards only.
Did this Quite a bit ago... ran with and without for over a week and i have better battery life without setcpu
When you don't have setcpu, you're not running at 1113ghz..
persiansown said:
When you don't have setcpu, you're not running at 1113ghz..
Click to expand...
Click to collapse
Perhaps...However, Linpack is proportional (I think) to the device's performance. My little experiment was testing different frequency kernels and measuring that against Linpacl
998: 7.4
1.13: 8.2
1.19: 8.9
So it would appear that performance increases with each kernel which wouldn't be the case if SetCPU was required.
I have some reasons to believe that SetCPU would interfere with the actual design of the Nexus One. I mean after all, i'm sure it was programmed to manage itself. So why have another app that does the same thing, twice? Just a thought, but for one thing, my phone is definitely cooler when charging compared to having SetCPU with profiles.
dogiedogie said:
Nope, incredible and onwards only.
Click to expand...
Click to collapse
You mean that the Incredible features CPU throttling?
jlevy73 said:
Perhaps...However, Linpack is proportional (I think) to the device's performance. My little experiment was testing different frequency kernels and measuring that against Linpacl
998: 7.4
1.13: 8.2
1.19: 8.9
So it would appear that performance increases with each kernel which wouldn't be the case if SetCPU was required.
Click to expand...
Click to collapse
There are dozens of potential optimizations that can be done to improve performance without touching the cpu speed. Different kernels, especially if they're from different people, will have different flags set in the build and so will perform differently even at the same clock speed.
Casao said:
There are dozens of potential optimizations that can be done to improve performance without touching the cpu speed. Different kernels, especially if they're from different people, will have different flags set in the build and so will perform differently even at the same clock speed.
Click to expand...
Click to collapse
I completely agree however all the kernels I use are from the same person and the optimizations at the different clocks speeds are identical. Therefore the spread in my linpack scores indicate that setcpu is not required. At least, that's my theory
this and other threads have made me question why we need setcpu anyways. I have it running and its great but can't we just integrate what setcpu is doing from the get go instead of having an external app running a separate process?'seems a little inefficient to me. The reason I say this is that I noticed most people are using the same settings for set cpu.
anyways, I dunno how relevant all this is since froyo's just around the corner and that may alleviate some problems but bring more problems
Yeah, start bashing my app, knowing I was the one who came up with the ideas behind the 1113MHz/uv hack in the first place (in fact, I came up with the 21MB hack as well, so prominently displayed in the OP's kernel thread title). Thanks, nexus one community.
I can explain that setcpu does not run any code in the background if your profiles are disabled, I can explain how cpufreq works, I can explain what lengths I went to to optimize the profiles, and I can explain that the profiles are very passive (except sometimes on the Droid, but there's an option for tweaking that) but I probably won't bother. Grab 1.5.3a and use it, or don't use it. I don't care either way.
I think that set-cpu is interfering with the built in govenor and its ability to scale the freq of the phone. I think that it is staying on what-ever freq you set in set-cpu and scaling properly and thus reducing the battery life, and making the undervolting useless.
Click to expand...
Click to collapse
You obviously do not know how cpufreq works. Setcpu does not touch the values after it sets a profile. Profiles actually run code only when it receives broadcast intents. It sets the max and min bounds and the governor if necessary within a fraction of a second. The service is completely idle otherwise. It can't "interfere with the built in governor." Okay, then. What is your big theory? What exactly is setcpu doing wrong?
SetCPU is advantageous because it allows you to tweak speeds on the fly and based on certain conditions. You can have solely kernel based overclocking and undervolting, sure, and that is perfectly fine. SetCPU is a convenient tool for controlling that without having to compile and flash a new kernel. If you do not like profiles, do not use them. They were only introduced in 1.3.0 But don't uninstall SetCPU because it does nothing with profiles disabled.
dogiedogie said:
Nope, incredible and onwards only.
Click to expand...
Click to collapse
HTC implements a rather awkward driver in nearly all of their Sense UI devices (and I think the Magic 32A) that throttles based on certain conditions. I am not entirely sure how it works, as I have not looked into the specifics, but it seems to max out the CPU under some conditions.
chowlala said:
I have some reasons to believe that SetCPU would interfere with the actual design of the Nexus One. I mean after all, i'm sure it was programmed to manage itself. So why have another app that does the same thing, twice? Just a thought, but for one thing, my phone is definitely cooler when charging compared to having SetCPU with profiles.
Click to expand...
Click to collapse
I am 100% sure this is placebo effect. Setcpu can't make your phone run hotter just because it's there. If you had a charging profile set for 1113/1113, sure, but that is not setcpu itself. Linux does not control the CPU scaling any further than what ondemand does - there is nothing preventing the CPU from going up to your max during sleep (or rather, when the screen is off), for example, or when your battery is low.
Oh, and using the active widget is a bad idea if you care about battery life. I tried to optimize it as much as possible, but realize that it's updating a lot more things than other apps are (the frequency, the bounds, and two temperature readings) at a relatively fast interval. The home screen does pause a bit while it is updating. That is a fact of life. Longer intervals are essentially useless because the update interval for cpufreq itself is on the order of thousands of microseconds. The current appwidget refreshes if the screen is on, regardless of whether it's visible or not (there is currently no way to tell if it is visible). A live wallpaper would be a much better idea than a constantly updating appwidget, and I'll look into that.
Let me explain this bit better. Cpufreq will scale your CPU between the max and min values automatically. Once the CPU load hits the "up threshold," it takes your CPU frequency from the min to the max, then gradually eases it down. SetCPU lets you easily change the max and min values on the fly. If you want, it can also prevent the system from scaling the CPU up that high during times you don't want it to (with profiles, of course). It does not and cannot interfere with the actual governor.
Well there you have it, straight from the source
TL;DR - setCPU doesn't run code in background unless you use profiles, it doesn't make your phone hotter unless you use a 1113/1113 profile, & if you value battery life don't use setCPU Active widget.
SetCPU
coolbho3000 said:
...
Click to expand...
Click to collapse
Props dude. Keep up the good work.
To be honest I'm a user, donator and supporter of SetCPU. I've never had cause to complain.
Not bashing your app dude, in fact I have the paid version. I am only wondering why people are noticing better battery life without it than with it. Want to see if it really is setcpu or something else. To do that something has to be isolated.
And I believe that if the freq are set in the kernel then the phone will scale up an down on its own.
coolbho3000 said:
Yeah, start bashing my app, knowing I was the one who came up with the ideas behind the 1113MHz/uv hack in the first place (in fact, I came up with the 21MB hack as well, so prominently displayed in the OP's kernel thread title). Thanks, nexus one community.
I can explain that setcpu does not run any code in the background if your profiles are disabled, I can explain how cpufreq works, I can explain what lengths I went to to optimize the profiles, and I can explain that the profiles are very passive (except sometimes on the Droid, but there's an option for tweaking that) but I probably won't bother. Grab 1.5.3a and use it, or don't use it. I don't care either way.
You obviously do not know how cpufreq works. Setcpu does not touch the values after it sets a profile. Profiles actually run code only when it receives broadcast intents. It sets the max and min bounds and the governor if necessary within a fraction of a second. The service is completely idle otherwise. It can't "interfere with the built in governor." Okay, then. What is your big theory? What exactly is setcpu doing wrong?
SetCPU is advantageous because it allows you to tweak speeds on the fly and based on certain conditions. You can have solely kernel based overclocking and undervolting, sure, and that is perfectly fine. SetCPU is a convenient tool for controlling that without having to compile and flash a new kernel. If you do not like profiles, do not use them. They were only introduced in 1.3.0 But don't uninstall SetCPU because it does nothing with profiles disabled.
HTC implements a rather awkward driver in nearly all of their Sense UI devices (and I think the Magic 32A) that throttles based on certain conditions. I am not entirely sure how it works, as I have not looked into the specifics, but it seems to max out the CPU under some conditions.
I am 100% sure this is placebo effect. Setcpu can't make your phone run hotter just because it's there. If you had a charging profile set for 1113/1113, sure, but that is not setcpu itself. Linux does not control the CPU scaling any further than what ondemand does - there is nothing preventing the CPU from going up to your max during sleep (or rather, when the screen is off), for example, or when your battery is low.
Oh, and using the active widget is a bad idea if you care about battery life. I tried to optimize it as much as possible, but realize that it's updating a lot more things than other apps are (the frequency, the bounds, and two temperature readings) at a relatively fast interval. The home screen does pause a bit while it is updating. That is a fact of life. Longer intervals are essentially useless because the update interval for cpufreq itself is on the order of thousands of microseconds. The current appwidget refreshes if the screen is on, regardless of whether it's visible or not (there is currently no way to tell if it is visible). A live wallpaper would be a much better idea than a constantly updating appwidget, and I'll look into that.
Let me explain this bit better. Cpufreq will scale your CPU between the max and min values automatically. Once the CPU load hits the "up threshold," it takes your CPU frequency from the min to the max, then gradually eases it down. SetCPU lets you easily change the max and min values on the fly. If you want, it can also prevent the system from scaling the CPU up that high during times you don't want it to (with profiles, of course). It does not and cannot interfere with the actual governor.
Click to expand...
Click to collapse
I too am a fan of setcpu, and over the last week I did get curious due to this this thread. I found my battery ran down quite significantly faster without setcpu, maybe because I didn't have my sleep profile of lowest freq min/max, or my battery profile of max 756, or my low battery profiles scaling down my cpu max. Either way, stop bashing the app, it's awesome, and if you had concerns, take them to the dev rather than start a witch hunt in the forums trying to make a posse.
People that report better battery, may not have had setcpu set up correctly in the first place. A friend of mine at work installed it, ran for a day and uninstalled it, citing it didn't do anything and infact drained his battery. He had the widget running, and had upped the minimum cpu freq to 500 and something, max to the 1.13ghx. He didn't run profiles. But as such, he wasn't letting his phone scale down to the lowest freq when it wanted to, and had the widget drain. I got him to set t up as I have mine, and he was blown away with the change.
"My car wont go over 20km/h"
"Are you putting your foot on the accelerator?"
"Whats an accelerator?"
Things have to be used correctly to get the best out of them, and unless someone saying it's far worse than without actually comes in and puts up their values they have it set to, we have no idea why they are having the fault. My experience (I have worked tech call centres for years) is that 99/100 issues people experience are due to not using things as they are set out to be, or just have no idea how to do what they are trying to do. My work mates thing was that he thought all apps would go faster if he increased the minimum freq, so therefore use less battery because the processes are completed faster. In a way it's logical, but the result is that even when nothings running the cpu wont fall below that value, so the battery drained much faster than he expected.
Is there a negative effect of setting the clock speed lower while screen off? Aside from running really labor intensive tasks?
It just seems like a great way to save battery to me. Right?
The only negative is getting the phone to wake up fast enough when you get an inbound call.
The CFS kernel (which is widely used now) seems to be less able to come out of a deep sleep rapidly than the older "zanfur" OC kernel did.
IIRC, on the older "zanfur" OC kernel, you could set the minimum scaling frequency to 19 Mhz - but with with the CFS kernel, you may need to use a minimum value of 122 Mhz or 245 Mhz.
Set the max scaling speed to 480 or 528 when sleeping. (The max frequency is only rarely used when the phone is sleeping - but you want the phone to pop out of it's low speed state quickly when you power up the screen, or experience an inbound call).
Thanks, Yeah I usually set the max to 480 while sleeping and 480 as min while awake. Battery seems good there.
Originally I was using SetCPU but I have switched to CPUBoost. Most all the kernels in the past few roms I have used are made by conap and he is also the creator of CPUBoost, so I figured they would integrate really well.
Also if I enter anything above the 800 range the phone will have random reboots throughout a few different roms I've tried.
As a note, if I remember correctly, if you have a kernel/ROM that supports the smartass governor, you should be able to use it and not need to have a profile set to underclock while the screen is off, or really need to underclock at all, as I believe it determines for you how much CPU is needed and sets the clock speed accordingly, simply abiding by your max and min speeds you set. Since less CPU is needed when the screen is off, it will automatically adjust accordingly. However, this is just something I've read around the forums, so don't take my word for it
Pokelover980 said:
As a note, if I remember correctly, if you have a kernel/ROM that supports the smartass governor, you should be able to use it and not need to have a profile set to underclock while the screen is off, or really need to underclock at all, as I believe it determines for you how much CPU is needed and sets the clock speed accordingly, simply abiding by your max and min speeds you set. Since less CPU is needed when the screen is off, it will automatically adjust accordingly. However, this is just something I've read around the forums, so don't take my word for it
Click to expand...
Click to collapse
Thanks for the info, I didn't know that. I will assume that's more or less accurate unless Conap or bftb0 chime in.
Pokelover980 said:
As a note, if I remember correctly, if you have a kernel/ROM that supports the smartass governor, you should be able to use it and not need to have a profile set to underclock while the screen is off, or really need to underclock at all, as I believe it determines for you how much CPU is needed and sets the clock speed accordingly, simply abiding by your max and min speeds you set. Since less CPU is needed when the screen is off, it will automatically adjust accordingly. However, this is just something I've read around the forums, so don't take my word for it
Click to expand...
Click to collapse
roirraW "edor" ehT said:
Thanks for the info, I didn't know that. I will assume that's more or less accurate unless Conap or bftb0 chime in.
Click to expand...
Click to collapse
Well, I suppose it could be said that the whole point of any rate governor is to reduce overall power consumption without markedly affecting the user's perception of "responsiveness" or "speed" - however they go about defining those metrics.
OTOH, because there are - what - five different scaling governors available, it is apparent that people have found their own reasons to create new scaling governors; presumably that arose from a dissatisfaction with the behavior of the available scaling governor - or, that different users have differing application workloads, and so they prefer one governor over another.
As Pokelover980 suggests, you could just hand a given rate governor a fixed set of limits (min/max), and be done with it.** For folks that have the time and desire to experiment, I would suggest that: pick a governor and a min/max clock rate and run that way for 2-3 days - no profiles at all. Then pick a different governor with the same min/max clock rate and run that way for another 2-3 days, and see how it goes - maybe not in battery life, because that's hard to measure in a repeatable way, but at least to see if any problems occur coming out of sleep.
Is the "smartass" governor better than all the rest of them? I don't really know. I used it for a little while, but found something I didn't like about it. (But don't take that as conclusive about anything; I doubt that I was doing disciplined testing when that happened). I tend to use either "interactive" or "ondemand", and don't have a strong preference for one over the other.
There probably is some value in keeping things simple. I think that I mentioned before that at one point (back when the CFS kernels were still in a state of flux) I was convinced that using setCPU was exacerbating problems with lock-ups I observed (once every couple of days). Again, though - that was really only my suspicion; I can't really prove it.
bftb0
** I suppose that folks that insist on extreme levels of overclocking ought to use either an overtemp profile or some other means to monitor temperature so that they don't cook their phone.
I Installed SetCPU on the wifes Eris. The smartass governor on CM7 will max out the cpu (to your preset max) if needed. I dont think the smartest thing to do is max out the cpu at 15% batt life. I have 5 different profiles set. One for screen off, charging, < 50%, < 30%, <10%. I use interactive governor vs smartass. Her phone is pretty responsive and I dont hear about issues with it not waking up. Battery life has also increased quite a bit.
root rookie here.. First device I ever rooted, really I'm new to cell phones in general.
I flashed this rom adryn bamf 4.1 (non remix) and its working good and all
But I noticed on the smartass setting, which underclocks, that after about an hour or so of playing a game/tv whatever my batter will be around 42C, it seems very hot compared to around 32C before I put this rom and kernal on
Two questions
Am I doing something wrong or is this normal
And, How hot can a battery get before it becomes something to worry about?
Thanks =P
Yea in the 40's is way high. Remember, heat is inefficiency (wasted energy). After playing a game for an hour you will probably be in the mid 30's C. I would recommend trying a different kernel and wiping devlik cache. Also, see what apps and services are running in the background and increase the length of time between syncs. Also, smartass scaling did great on my incredible but I have found that it is not perfected yet for the tb. I would suggest ondemand unless the dev or OP specifically says that smartass is the way to go. As far as heat and battery I find that adrenylyn's kernels do the best. As far as performance, drod and ziggy's seem to fly. Isoman or whatever seems to also be a favorite but I personally didn't have great results. It is important to not supremely OC or UC. I would simply stray away from UC in general. For a daily driver, I would stay under 1.5 Ghz, and honestly 1.2 seems to work best for me. Hope this helps.
thanks for taking the time to respond
So why no under clocking? I assumed it would help battery life but not so much?
Just set to 1200 for both min/max? Or on demand scaling up to 1200?
I prob had a bunch of apps running in the backround, i'm new to droid.. came from an old feature phone
42C is definately too hot! As the previous poster suggested, try a different kernel. There also could be a remote chance your battery is defective.
I really feel like it is more likely that something I am doing is impacting it
I had the phone stock for a week and no problems (same usage)
Rooted but stock rom for a week and no problems
Put this kernal on (which everyone says is really good) and this rom and it was getting hot.. So far it is good around 38-39 (still too high?) with 1200mhz on demand min 256mhz
I flashed 2 different kernals and both times after less than 45 mins of browsing forums and playing home run baseball my battery gets to 42C. Could this be caused by the rom? I wonder if I damaged my battery or phone at this point
Mine got up to 113 degrees over the weekend. It felt like I was cooking my phone off and getting ready to throw it like I do in black ops.
I realized my phone was trying to search for a 4g signal when there was none. I entered #*#*#4636#*#*# on my dial pad to turn it off. It reduced my battery heat by 5 degrees. I should point out I was out in the field. Aka in the middle of nowhere where.
Sent from my rooted Thunderbolt with VirusROM AirborneTB. Xda premium
I'm @ 53.4C right now and it doesn't seem to be charging, lol.
raider3bravo said:
Mine got up to 113 degrees over the weekend. It felt like I was cooking my phone off and getting ready to throw it like I do in black ops.
I realized my phone was trying to search for a 4g signal when there was none. I entered #*#*#4636#*#*# on my dial pad to turn it off. It reduced my battery heat by 5 degrees. I should point out I was out in the field. Aka in the middle of nowhere where.
Sent from my rooted Thunderbolt with VirusROM AirborneTB. Xda premium
Click to expand...
Click to collapse
Sorry but to fly off topic what do you do? I'm generally out in the boondocks when I'm on wellsite...
Sent from my Thunderbolt running CM7...
42c isn't anything out of the ordinary, or outside operational parameters for a battery of that type. Not by a long shot, actually. That battery can safely operate at 59c, but the phone won't charge it north of about 47c due to the fact charging will increase the temperature even more.
As for the governors:
The smartass governor operates similarly to the interactive governor, but isn't as aggressive and allows for wake up lag reduction. The governor SHOULD be your main line of controlling clock speed, not your min and max settings. Some might like to argue that point, but that's mainly because they haven't messed around with governor parameters. With and ondemand or interactive governors, and even some smartass governors (Not Ziggy's modified), it's entirely possible to set min as low as 61MHz, and max at 1.65GHz and have the CPU rarely, if ever, reach those speeds. It depends entirely on what you've set the governor parameters to be. I don't know of any app that allows you to modify those because the locations of the parameters aren't always the same name or in the same places so it's best done through a script. The script I uses does routinely reach up to my freq_max, but it does it fairly aggressively, then ramps down just as aggressively. Part of that is the nature of the lagfree governor, part of it is where I've set the thresholds. In any event, governor control via a script is a much better solution than castrating your device.
Since yesterday my phone has been shutting down randomly whenever the screen turned off. Coincidentally, yesterday I also created a profile to underclock the processor to 200mhz when the screen is off. However I forgot about that and assumed it the random shut downs were a problem with Villain Rom or the kernel I was running so I tried every kernel I could find and change ROM, but to no avail, it kept shutting down.
I just had the thought about SetCPU, removed the underclock and alas, it is fine! no random shut downs at all...
Has anyone else had a problem like this?
Yes, that's likely causing the problem. Why would you underclock to 200mhz in the first place? The benefit (if there is any) is minimal. 200mhz is a to low value for most devices.
If you under volt too much it can have trouble turnibg back on from standby. What voltages you set?
Sent from my GT-I9100 using XDA App
Yeah I didn't realise that, I used to underclock to 200mhz when my screen was turned off on my Desire as to preserve battery life which is why I didn't think it was an issue, clearly the Galaxy does not like it hence random shut downs.
I was running at 1200mhz when battery is between 50 and 100% then at 800mhz <50%.
Removed all profiles now and have just set it as on demand
I remember there was this long debate about ASUS/NVIDIA and how they took away the 107MHz frequency and how it affected battery life..
For the record, on my CPU Spy I have it at 120 hours with 35% at 370MHz and 0% (56 minutes) at 102MHz with the rest in deep sleep and 405 and up to 1300MHz with great battery life.
In any case, there's a discussion in EVO 3D about CPU that might have some bearing on the frequencies and how it affects battery life and why sometimes the lowest one isn't the best for battery life.
Now, of course we know the variances between all the devices posted on here so while a lot of folks might have been fine, some might not, but that seems to be the case for the Prime. Hence we saw posts from folks saying they were fine with battery when it was at a min of 370MHz while some had worse.
Also, the Prime does use a different CPU than the EVO 3D so that could be taken into account as well
Anyways, good read for those interested
-----
From http://forum.xda-developers.com/showpost.php?p=23384703&postcount=2110
Thanks for the feedback. I do appreciate it, but by the looks of your post, you didn't see my detailed description of why the frequencies are set to what they are now. I was more interested in what people are actually experiencing as far as performance and battery in real world tests and conditions. From your post, the information that I believe is relevant is that you think your phone runs fine at 192Mhz. I'll accept that for what it is (a data point) but I already know from experience that you are in the minority here. As soon as I released v1.1 with the 192Mhz min frequency, I immediately started getting inundated with people complaining that battery life was much worse, and the phone lagged more on occasion. Then when I brought the frequency back up to 384Mhz, the vast majority reported "thank you, battery life is back to phenomenal and lag is gone". Well, that's what got me on my quest to actually find and measure the needed frequencies.
No, neither HTC nor Qualcomm set these devices up to work as well as they actually can. They simply do not have the resources and the time. These things are rushed to market and updates are no better: they are designed to "make the device work". That's about it! So when I actually started testing these things, I found that 192Mhz was far too slow to make this phone work without lag. 384 fixed the problem but when I looked into it further, 486 worked even better, and without extra battery drain. I didn't pull these numbers out of a hat nor did I increase them for bragging rights. They are measured values of what the phone actually needs in order to keep up! I spent many hours testing different states, what frequencies are needed when the CPU wakes up when the screen is off, etc. Simply put, 192 doesn't cut it (not even close) and 384 doesn't quite cut it either. When you crunch the numbers, you find that the phone actually needed 432Mhz while running one core with the screen off and 540Mhz while running dual core with the screen on. Lowering those numbers caused the CPU to jump relentlessly between the min/max numbers and when you look at the time and crunch the numbers, it was always shooting for those figures: 432 with screen off and 540 with screen on!
In other words, if you crank it down to even 384Mhz while the screen is on and IDLING (not even running any games or other apps: what you called "waiting for input"), it'll hop up to 1188 much more frequently and in fact, crunch the numbers for the amount of time it spent at 384 and 1188 and get an average and you'll find that on average, the CPU was using about 540Mhz of power with the screen on and about 432Mhz with the screen off. I will add a disclaimer here that yours may be slightly different (up or down one notch in the time table) from the 432-off/540-on numbers, but I did test a variety of configurations as I said in my description when I released 2.0 and 432/540 minimum frequencies were the good middle ground that worked well under all setups from clean install to heavily loaded down. Part of the need for higher minimum frequencies is because with the screen off, there's an initial "crunch" when the CPU is awakened and that often requires more CPU power than when a longer task is being performed. And with the screen on, it is always doing more than just waiting for input from you! There's a lot more going on in there than you think. Even bumping the min screen-on frequency from 384 to 486Mhz caused a dozen posts saying "Wow, lag is completely gone" and "apps seem to open before I even touch the screen". This is not placebo. This is noticeable and even measurable in benchmarks! No, the phone CANNOT and will not instantly crank up to 1188 Mhz from 192 (or 384). I've proven this many times. It doesn't work that way.
You have to remember that the decision to ramp up to 1188 is made at 192Mhz! It only measures CPU load 20 times per second. And it will never be able to ramp up to 1188 in 1/20 second! The reason is that by the time the service reports a high CPU load (high enough to trip the up-frequency), you've already experienced 1/20 second lag minimum. At that point, it takes at least one more cycle to actually increase CPU frequency at which point you've experienced at least 1/10 second of lag. That is almost always noticeable. To complicate matters, if you look at the code for the daemon, you'll notice that it is a "nice" process which means other high priority system processes can actually "steal" time from the daemon and that can actually greatly increase the amount of time it takes for the daemon to actually raise CPU frequency once it notices the phone is lagging. By that time, you've already noticed additional wait to open an app, a "hiccup" while scrolling, etc. The reality is, your phone can lag at 192Mhz (or 384) for several 1/20 second cycles before the CPU is actually ramped up to the full 1188 and THAT is what causes the lag.
So long story short (I know, too late now) I have to discount all your questioning about whether or not I got the numbers right because your assumptions about the numbers are quite frankly all dead wrong! Your scale of the numbers in your car analogy doesn't fit either. I actually do performance tuning on (among other setups) Hemis. The analogy is more like: set your idle to 192 RPM and see if you can keep it running. If it does, it'll be loping like hell and then when you hit the gas, what happens? It bogs. It's because the system wasn't ready for the load. Set it to 540RPM and see how much better it responds. That's a better analogy here.
So I'm really interested in actual results more than people pulling their own numbers out of a hat and saying "these make more sense to me". A lot of testing went into the CPU tweaks in this ROM and I'm aware of "theories" about how people think 192 might be better or 384 is better. Been there done that. That was the boardroom stage... kinda where HTC and Qualcomm left it. We're already out on the track racing and making adjustments.
Oh, and the frequencies are no more "locked" now than they've ever been. I intentionally set up the init.post_boot.sh so that they can easily be changed. So if you want to run yours at the laggier, less efficient 192Mhz, the choice is yours. Just follow Lrod's instructions above. I was going to post those but he did a fine job.
Edit: I also notice you said at one point "So I don't understand why the decision was made in v2.0 to raise the minimum frequencies to 432mhz for core0 and 540mhz for core1.". CPU0 is never run at a different minimum frequency than CPU1. The numbers for min/max are:
- Screen off: CPU0 = 432/648, CPU1 = offline
- Screen on: CPU0 = 540/1188, CPU1 = 540/1188
And again, these numbers came from actual measurements and number crunching. Didn't matter what you used for minimum frequency: you could set it to 192 and run the phone for a day, and then set it to 384 and run the phone for a day. What you'd find is that regardless of what you picked, the CPU was always "hunting" for about 432Mhz with the screen off and about 540Mhz with the screen on. And with screen on, I mean the screen forced on but the phone doing nothing but idling on the home screen. The CPU was doing nothing but typical background tasks with an occasional email or SMS message coming in and maybe a stray screen scrolling thrown in infrequently.
Mike