Page 61 of 145 FirstFirst ... 1151565758596061626364656671111 ... LastLast
Results 1,201 to 1,220 of 2889
Like Tree17Likes
  1.    #1201  
    Quote Originally Posted by quini View Post
    The team is going to release a 1.4.2 based Uberkernel as soon as the sources get released... in the meantime, you can still use screenstate 500/600. That means +20% CPU power when the screen is on
    I think you might be mistakenly referring to 1.4.5 ...

    -- Rod
  2. #1202  
    I have upgraded to webos 1.4.5 from 1.4.1 without uninstalling any patch, nor the uber kernel (I really wanted to uninstall everything before upgrading, but my Pre did it on its own as I left it unattended - I'm not sure how this happenned, but it's not the point now).

    I had some initial problems with some patches that would not uninstall. I could not also run EPR from webosqui. Finally, I run the Emergency Patch Recovery in Preware and everything seems to be ok now. The only problem I have is when trying to install the uber kernel in Preware. It says that the pacakage is not currently available for webos 1.4.5 and that it will only install a placeholder that will notify when an update is available.

    Previous to the upgrade I had uber kernel and govnah running perfectly.

    Any ideas?

    I have an Spanish Palm Pre with Movistar.
  3. #1203  
    Quote Originally Posted by naiki View Post
    The only problem I have is when trying to install the uber kernel in Preware. It says that the pacakage is not currently available for webos 1.4.5 and that it will only install a placeholder that will notify when an update is available.

    Previous to the upgrade I had uber kernel and govnah running perfectly.

    Any ideas?
    As Rod has already said (in this thread even), it's because the UberKernel for 1.4.5 is still undergoing testing and is not available in the main repository.

    EDIT: Actually, I got it slightly wrong, sorry. UberKernel for 1.4.5 can't even be tested yet because we're still waiting for Palm to release the sources for 1.4.5 version. This is what Rod had said just one page before (emphasis added by me):
    Quote Originally Posted by rwhitby View Post
    The real one will be available within 24 hours of Palm releasing the 1.4.5 kernel source code on opensource.palm.com ...

    A temporary 1.4.1 kernel repackaged to instal on 1.4.5 is in the testing feed. I'm waiting for reports from alpha testers.

    -- Rod
    Last edited by domicius; 07/06/2010 at 10:41 PM.
    Want to get the best Android Apps on your webOS device? Tell HP we need OpenMobile ACL!
    Sign the petition today at http://www.ipetitions.com/petition/a...apps-on-webos/
  4. #1204  
    Quote Originally Posted by naiki View Post
    I have upgraded to webos 1.4.5 from 1.4.1 without uninstalling any patch, nor the uber kernel (I really wanted to uninstall everything before upgrading, but my Pre did it on its own as I left it unattended - I'm not sure how this happenned, but it's not the point now).

    I had some initial problems with some patches that would not uninstall. I could not also run EPR from webosqui. Finally, I run the Emergency Patch Recovery in Preware and everything seems to be ok now. The only problem I have is when trying to install the uber kernel in Preware. It says that the pacakage is not currently available for webos 1.4.5 and that it will only install a placeholder that will notify when an update is available.

    Previous to the upgrade I had uber kernel and govnah running perfectly.

    Any ideas?
    That's what it's supposed to do. In case you're not familiar, read here: http://forums.precentral.net/webos-p...echnology.html
    "Patience, use the force, think." Obi-Wan


    Ready to try Preware? Get this first: Preware Homebrew Documentation
  5. #1205  
    Quote Originally Posted by domicius View Post
    As Rod has already said (in this thread even), it's because the UberKernel for 1.4.5 is still undergoing testing and is not available in the main repository.

    EDIT: Actually, I got it slightly wrong, sorry. UberKernel for 1.4.5 can't even be tested yet because we're still waiting for Palm to release the sources for 1.4.5 version. This is what Rod had said just one page before (emphasis added by me):
    Sh.....t, Promise I did some reading and searching before posting, but obviously I missed that (just in the page before!!).

    Thank you for pointing me out.
  6. #1206  
    Quote Originally Posted by naiki View Post
    Thank you for pointing me out.
    You're welcome. I know it can sometimes get overwhelming following everything on this forum, but for important webos-internals news I'd recommend following webOS Internals (webosinternals) on Twitter
    Want to get the best Android Apps on your webOS device? Tell HP we need OpenMobile ACL!
    Sign the petition today at http://www.ipetitions.com/petition/a...apps-on-webos/
  7. GigaS27's Avatar
    Posts
    286 Posts
    Global Posts
    389 Global Posts
    #1207  
    Sorry if this has been covered before...i tried reading a few of the past pages but no luck.

    i just upgraded to the touch stones and found out that my phone is now @ temps of 104 when charging. I know when i read about the kernel that they stated the over clocking was brought down during charge rates, but with the touchstone it seems to still be very hot. When i used the cable directly it seemed fine.

    Any ideas?

    Settings:
    Screenstate 500/800
    Compcache @ 64mb
    Sprint Palm Pre-
  8. GigaS27's Avatar
    Posts
    286 Posts
    Global Posts
    389 Global Posts
    #1208  
    Sorry if this has been covered before...i tried reading a few of the past pages but no luck.

    i just upgraded to the touch stones and found out that my phone is now @ temps of 104 when charging. I know when i read about the kernel that they stated the over clocking was brought down during charge rates, but with the touchstone it seems to still be very hot. When i used the cable directly it seemed fine.

    Any ideas?

    Settings:
    Screenstate 500/800
    Compcache @ 64mb
    Sprint Palm Pre-
  9. #1209  
    Quote Originally Posted by naiki View Post
    I have upgraded to webos 1.4.5 from 1.4.1 without uninstalling any patch, nor the uber kernel (I really wanted to uninstall everything before upgrading, but my Pre did it on its own as I left it unattended - I'm not sure how this happenned, but it's not the point now).
    ...
    I have an Spanish Palm Pre with Movistar.
    That's strange... I'm also running an spanish Pre with 1.4.1 firmware, and it says it's up to date?! I'm using it with a Simyo SIM, but I've always been notified when new updates were available (since 1.3.1) 8-?

    Never mind, it still doesn't show up at www.palm.com/support ... 8-)
  10. #1210  
    Quote Originally Posted by GigaS27 View Post
    Sorry if this has been covered before...i tried reading a few of the past pages but no luck.

    i just upgraded to the touch stones and found out that my phone is now @ temps of 104 when charging. I know when i read about the kernel that they stated the over clocking was brought down during charge rates, but with the touchstone it seems to still be very hot. When i used the cable directly it seemed fine.

    Any ideas?

    Settings:
    Screenstate 500/800
    Compcache @ 64mb
    If you set your screen to go off while on the touchstone, it will stay cool. I use an app called 'Quick System Tasks' to do this.
    "Patience, use the force, think." Obi-Wan


    Ready to try Preware? Get this first: Preware Homebrew Documentation
  11. #1211  
    I think my Pres CPU got tired of running at 800MHz... or the battery got tired of powering it at that freq...

    For the last couple weeks I've been experiencing battery drain of 30-35% per hour (using Battery Monitor) while using the phone. Idle drain was 1-2% max.

    After experimenting with removing some patches and apps, I finally broke down and changed the Govnah settings to Palm Default (I left the Compcache enabled at 32MB)... with similar usage the batter drain was a much better at 16-19% per hour.

    I've since started using the Fixed Speed 600 profile and the battery drain is a manageable 18-20% per hour.

    I don't know if anyone else has had a similar experience, based on a lot of posts it appears that many are getting better battery life with overclocking, so it is probably just my unit. Just thought I'd share in case anyone else was seeing a similar drain issue.
    Follow me on teh Twitterz
  12. #1212  
    Quote Originally Posted by Spader View Post
    For the last couple weeks I've been experiencing battery drain of 30-35% per hour (using Battery Monitor) while using the phone. Idle drain was 1-2% max.
    Can you define in detain what you mean by using the phone? If you mean simply making a call the radio uses about 25% per hour of an 1150mAh battery or about 287mA/hr. If the screen is on it will consume between 100 and 200mA/hr depending on brightness level. 3D games (needs more testing) may be somewhere between 400 and 500mA/hr depending on screen brightness and possibly CPU speed (if overclocking). 1-2% per hour idle is better than average for 1150mAh battery (3-5% is the average range). And 1-2% is probably average for some extended batteries depending on how much battery saving tips are followed.

    Quote Originally Posted by Spader View Post
    After experimenting with removing some patches and apps, I finally broke down and changed the Govnah settings to Palm Default (I left the Compcache enabled at 32MB)... with similar usage the batter drain was a much better at 16-19% per hour.
    Can you list the patches you removed. I am not suspecting patches but assessing changes made. So if any other changes not specified please do list them. Also what are your different device settings like brightness, gps, wifi, signal strength, etc. These may be factors to concider as well to determine what is going on. Basically to determine if anything unusual is causing etra drain detailed usage and settings are needed. It may very well be that you are a heavy user and overclocking may possibly increase the drain. I personally don't see any significant increase unless I'm doing certain CPU intensive tasks. But is an acceptable amount. It's not anything close to like doubling the drain compared to stock speed.
    As requested: for my works on webOS patches and apps. Twitter: @larryboytw Patches: Small icons browser start page, 5x5 launcher. I have an AAS CIS Programming degree. I enjoy working on open source projects and alpha and beta testing.
    http://install.preware.org/ for easy to get up and running for patches and apps.
  13. #1213  
    When I was doing my testing (which I was doing purely for my own benefit, so it was far from perfectly scientific) I started with approx. 85% battery, I was on WiFi in my house (N Router, good strength) and had solid Sprint phone signal as well. Also, this is a Stock Pre battery, a little over one year old.

    During my test I was running Baseball Live, polling for scores on one game every two minutes, and battery monitor, set to poll every 30 sec.

    Brightness = 20%
    GPS = On
    Google Location Services = On

    I did three tests, each starting with a Luna restart before, then immediately launching the battery monitor. I then launched a web card (then went to m.precentral.net), Tweed, Facebook Beta and Engadget.

    For 15 minutes at each Govnah setting I would refresh and scroll through each App, making sure that data pull was necessary each time. I tried to spend as close to equal time in each app as I could, but as I said I wasn't striving for perfection.

    This test is where I got my drain numbers from.

    Prior to this test, I had tried removing the battery % in top bar patch, the faster animations patch and the actual battery percentage patch with no difference noted in battery drain (all of these patches had been re-applied prior to my test). I had also cleared over 40 Apps from my Pre that I simply no longer used. haha

    I want to be perfectly clear, I do not blame UK, or Guvnah in any way. I have been overclocking to 800MHz since the first public release of the .sh OC method. I'm on a nearly launch day (Warranty Date Code 6/13/2009) Pre that has never been refurbished.

    I know that I'm what most would call a "heavy" user, and I expect a good amount of battery drain due to this, it was just getting a little too heavy to maintain, so I had to make a change. haha
    Follow me on teh Twitterz
  14. #1214  
    Spader

    That gives me a good picture to go on and it seems to be that with that usage test scenario the drain amount you listed would be expected and I'd even expect any overclocking to increase the consumption. I suspect there was a good amount of screen on time. I'm assuming "For 15 minutes at each Govnah setting" means screen was on all that time and would be at least 27mA (~2.34% of the per hour). The activity that consumes the most based on your description is probably baseball live 2 minute poll. I suspect it contributes maybe a third of the consumption. It's hard to put an amount on the other tasks individually. But they all use CPU and data how much of each depends on what you did with each. As far as I'm aware the omap 3430 is rated to consume 30mA per hour. Idle with all radios on is at least 20mA per hour.

    There is a way to determine exactly how much baseball live consumes. Assuming the battery meter has been recently calibrated from a full discharge cycle and everything is setup as you had in the test let the device run idle for at least 2 hours with battery monitor running at 30 second interval (since that is the interval used in your test). This is the baseline. Then close battery monitor and open baseball live (2 minute poll) and open battery monitor again. Run for two hours that way not turning the screen on after you turn it off once both are running. The reason to open battery monitor after you have done what is needed with baseball live is to not taint the mA average with usage to get baseball live ready. The amount baseball live consumes per is the difference between the mA average baseline and the mA average while baseball live was running. This process can be used to determine consumption for just about anything. I hope this is not off topic for the thread. If someone really wants to the same process can be used at stock speed and overclock speed to see if there is any significant impact to consumption. For example a 3D game played for 2 hours at 800mhz and at the stock 600mhz. Chances are 3D gaming is the most CPU intensive you can get.
    As requested: for my works on webOS patches and apps. Twitter: @larryboytw Patches: Small icons browser start page, 5x5 launcher. I have an AAS CIS Programming degree. I enjoy working on open source projects and alpha and beta testing.
    http://install.preware.org/ for easy to get up and running for patches and apps.
  15. #1215  
    Thanks for the input. It helps put things in perspective.

    I want to make it clear again that I DO NOT blame UK or Guvnah for ANY increased batter drain. I fully understood going in that overclocking the CPU would most likely result in faster battery drain while preforming similar tasks. And I'm fully aware that the way I use the phone (more as a mobile Internet device than as a phone most of the time), is conducive to quick battery drain.

    The only reason I posted this here, is because ultimately I did use UK+Guvnah to curb my battery drain based on MY usage. As they say, your mileage may vary. haha

    What's really great about UK w/Guvnah is that I can set it to stock speeds or even 600MHz to conserve battery, but when I know I'll be near a charger and want a boost in performance a couple taps is all it takes to bump the old CPU clock up to 720 or 800MHz for however long I need it.
    Follow me on teh Twitterz
  16. #1216  
    Quote Originally Posted by Spader View Post
    What's really great about UK w/Guvnah is that I can set it to stock speeds or even 600MHz to conserve battery, but when I know I'll be near a charger and want a boost in performance a couple taps is all it takes to bump the old CPU clock up to 720 or 800MHz for however long I need it.
    Before you get it in your head that lower speeds == less battery drain, you (and any one else that's reading these words) may want to read a bit on "Race To Idle".

    LessWatts.org - Saving Power on Intel systems with Linux

    (URLs seem to be disabled for some reason, or the advanced options just aren't showing for me)


    M.
  17. #1217  
    Quote Originally Posted by Xanadu73 View Post
    Before you get it in your head that lower speeds == less battery drain, you (and any one else that's reading these words) may want to read a bit on "Race To Idle".

    LessWatts.org - Saving Power on Intel systems with Linux

    (URLs seem to be disabled for some reason, or the advanced options just aren't showing for me)


    M.
    I understand the concept you're referring to... however, that doesn't really apply in the "active use" type of situation that I tested for myself.

    Again, I want to make it clear that I don't believe what I did will work for everyone, hoever I did my own test and determined it's the best for ME and MY usage.
    Follow me on teh Twitterz
  18. #1218  
    Quote Originally Posted by Spader View Post
    I understand the concept you're referring to... however, that doesn't really apply in the "active use" type of situation that I tested for myself.

    Again, I want to make it clear that I don't believe what I did will work for everyone, hoever I did my own test and determined it's the best for ME and MY usage.

    Understood, but you specificly mentioned turning down the clock speed to save power. I do get that you're taling about "active use time", but, I think you're forgetting about all the work that gets done when you're not using it. The slower the clock, the longer it takes so the more power it takes to run hard. I quite often see load levels when I'm *not* using my phone DWARF the load levels of when I actually am.


    M.
  19. #1219  
    Ah, I see... yeah, I was referring to when I'm actively using the phone - which is a significant % of the time.
    Follow me on teh Twitterz
  20. #1220  
    Quote Originally Posted by Xanadu73 View Post
    Understood, but you specificly mentioned turning down the clock speed to save power. I do get that you're taling about "active use time", but, I think you're forgetting about all the work that gets done when you're not using it. The slower the clock, the longer it takes so the more power it takes to run hard. I quite often see load levels when I'm *not* using my phone DWARF the load levels of when I actually am.


    M.
    I always forget to mention the other side of the coin. If processing is occurring regularly during periods of idle time the slower speed may also increase battery. Which is why I have been very interested in analyzing battery consumption. Not for my own benefit but for others who may not fully understand how what they do with their device and how certain settings impact how fast or slow their battery is consumed. Knowing a measured amount of consumption for every little thing I have found brings new understanding to many. I try to help others understand as much as possible the various aspects and try using as much stuff as I can quantify in each situation to discover what works best for them. Using that process on my own usage I discovered it is best that I keep my pre running at 800mhz. This is one of the reasons why I like to experiment testing this sort of stuff.
    As requested: for my works on webOS patches and apps. Twitter: @larryboytw Patches: Small icons browser start page, 5x5 launcher. I have an AAS CIS Programming degree. I enjoy working on open source projects and alpha and beta testing.
    http://install.preware.org/ for easy to get up and running for patches and apps.

Tags for this Thread

Posting Permissions