I had uberkernel and govnah, but wasn't loving performance so I switched back to Unixpsycho's 800 Mhz ipk (so easy to install) and it's soooo easy! Buy this sounds too sweet to pass on.

@unixpsycho: how do I uninstall your 800 ipk kernel? Preware? And then I install F102 through webos qi? Sorry if answered before, this thread is getting too long to check every post. Do I need Govnah too? Or can I do just F102?

tia, gonna have to donate to you... Again. I am/was huge fan of your 800 ipk

I had uberkernel and govnah, but wasn't loving performance so I switched back to Unixpsycho's 800 Mhz ipk (so easy to install) and it's soooo easy! Buy this sounds too sweet to pass on.

@unixpsycho: how do I uninstall your 800 ipk kernel? Preware? And then I install F102 through webos qi? Sorry if answered before, this thread is getting too long to check every post. Do I need Govnah too? Or can I do just F102?

tia, gonna have to donate to you... Again. I am/was huge fan of your 800 ipk

I love the "horsepower" of F104 w/o Govnah at 800MHz and I had high hopes for efficient operation during screensleep at 125MHz. I have even been surprised that radio applications operate just fine at 125MHz following some mysterious system adjustment that takes a day to become stable. However, three nights and a day of screensleep testing reveal excessive battery drain of 10%/hr. How can it be that a slower clock speed uses so much more juice than with the earlier 500-800Mhz kernal (1.4.5.1)?

So I instaled F104 and everything seems to be great with one ecception. Every tine I restart, the governor resets to 125/800 and seems to stay stuck at 125. The UI remains imposssibly slow until I change to userspace 500 (i installed F104 because I want the memory optimizations without overclocking). Is there any way to prevent this/default to userspace 500? Also is anyone else having this problem?

Are you using Govnah? If so, are you using the latest version that offers "sticky" profiles that remain after a clean restart?

I love the "horsepower" of F104 w/o Govnah at 800MHz and I had high hopes for efficient operation during screensleep at 125MHz. I have even been surprised that radio applications operate just fine at 125MHz following some mysterious system adjustment that takes a day to become stable. However, three nights and a day of screensleep testing reveal excessive battery drain of 10%/hr. How can it be that a slower clock speed uses so much more juice than with the earlier 500-800Mhz kernal (1.4.5.1)?

If I'm not using the phone (standby mode) I measure battery drain of 1.5-2% per hour. The lowest standby battery drain I measured was with 1.5.0 of 0.89% per hour. I've installed some programs since I updated the kernel to F104 that may increase battery drain slightly by checking for other services more frequently, but still don't have any excessive battery drain.

My biggest test case now is trying to see if there's actually any battery savings by setting the screen off <500.

Every tine I restart, the governor resets to 125/800 and seems to stay stuck at 125.

I am having this problem also. Exactly as described. When in the "stuck" state, I can put it in any screenstate mode, and it always chooses the min frequency I set. So, for example, if I set: screenstate 500/800, it'll get stuck at 500MHz. It's as if the governor, for some reason, can't correctly assess the screen's state and is stuck thinking that it's off.

In addition, after a reboot F104 has a difficult time connecting to wifi. I typically leave wifi on when I'm at home (thank you QST). So when I reboot, wifi is on and working. But after the reboot, wifi will be on, but not connected to my AP. If I turn off wifi then turn it back on, it will connect. But not automatically after a reboot.

I've gone back to UberKernel because of these two issues. And the screenstate governor in that kernel seems to work just fine. I think I will try F102 to see if that also exhibits the problem.

Update: F102 does not seem to exhibit either of these problems.

Originally Posted by Xanadu73

Then make sure your screen brightness is >=20%

Does the brightness have to be >= 20% for the screenstate governor to recognize that the screen is on? It doesn't have to in UberKernel, where my default screen brightness of 5% is sufficient to trip screenstate up to 800MHz. Maybe I need to try F104 w/a brightness >20%?

However, three nights and a day of screensleep testing reveal excessive battery drain of 10%/hr. How can it be that a slower clock speed uses so much more juice than with the earlier 500-800Mhz kernal (1.4.5.1)?

It would depend on how much your phone is doing for you while it's screen is off. If it's doing a lot of background applications, then it could be pretty significant. There's a concept called "Race to Idle". The basic idea is that idle takes very little power no matter what frequency the CPU is set at. And if you can get back to idle quickly, you're better off even if it uses more power at the higher frequency than the lower one. The longer time at the lower frequency actually consumes more power than the shorter time at the higher frequency.

This takes on even more significance when you consider applications using a network, which consumes more power. If you do a network operation (especially an EVDO operation) at 125MHz and spend far too long doing it, you're not just consuming CPU cycles, you're forcing your phone to keep the power hungry network operation active longer.

If you can get your background apps down to basically no functioning while the screen is off then I'd expect your drain per hour to drop quite a bit. For testing purposes, I'd disconnect from all synergy based services. I'd disable notifications in any twitter app I had, and facebook. If, after doing that, you're dph% drops, then it's a pretty good indicator that race to idle type stuff is going on here.

Has anyone experienced any temporarily-non-responsive keyboard issues after installing this?

I'm loving this kernel (F102), but keep running into times when my keyboard won't register presses for 10-15s, in various apps. I'm not sure if it's related to this or if maybe another patch or hardware problem (dropped my phone 4 days ago :/).

Weird, mine is completely unpatched, just preware and some apps, and I also have those little hangs, it responds again after a few seconds tho

My biggest test case now is trying to see if there's actually any battery savings by setting the screen off <500.

Thanks for your reply. Comparison testing of individual phones to determine if battery life is enhanced by sub 500MHz settings asseses the essence of slow clocking having already established its functionality. Your experience with UK fails to address questions about the F104 kernel that I suspect is responsible for excessive consumption. Nevertheless, and I am eager to see your comparative test results.

On my phone, other 500-800MHz kernals have yielded sub 3% drain in screenoff. Meanwhile, I have been reviewing the excellant battery life suggestions in the General Pre forum.

Last edited by RRaburn; 06/13/2010 at 12:54 PM.
Reason: add bracket for quote

I love the "horsepower" of F104 w/o Govnah at 800MHz and I had high hopes for efficient operation during screensleep at 125MHz. I have even been surprised that radio applications operate just fine at 125MHz following some mysterious system adjustment that takes a day to become stable. However, three nights and a day of screensleep testing reveal excessive battery drain of 10%/hr. How can it be that a slower clock speed uses so much more juice than with the earlier 500-800Mhz kernal (1.4.5.1)?

This is actually the only reason I would switch back to UberKernel... I get excessive battery drain when using my phone (and even when I am not using it, but I have several background programs running). I am even using the Userspace 500min/600max set at 500 governor (not overclocking)

I just thought I'd check in after having used F102 for however long it's been since you released it.

"Smooth" comes to mind. It's just as "fast" as your previous releases, but, this feels smoother for whatever reason. Cards don't "jump" like they did, they "glide".

The battery life isn't *as* minimal as it was with the the Kernel That Shall Not Be Mentioned. Since then I get idle drains >2% but <3%.

Actually *using* the phone plows through battery. Like actually loading apps, page renders, and what not. Maybe my /media/internal needs to be checked for FS errors. I get that a lot for whatever reason. I added the "flush" mount option to my fstab, but it hasn't seemed to help much.

The Camera works and doesn't hang like it used to. *But*, putting it into a card, then bring it back to focus causes it to sit gray for (up to) 10 seconds. Video hangs sometimes while recording.
I took killing some time at my super fun job this past week. You can see how often it stutters, pauses, and even flat-out skips. I don't know if this is "normal" or not as I rarely actually use it to record video. Don't know if it's a kernel thing or maybe my vfat partition. I dunno.

TMC: never see 'em! I have opened 20, yes twozero, apps including camera, several web pages (hefty ones like three cards of slashdot), and a few games. I don't have any 3D games installed, so I'll leave that to others.

All things said, this is your best release yet. Personally when the day comes that all these kernels *require* Govnah to keep them at 500/800, is the day I start figuring out how to do all this myself, because I have found that having them "stock locked" at 500/800 gives the best performance and least battery drain. Telling the kernel to do it isn't the same. I don't know why that is, and it makes no sense that I can duplicate it over and over (I had a short thread on that I think you saw).