Page 12 of 53 FirstFirst ... 2789101112131415161722 ... LastLast
Results 221 to 240 of 1045
  1. #221  
    Quote Originally Posted by brennan7 View Post
    well as far as i've collected. everyone who is having the freeze issue is using govnah. i just have this kernel installed w/o govnah and it clocks down to 125 as it should and wakes up to 800 without any lag or freeze. Which leads me to believe that it is in fact govnah thats causing the issue when scaling down to 125
    You do realise that when govnah is not running, it does absolutely nothing to anything, right?

    When it is running, it is causing wake-ups and process context switches to update the graph, and that is likely to have an impact on system performance.

    But once you hit the "Save" button, and then exit Govnah, it has absolutely no background operatons at all.

    Now, this is not meant to discount your experiences and observations, it is just the facts about how Govnah works for you to add into your diagnosis deliberations.

    -- Rod
    WebOS Internals and Preware Founder and Developer
    You may wish to donate by Paypal to donations @ webos-internals.org if you find our work useful.
    All donations go back into development.
    www.webos-internals.org twitter.com/webosinternals facebook.com/webosinternals
  2. #222  
    Quote Originally Posted by rwhitby View Post
    You do realise that when govnah is not running, it does absolutely nothing to anything, right?

    When it is running, it is causing wake-ups and process context switches to update the graph, and that is likely to have an impact on system performance.

    But once you hit the "Save" button, and then exit Govnah, it has absolutely no background operatons at all.

    Now, this is not meant to discount your experiences and observations, it is just the facts about how Govnah works for you to add into your diagnosis deliberations.

    -- Rod
    Thanks for the info!

    I am aware that when its not running it has no background function. I was just going more along the lines that most people that are having the screen issue are using the application in some form.
  3. #223  
    Quote Originally Posted by brennan7 View Post
    well as far as i've collected. everyone who is having the freeze issue is using govnah. i just have this kernel installed w/o govnah and it clocks down to 125 as it should and wakes up to 800 without any lag or freeze. Which leads me to believe that it is in fact govnah thats causing the issue when scaling down to 125

    That's an interesting theory. I'll pull out Govnah tonite, let mine run all day tomorrow scalling however Psycho wants it to scale and report back.


    M.
  4. #224  
    Quote Originally Posted by kevank View Post
    I have zipped my script and attached it to the email. Just use wosqi and send the file to /etc/event.d

    Here is the text of the script if you don't want to d/l the attachment:

    start on stopped finish

    console none

    script
    # Set governor
    echo "screenstate" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

    # Set min frequency
    echo 500000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
    # Set max frequency
    echo 800000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq

    end script
    Thanks a lot, it works great!
  5. #225  
    Quote Originally Posted by QuarlesLT View Post
    Thanks a lot, it works great!
    so, just to be clear, if i use the compcavhe karnel 1.4.4 and install this script, my pre will run on 500-800, and i wouldnt need govnah or cpuscaler installed? thanks
  6. #226  
    Quote Originally Posted by ericizzy1 View Post
    so, just to be clear, if i use the compcavhe karnel 1.4.4 and install this script, my pre will run on 500-800, and i wouldnt need govnah or cpuscaler installed? thanks
    Correct.
  7. #227  
    Quote Originally Posted by QuarlesLT View Post
    Correct.
    works great, thank you
    Last edited by ericizzy1; 05/18/2010 at 09:25 AM.
  8. #228  
    btw, when needed, is there a way to remove this 500-800 cputune?
    Last edited by ericizzy1; 05/18/2010 at 11:36 AM.
  9. kevank#AC's Avatar
    Posts
    67 Posts
    Global Posts
    73 Global Posts
    #229  
    Quote Originally Posted by ericizzy1 View Post
    btw, when needed, is there a way to remove this 500-800 cputune?
    Yes. Via WOSQI open the command line and type in:

    mount -o remount,rw /
    rm /etc/event.d/cputune
    mount -o remount,ro /

    K
  10. RRaburn's Avatar
    Posts
    53 Posts
    Global Posts
    102 Global Posts
    #230  
    Now that others have strongly suggested that freezing issues with the kernel are related to mixing it with scaling programs, I would like to move the discussion on to improving the kernel.

    After over 48 hours of kernel operation, I have observed increased overnight battery drain while no applications are open. The drain is significant--from over 70% charge to under 30% in about eight hours.

    Anyone else have similar observations? Please note that I have not experienced other problems with 125 MHz operation.
  11. #231  
    Quote Originally Posted by RRaburn View Post
    After over 48 hours of kernel operation, I have observed increased overnight battery drain while no applications are open. The drain is significant--from over 70% charge to under 30% in about eight hours.
    For the first two months or so after I got my pre (launch day june 2009) with the stock battery I averaged about 5% per hour drain idle. I had GPS on, wifi on, BT off, had average of 2 bars signal, two emails set as items arrive (less than 10 emails a day), instant messengers off, screen brightness at lowest. I switched over to the 2600 extended battery. However if I had stuck with the stock battery after the improvements to battery consumption I would expect to have seen my drain rate improve to probably about 3% per hour. On my 2600 battery originally I was getting between 2% and 3% per hour drain when idle and now get between 1% and 1.5% per hour drain when idle. Do note that I am using the uberkernel set to performance 800 so the cpu remains at a constant 800. I only notice increased drain vs what I am used to seeing on the original kernel at 500 during periods of heavy use of CPU intensive apps. Anyways depending on what your idle drain rate was before I'm not sure if there is any cause for concern at the 5% per hour idle. If the drain rate used to be consistently 2% or less per hour then I would be looking for factors to cause the increase drain if it remains consistently at 5% per hour.
    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.
  12. #232  
    Quote Originally Posted by RRaburn View Post
    Now that others have strongly suggested that freezing issues with the kernel are related to mixing it with scaling programs, I would like to move the discussion on to improving the kernel.

    After over 48 hours of kernel operation, I have observed increased overnight battery drain while no applications are open. The drain is significant--from over 70% charge to under 30% in about eight hours.

    Anyone else have similar observations? Please note that I have not experienced other problems with 125 MHz operation.
    it is just a theory I have that govnah is playing apart in it. It has yet to be solidly proven, and rod's input makes it alot less likely that govnah is causing the problems.

    as for the battery drain, I notice that my idle battery life is much better with this kernel. Now I can take it off the charger around noon, and put it back on at around 3 in the morning, with mid to heavy usage
  13. RRaburn's Avatar
    Posts
    53 Posts
    Global Posts
    102 Global Posts
    #233  
    Quote Originally Posted by brennan7 View Post
    as for the battery drain, I notice that my idle battery life is much better with this kernel.
    Let's make certain we are making valid comparisons.

    My idle battery drain with the compcache kernel is greater than experienced with either the stock Pre or several months of first-generation 800MHz operation. As noted earlier, 125MHz battery drain when running audio apps is improved. StoneRyno's quantitative data provides a baseline and experience with idle uberkernel, but not the compcache kernel sans other scaling apps.
  14. #234  
    Quote Originally Posted by RRaburn View Post
    Let's make certain we are making valid comparisons.

    My idle battery drain with the compcache kernel is greater than experienced with either the stock Pre or several months of first-generation 800MHz operation. As noted earlier, 125MHz battery drain when running audio apps is improved. StoneRyno's quantitative data provides a baseline and experience with idle uberkernel, but not the compcache kernel sans other scaling apps.
    well what i can do it leave my phone idle overnight with battery monitor open and then i can report back the drain per hour tomorrow
  15. #235  
    So... just got my new radio for my car today, and started streaming music over bluetooth. I realized once the screen goes off (and the cpu goes down to 125mhz) the music starts to lagggggggg. I figure its an easy fix to just grab govnah and clock it down to 500 when the screen is off, but just giving ya the fyi!
  16. #236  
    uNixpSyChO: I noticed your latest 1.4.5.1 build is up and shows you've put the min scaling speed back to 500mHz with all the complaints of old Pre's locking. If we run Govnah can we still select a speed <500 post boot? Some of us have Pre-Plus's that run fine at 125, 250, etc.


    EDIT: never mind, I re-read your first post with the updated info and tested the kernel and see that the hard deck is 500. I did find I could use Govnah to set the screen on/max to 600, 720, or 800 however.
    Last edited by 4wheels; 05/19/2010 at 09:04 PM.
  17. giftedmd's Avatar
    Posts
    43 Posts
    Global Posts
    91 Global Posts
    #237  
    Quote Originally Posted by 4wheels
    uNixpSyChO: I noticed your latest 1.4.5.1 build is up and shows you've put the min scaling speed back to 500mHz with all the complaints of old Pre's locking. If we run Govnah can we still select a speed <500 post boot? Some of us have Pre-Plus's that run fine at 125, 250, etc.


    EDIT: never mind, I re-read your first post with the updated info and tested the kernel and see that the hard deck is 500. I did find I could use Govnah to set the screen on/max to 600, 720, or 800 however.
    Oh no! I love the kernel the way it is, being able to scale to 125MHz works awesome for me! If people dont like it, they can use the uberkernel or run the script mentioned earlier for 500-800 screenstate scaling. Keep the 125-800MHz screenstate alive!
    Last edited by rlsroufe; 05/19/2010 at 10:32 PM.
  18. #238  
    Quote Originally Posted by rlsroufe View Post
    Oh no! I love the kernel the way it is, being able to scale to 125MHz works awesome for me! If people dont like it, they can use the uberkernel or run the script mentioned earlier for 500-800 screenstate scaling. Keep the 125-800MHz screenstate alive!
    you could just keep that kernel saved somewhere on your pc. Most people had problems with the phone freezing (not the kernels fault) and i recently had problems with bluetooth audio streaming when the screen was off at 125 mhz.

    Its the right idea, just some kinks need to be worked out
  19.    #239  
    Quote Originally Posted by brennan7 View Post
    you could just keep that kernel saved somewhere on your pc. Most people had problems with the phone freezing (not the kernels fault) and i recently had problems with bluetooth audio streaming when the screen was off at 125 mhz.

    Its the right idea, just some kinks need to be worked out
    Then why not set it to 250Mhz?

    A2DP is a hog.
    Live free or DIE!
  20.    #240  
    Quote Originally Posted by rlsroufe View Post
    Oh no! I love the kernel the way it is, being able to scale to 125MHz works awesome for me! If people dont like it, they can use the uberkernel or run the script mentioned earlier for 500-800 screenstate scaling. Keep the 125-800MHz screenstate alive!
    alot of users dont like creating a script for that. esp if they forget about it.

    125/250 will be back. Other things have to get updated to take advantage of it.
    Live free or DIE!

Posting Permissions