[ROM+Kernel] Inferior Human Organs unofficial CM7.1

[Dannemand]

Part of what you say here does indeed conflict with what LeslieAnn says. She says that our processor doesn't support 122MHz, but you seem to imply that it does.

So who's right here?

It was around a year ago, but I believe it was Zefie (the guy who did all of the Xionia kernels, recoveries and a few roms), who determined that 122 was not actually working.

I'll take his word over most anyone regarding the processor speeds, he knows this and the Optimus S like the back of his hand.

OK, it looks like more clarification is needed:

1) I've never used 122 MHz myself, let alone advocated it (and I still don't). But since CPU Spy reports my phone spending time at that speed (Smartassv2 uses the full register of speeds as it ramps up from idle, even speeds below the Min setting) I've always assumed it to be a supported speed.

2) After seeing Whyzor's post, I decided to make some tests this afternoon, playing Pandora in my car while running some errands. There was a dramatic difference from 480 (my normal Min setting) down to 122: At 480 Pandora ran fluently, at 320 it sputtered a bit, at 245 it sputtered a lot, at 122 there is only a few cracks and pops and the UI becomes very unresponsive. I then decided to test Interactive governor as Whyzor recommended. Still at 122 Min, it basically caused the phone to lock up when trying to play Pandora. With screen on, the UI would suck all CPU. But even with screen off, it was almost completely dead. I had to pull the battery eventually as it didn't have enough CPU left to navigate away from Pandora. InteractiveX and OnDemand (the stock governor) were similar. Smartassv2 seemed to deal better with the low speed, as it ramps up based on CPU demand, whereas Interactive depends more on user action (Screen on) to ramp up.

3) Tonight (after seeing the responses to my last post ) I did some more scientific tests, running benchmarks at each speed. I disabled Screen timeout (to prevent idling) and used the Powersave governor to lock CPU speed at the Min setting. I verified with CPU Spy after each test to see that it did indeed lock and test at that CPU speed and no other speeds were in play. I used Raw CPU MFLOPS in StabilityTest 2.4.

Results:
122MHz=1.7 MFLOPS
245MHz=4.1 MFLOPS
320MHz=4.1 MFLOPS
480MHz=5.9 MFLOPS
600MHz=10.0 MFLOPS
729MHz=12.2 MFLOPS
748MHz=12.6 MFLOPS
768MHz=13.0 MFLOPS

The dramatic jump in score from 122 to 245 is surprising. Possibly other CPU or chipset functions get throttled at that setting to save battery, but I think at this low speed the waiticon and background processes consume a significant percentage of CPU cycles during the test. Even more surprising is that 245 and 320 yielded the same score, for which I have no explanation. I re-ran the tests multiple times to verify.

4) My conclusion remains that all of the speeds available in the menu are supported -- including 122, 245 and 320. Again, CPU Spy validates that. I don't know how Zefie arrived at his claim, but nothing in my tests indicate otherwise.

5) That said, I still consider 122 to be useless for my purposes ? though it may serve a purpose if you only have minor CPU limited processes running during Screen off. At 122 there is barely enough CPU to run the UI (certainly not with animations enabled).

6) As I wrote earlier, the goal is to have the phone enter deep sleep as much as possible during Screen off, only waking up briefly to receive email notications. As long as these tasks are CPU limited, it makes sense to have a higher Min setting, such as 480. The faster the CPU runs, the faster the tasks complete and the phone can go back to sleep.

7) Mmarz' famous tests from last spring/summer concluded that up to a certain point higher clock speeds yield higher "battery efficiency". (He spliced a multimeter in between the battery and his OV to measure total draw while completing certain tasks). But (as I believe he later acknowledged) this does not take into consideration that some tasks are time limited (reading a web page, listening to a symphony etc) and you want the processor to run as slowly as possible during this time ? only fast enough to support the task. That's why you choose Min setting based on your needs. Use CPU Spy to check it as I described in earlier posts.

OK, I hope this time at least I clarified more than I confused :-\

 

[flapjack.fiasco]

OK, it looks like more clarification is needed:

1) I've never used 122 MHz myself, let alone advocated it (and I still don't). But since CPU Spy reports my phone spending time at that speed (Smartassv2 uses the full register of speeds as it ramps up from idle, even speeds below the Min setting) I've always assumed it to be a supported speed.

2) After seeing Whyzor's post, I decided to make some tests this afternoon, playing Pandora in my car while running some errands. There was a dramatic difference from 480 (my normal Min setting) down to 122: At 480 Pandora ran fluently, at 320 it sputtered a bit, at 245 it sputtered a lot, at 122 there is only a few cracks and pops and the UI becomes very unresponsive. I then decided to test Interactive governor as Whyzor recommended. Still at 122 Min, it basically caused the phone to lock up when trying to play Pandora. With screen on, the UI would suck all CPU. But even with screen off, it was almost completely dead. I had to pull the battery eventually as it didn't have enough CPU left to navigate away from Pandora. InteractiveX and OnDemand (the stock governor) were similar. Smartassv2 seemed to deal better with the low speed, as it ramps up based on CPU demand, whereas Interactive depends more on user action (Screen on) to ramp up.

3) Tonight (after seeing the responses to my last post ) I did some more scientific tests, running benchmarks at each speed. I disabled Screen timeout (to prevent idling) and used the Powersave governor to lock CPU speed at the Min setting. I verified with CPU Spy after each test to see that it did indeed lock and test at that CPU speed and no other speeds were in play. I used Raw CPU MFLOPS in StabilityTest 2.4.

Results:
122MHz=1.7 MFLOPS
245MHz=4.1 MFLOPS
320MHz=4.1 MFLOPS
480MHz=5.9 MFLOPS
600MHz=10.0 MFLOPS
729MHz=12.2 MFLOPS
748MHz=12.6 MFLOPS
768MHz=13.0 MFLOPS

The dramatic jump in score from 122 to 245 is surprising. Possibly other CPU or chipset functions get throttled at that setting to save battery, but I think at this low speed the waiticon and background processes consume a significant percentage of CPU cycles during the test. Even more surprising is that 245 and 320 yielded the same score, for which I have no explanation. I re-ran the tests multiple times to verify.

4) My conclusion remains that all of the speeds available in the menu are supported -- including 122, 245 and 320. Again, CPU Spy validates that. I don't know how Zefie arrived at his claim, but nothing in my tests indicate otherwise.

5) That said, I still consider 122 to be useless for my purposes – though it may serve a purpose if you only have minor CPU limited processes running during Screen off. At 122 there is barely enough CPU to run the UI (certainly not with animations enabled).

6) As I wrote earlier, the goal is to have the phone enter deep sleep as much as possible during Screen off, only waking up briefly to receive email notications. As long as these tasks are CPU limited, it makes sense to have a higher Min setting, such as 480. The faster the CPU runs, the faster the tasks complete and the phone can go back to sleep.

7) Mmarz' famous tests from last spring/summer concluded that up to a certain point higher clock speeds yield higher "battery efficiency". (He spliced a multimeter in between the battery and his OV to measure total draw while completing certain tasks). But (as I believe he later acknowledged) this does not take into consideration that some tasks are time limited (reading a web page, listening to a symphony etc) and you want the processor to run as slowly as possible during this time – only fast enough to support the task. That's why you choose Min setting based on your needs. Use CPU Spy to check it as I described in earlier posts.

OK, I hope this time at least I clarified more than I confused :-\

That is exactly the sort of clarification we need. Thank you for taking the time!

Sent from my LG-VM670 using Tapatalk

 

[CuriousNoob]

Looool! Good luck getting Leslieann to believe

Sent from my LG-VM670 using Tapatalk 2 Beta-4

 

[JerryScript]

LOL, you guys sometimes crack me up.

Anyone try any extensive testing while in Suspend Mode while running BACKside 0313?

 

[CuriousNoob]

I tried it out for 6 hours in school


I'm pretty sure I would have had better battery life on my old Optimus, but this one sucks. I lost 23% battery.

Sent from my LG-VM670 using Tapatalk 2 Beta-4

 

[LeslieAnn]

OK, it looks like more clarification is needed:

Awesome work, thanks!

Looool! Good luck getting Leslieann to believe

Why?
No one has shown any proof contrary, now we have it. If I'm going to just take someone's word, I'm going to take the "authority" until shown evidence to the contrary.

While Dannemand proved 122 does exist, he also pretty much showed it may as well not as far as using it is concerned.

 

[JerryScript]

Perhaps 122 didn't exist on the stock kernel, and wasn't built into zefie's, but is being used in newer kernels?

I don't work on the kernel, I leave that to those in the IHO team with the experience to do it right. Teamwork is what made IHO what it is today.

 

[Dannemand]

Actually my point wasn't so much to prove the existence of 122 or have a debate, but more to help people overclock their phones right. There is so much misunderstanding and so many myths about it.

I just saw LeslieAnn's new thread out on the same mission - it should be stickied!

 

[LeslieAnn]

Perhaps 122 didn't exist on the stock kernel, and wasn't built into zefie's, but is being used in newer kernels?

I don't work on the kernel, I leave that to those in the IHO team with the experience to do it right. Teamwork is what made IHO what it is today.

Most of the original overclock kernels were actually OS kernels, so it's probable that that speed just wasn't included in it.

 

[Whyzor]

I just ran a couple of tests, set CPU to interactive governor 122-864, played a mp3 in the background using default music player. In cpu spy, reset counter, waited a few minutes, refreshed counter. 90%+ of the time was at 122 Mhz.

Retested this again using Pandora over 3G. After about 5 minutes, 48% at 864 Mhz, 38% at 245 Mhz, 14% at 122 Mhz. This shows that interactive is doing its job of ramping down when the load is low, no stutters or any problems. Pandora seems to have less efficient software algorithms when playing music, so uses more CPU cycles (maybe due to its DRM bloat, & ads service running too).

Some of the newer "fancier" sounding governors just have a preference for higher CPU ranges, so it's noticeable in response compared to the default ondemand, but to prove it's more battery efficient takes a lot more work.

 

[Eollie]

There seems to be a trend here that has been proven in the past and people are forgetting about it. Each phone is different. Look at noobs new phone, then Dane and Whyzor's phone results. Dane makes a very important statement, his guide was to help people properly overclock the phone. So many different opinions and suggestions without anything to back it up.

The key is to test until you find the combo that works for YOU! I always suggested trying 480/767 because that is where MY phone was the most stable. I could go higher but things would stop working properly. Those two values always seemed to be a good start point. If people wanted to go lower they could.

I cant remember where it is posted but blarf explained the governor and clock speeds real well. He also showed where going lower than 480 really is a placebo effect in battery life. Since our phone cant be undervolted underclocking isnt as beneficial as it is suppose to be. That is why he said stick around 480.

 

[Dannemand]

There seems to be a trend here that has been proven in the past and people are forgetting about it. Each phone is different. Look at noobs new phone, then Dane and Whyzor's phone results. Dane makes a very important statement, his guide was to help people properly overclock the phone. So many different opinions and suggestions without anything to back it up.

The key is to test until you find the combo that works for YOU! I always suggested trying 480/767 because that is where MY phone was the most stable. I could go higher but things would stop working properly. Those two values always seemed to be a good start point. If people wanted to go lower they could.

I cant remember where it is posted but blarf explained the governor and clock speeds real well. He also showed where going lower than 480 really is a placebo effect in battery life. Since our phone cant be undervolted underclocking isnt as beneficial as it is suppose to be. That is why he said stick around 480.

I think Eollie nails it: My main point has been that there are a lot of myths in the area of over/underclocking, partly due to lack of understanding (there is so much info to read), which leads to this pursuit of "the one perfect setting". There is no such thing, both because each phone's hardware is different, but also because we all use our phones in different ways.

So ideally, people need to go through this process that I've tried to lay out (and LeslieAnn even more so in her new thread) to determine the right settings for them.

The classic recommendation of Min=480, Max=two notches down from stable is a great starting point. Or a great default for those who (understandably) don't want to do this work -- although it still requires some work to determine Max. There is nothing wrong with simply sticking to that -- it's what I've argued myself.

But then over time I saw how this developed into myths like "480 is the best Min setting, it's what the Devs recommend". And that's where the train leaves the track. It's the best settings for those who don't want to dig further into it, but don't defend it like some gospel.

Something else I want to add: I've noticed some people seemed to take to my my recent postings as if I offended them or challenged established authority. That has not been my intention, and I apologize if it came across as such. I am not native English, and maybe not always perfectly clear in my writings.

Very specifically, there is hardly anything that I've observed or written that contradicts with what I've seen LeslieAnn say (other than the existence of 122, which is not significant in itself, and probably just due to newer kernels since Zefie's days). On the contrary, ever since I started following this forum a year ago, I've found LeslieAnn's writings on the subject to be islands of fact and reason in a sea of noise. Having built overclocked PCs myself for almost 20 years, I recognized instantly that she knew what she is talking about. And indeed, I have seen nothing in her responses to my recent postings that indicate that we're on different pages. So please don't try to put us there. I'm gonna have to repeat some of this in LeslieAnn's OC thread.

Thanks for listening.

 

[Dannemand]

I just ran a couple of tests, set CPU to interactive governor 122-864, played a mp3 in the background using default music player. In cpu spy, reset counter, waited a few minutes, refreshed counter. 90%+ of the time was at 122 Mhz.

Retested this again using Pandora over 3G. After about 5 minutes, 48% at 864 Mhz, 38% at 245 Mhz, 14% at 122 Mhz. This shows that interactive is doing its job of ramping down when the load is low, no stutters or any problems. Pandora seems to have less efficient software algorithms when playing music, so uses more CPU cycles (maybe due to its DRM bloat, & ads service running too).

Some of the newer "fancier" sounding governors just have a preference for higher CPU ranges, so it's noticeable in response compared to the default ondemand, but to prove it's more battery efficient takes a lot more work.

Wow, very different results, thanks for posting! One thing is certain, streaming music is far more demanding than playing off the SD card. Things that clearly affected my Pandora tests:

1) I use the high bitrate setting in Pandora.
2) My phone has a weak radio (always had, haven't had the courage to try the ZV9 update yet)
3) VM coverage is mediocre in my area -- not terrible though.

That was why I made the Raw CPU tests, because I wanted to see what 122 can do versus the higher speeds without involving the radio.

In my case I found that Interactive governor was more dependent on Screen On activity to ramp up than Smartassv2. In the case of Pandora, Interactive simply didn't ramp up when the screen was off, and I almost couldn't get my phone back.

Thanks again. Shows how different these phones are. I wish mine could do 864

Edit: I forgot, I think the main reason Pandora is more demanding is not just the bloat (though that too) but that they probably use newer encodes which compress more efficiently and take more CPU cycles to decode. MP3 is the oldest and least demanding of all music codecs. Of course receiving data over 3G also takes some CPU cycles.

 

[mrg666]

I just ran a couple of tests, set CPU to interactive governor 122-864, played a mp3 in the background using default music player. In cpu spy, reset counter, waited a few minutes, refreshed counter. 90%+ of the time was at 122 Mhz.

Retested this again using Pandora over 3G. After about 5 minutes, 48% at 864 Mhz, 38% at 245 Mhz, 14% at 122 Mhz. This shows that interactive is doing its job of ramping down when the load is low, no stutters or any problems. Pandora seems to have less efficient software algorithms when playing music, so uses more CPU cycles (maybe due to its DRM bloat, & ads service running too).

Some of the newer "fancier" sounding governors just have a preference for higher CPU ranges, so it's noticeable in response compared to the default ondemand, but to prove it's more battery efficient takes a lot more work.

I will throw some more data in this useful discussion. Using interactive governor, when I set my CPU speed 320-806, battery use is 2.5-3.0 percent/hr. For 122-806, I get 1.5-2.0 percent/hr with about the same usage pattern. Except bluetooth, everything is turned on and screen brightness is at 50%. I did not see any disadvantage of 122 minimum clock, other than a little (very slight) lag occasionally.

Edit: Kernel is BobZhome v3.7 and ROM is MiRaGe, 03242012 build.

 

[LeslieAnn]

I
Something else I want to add: I've noticed some people seemed to take to my my recent postings as if I offended them or challenged established authority. That has not been my intention, and I apologize if it came across as such. I am not native English, and maybe not always perfectly clear in my writings.

Very specifically, there is hardly anything that I've observed or written that contradicts with what I've seen LeslieAnn say (other than the existence of 122, which is not significant in itself, and probably just due to newer kernels since Zefie's days).

While I agree with what you and others have said, I want to focus on this part.
As devs, at times we may come off as short, which can sound confrontational and that really isn't the case. Look at the length of some of my posts (and how many), they are very wordy, and if I try and and pass on everything I need to say in a single post in a casual way, it would often come out as a massive wall of text that no one reads. Many times we just post what we need and move on and that comes across wrong.

Text unfortunately doesn't always convey context well, so what was meant as a a friendly "hey, that's not right" makes some people think you are saying "Hey idiot, you're F'ing wrong!". Try to keep an open mind when you read text because you may get the context wrong. I didn't take offense to any of it, but I did worry that it would lead to people picking apart everything I had said or start a massive argument. I'm glad to see it hasn't turned into an argument and seems actually to be more about picking through the finer details, which is good.

As for disrupting the established authority, I didn't see it that way. I'm more interested in facts and evidence than I am with pride and authority. If someone wants to upstage me, they are welcome to, I'm not competitive like that (opinionated, OH YES, but competitive, no). My goal was to reduce the bad information people were spreading and while I may have spread a bit myself in the process, I think it's minor compared to the information that it corrected and I have the impression most here seem to agree with that assessment.

I don't think anyone here was trying to tear me down, just try and work out the finer details of it all, which I think is good.

And if anyone feels I was being a witch (or worse) to them because of being short, I do apologize, as it wasn't intentional. I suspect most of the devs feel the same way.

 

[mrg666]

LeslieAnn, you are always very helpful and modest. I just checked to be sure; you are top-thanked again today in this forum. Did you just apologize for this?

 

[Dannemand]

LOL, thanks LeslieAnn. You know, I wasn't even thinking of you when I said I'd sensed some resentment. You were on the ball right away focusing on the facts. That's why I specifically pointed that out in my last post.

As mrg666 said, you're always very helpful.

And yes, nuances often get lost in translation - even more so in writing with Swype and auto correct

I did some more tests today following mrg666's and Whyzor's latest. It'll have to wait till tomorrow before I can post it though - need my PC.

 

[CuriousNoob]

You're running backside?

Sent via the Postal Service

Any rom I use. My phone can't even handle Harmonia OR Bumblebee.

Sent from my VM670 using Tapatalk 2 Beta-4

 

[clodfelterac]

@ curiousnoob-- I'd just send the piece back to vm and grab one off eBay in the meantime... I know there's two of them for around $80 each... both in good working order... one has a scratchy screen... perfect for a tester...

 

[apraphaelsd]

Not sure why it would boot loop on you I recommend you ensure you wipe the cache and dalvik-cache then wipe data/factory reset. It could have just been a bad flash... I have had weird things happen before as well, and performing the install corrected it.

It is highly recommended to use the IHO Recovery found at https://github.com/inferiorhumanorgans/android_device_lge_thunderc/wiki/Binary when flashing IHO ROM's. I have even had issues with the regular ClockworkMod...

Sent from my LG Optimus-V using Tapatalk

Go to your recovery menu (if using Xionia) then scroll down to advanced, then select fix boot loop. It fixed mine the first time.