Page 2 of 3 FirstFirst 123 LastLast
Results 21 to 40 of 48
  1. Daemon's Avatar
    Posts
    796 Posts
    Global Posts
    809 Global Posts
    #21  
    Quote Originally Posted by idontwan2know View Post
    It's not credible that increasing the clock speed of your CPU has vastly improved your battery life.

    More likely is that the battery monitor is not calibrated properly and will correct out over several days, or that your usage patterns have changed.

    It's not impossible either. I get more standby time out of the stock
    battery than anyone else I've ever seen here (60+ hrs) and I've done
    it both before and after the 800Mhz patch so it certainly hasn't hurt
    anything and can't be explained away by battery calibration quirks.
    Keep in mind that CPU is only one of several sources of battery
    drain. The data radios (EVDO and/or Wifi) are a large percentage, so it's
    conceivable that by having a faster CPU, background tasks simply get done in
    less time and the data radio is thus active for shorter intervals causing a net
    decrease in battery drain.

    BTW, if you want to wait on 1.4.1 until there's an updated overclocking patch,
    it's easy enough to disable the auto update.
    http://www.webos-internals.org/wiki/Blocking_Updates

    ian
  2. #22  
    I've noticed an increase in battery life with the patch as well. My useage patterns certainly haven't changed. It does help. I've been running on 1.4.1 since Wednesday night and have had no gliches or crashes. As I stated in another post the cpu running at 800 seems to be more efficient and does save battery. I'm gonna run data on 1x all day and see if the battery life is even better.
  3. #23  
    Clocking to 800MHz will indeed save battery life, under the condition that the ondemand scheduler is enabled and not the sucky Palm power daemon (no offense guys, but... really?). The reason is explained by a senior kernel hacker at Intel at the end of the posting here: weird interrupts

    Those with bad CPUs may be helped by the following settings which tweak ondemand to:

    * set the system not to step up processor speed until 50% utilisation is hit (default is 95% which is way too stingy, some people are suggesting 20% which I found too lax, 50% is so far for me a happy medium)
    * Double the sampling rate. Some people are recommending increasing this by 1 or 2 orders of magnitude; this will certainly reduce latency (and thereby increase performance) but at the cost of battery life as the CPU is woken more often to sample the load to see if it needs to be increased - this will cause a Heisenbug to some extent as the system may have to step up the processor speed just to cope with the load of the increased sampling rate.
    * Set the powersave_bias to 50 (which is 5%). This causes the system to step down the speed to one below it powersave_bias/10% of the time; so for example if the system is set to run at 800MHz it will step down to 720MHz 5% of the time. If I understand the documentation correctly, when the sampling loop next runs if the load is not sufficient to raise it back to 800MHz it will stick to 720MHz. Whether at that point it also has a 5% chance of stepping down to 600MHz I do not know.

    These settings can be cut and pasted into a novaterm or terminal window (rebooting your Pre will reset these settings to default if anything goes awry):

    echo "800000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
    echo "125000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
    echo "ondemand" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
    echo 50 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/up_threshold
    echo 20000 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/sampling_rate
    echo 50 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/powersave_bias
  4. #24  
    Oh, and for those who are finding 800MHz a massive power drain, you are either (a) not doing it right, or (b) spending too much time playing with your much faster Pre. Physically using the device is the fastest way you can drain the battery.

    Cheers, Steve
  5. #25  
    To follow up once more, empirical tinkering shows that when the CPU steps down, it also has a 5% chance of stepping to the next speed down. This is pretty rare, though - it is more likely to go from 720 to 250 or 125.

    Cheers, Steve
  6. #26  
    And one last point, as pointed out by rwhtiby and supplemented by my own advice: Some people have reported problems with phones locking at 125MHz; If you would like to have a minimum of 250MHz instead replace:

    echo "125000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq

    with

    echo "250000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq

    And to state the obvious: this (along with the 800/720/600MHz patches and the like) is tweaking on the hardware to drive it outside the limits that Palm set. If the phone breaks and you do not have some form of insurance, your only satisfaction is that you get to keep the broken phone. At least it looks quite pretty.

    Cheers, Steve
  7. #27  
    Also, only once using the scaling commands above for a while to make sure they're stable on your device, it's very simple to have them apply immediately at boot.

    Just create a file that says the following:

    Code:
    start on stopped finish
    stop on runlevel [!2]
    console none
    script
    <insert commands that you've tested to be stable on your device here>
    end script
    and then send that file to /etc/event.d/

    One last thing that I highly recommend in your stability testing is trying to watch a video. Last time I tried any form of CPU scaling, it worked very well in most day-to-day use, but I got horrible artifacting in videos.
    Last edited by jhoff80; 04/04/2010 at 05:24 PM.
  8. #28  
    Good call, jhoff80; I should have posted my script. For anyone looking for a hand held "cut and paste from command line to automate it", here you go:

    palm-webos-device / # cat > /etc/event.d/cpu-scaling
    # Enables cpu scaling

    start on stopped finish
    stop on runlevel [!2]

    console none

    script
    echo "800000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
    echo "125000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
    echo "ondemand" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
    echo 50 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/up_threshold
    echo 20000 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/sampling_rate
    echo 50 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/powersave_bias
    end script

    (hold down the CTRL key, hit the d key, release CTRL key)
    palm-webos-device / #

    Cheers, Steve
  9. #29  
    Quote Originally Posted by jhoff80 View Post
    Also, only once using the scaling commands above for a while to make sure they're stable on your device, it's very simple to have them apply immediately at boot.

    Just create a file that says the following:

    Code:
    start on stopped finish
    stop on runlevel [!2]
    console none
    script
    <insert commands that you've tested to be stable on your device here>
    end script
    and then send that file to /etc/event.d/

    One last thing that I highly recommend in your stability testing is trying to watch a video. Last time I tried any form of CPU scaling, it worked very well in most day-to-day use, but I got horrible artifacting in videos.
    Are you sure? Doesn't LunaSysMgr mess things up after boot?
  10. #30  
    In my empirical testing, LunaSysMgr can only affect things if the governor is set to userspace; it has no effect when ondemand is selected.

    Cheers, Steve
  11. #31  
    Quote Originally Posted by jhoff80 View Post
    Also, only once using the scaling commands above for a while to make sure they're stable on your device, it's very simple to have them apply immediately at boot.

    Just create a file that says the following:

    Code:
    start on stopped finish
    stop on runlevel [!2]
    console none
    script
    <insert commands that you've tested to be stable on your device here>
    end script
    and then send that file to /etc/event.d/

    One last thing that I highly recommend in your stability testing is trying to watch a video. Last time I tried any form of CPU scaling, it worked very well in most day-to-day use, but I got horrible artifacting in videos.
    can confirm that, smooth overall, but after watching a video i got horrible artifacting even after closing the youtube app. removing those changes fixed it.
  12. #32  
    I haven't tried scaling in a while, but this thread re-inspired me to.

    I got the artifacting again at 125 and 250 MHz as minimums, in both video and 3d games.

    Then, I decided what would work well for me is to scale solely between 500MHz and 800MHz.

    I figure, that would give me most of the advantage of the increased 800MHz speed when necessary, but since the CPU could scale down to stock, should have even less of an issue with heat and battery.

    Can't confirm that my assumptions are correct yet, but I can say that I haven't gotten any artifacts during videos or 3d games.
  13. #33  
    Quote Originally Posted by jhoff80 View Post
    I haven't tried scaling in a while, but this thread re-inspired me to.

    I got the artifacting again at 125 and 250 MHz as minimums, in both video and 3d games.
    You might want to play with decreasing up_threshold and/or powersave_bias to make the CPU more aggressive in clocking up. The settings I posted were conservative in order to (a) cope with my "bad" cpu, and (b) extend the battery life.

    Cheers, Steve
  14. #34  
    Quote Originally Posted by sbromwich View Post
    You might want to play with decreasing up_threshold and/or powersave_bias to make the CPU more aggressive in clocking up. The settings I posted were conservative in order to (a) cope with my "bad" cpu, and (b) extend the battery life.

    Cheers, Steve
    Yeah, I spent a while trying to mess around with that stuff for the first few months I had my Pre, and the reason I stopped using it was despite all the experimentation I could never get it working well enough.

    The scaling between 500 and 800 is nice enough for me, because it was either going to be constantly at 800, or this.
  15. stubbs's Avatar
    Posts
    425 Posts
    Global Posts
    442 Global Posts
    #35  
    Quote Originally Posted by jhoff80 View Post
    I haven't tried scaling in a while, but this thread re-inspired me to.

    I got the artifacting again at 125 and 250 MHz as minimums, in both video and 3d games.

    Then, I decided what would work well for me is to scale solely between 500MHz and 800MHz.

    I figure, that would give me most of the advantage of the increased 800MHz speed when necessary, but since the CPU could scale down to stock, should have even less of an issue with heat and battery.

    Can't confirm that my assumptions are correct yet, but I can say that I haven't gotten any artifacts during videos or 3d games.
    I've done the same thing, and scaling between 500 and 800MHz is working beautifully.
  16. #36  
    Quote Originally Posted by jhoff80 View Post
    Yeah, I spent a while trying to mess around with that stuff for the first few months I had my Pre, and the reason I stopped using it was despite all the experimentation I could never get it working well enough.

    The scaling between 500 and 800 is nice enough for me, because it was either going to be constantly at 800, or this.
    Oh, that sucks :-(

    I think that hints there may be different "types" of "bad" CPUs, or perhaps limits on how low some "bad" CPUs go? Mine is happy with 125 for hours on end but won't run at 800 for long. Interesting.

    Cheers, Steve
  17. danstah's Avatar
    Posts
    136 Posts
    Global Posts
    141 Global Posts
    #37  
    Also tried the 125 and 250 with no luck. Then i set it to 500 and still get artifacting in 3d games strangely enough.... Even tried 600 with no luck. Seems like a problem with the ondemand scheduler
  18. #38  
    FYI, my "scaling_max_freq" seems to be locked in at "600000" and I can't get it to register "echo '800000' > scaling_max_freq." scaling_min_freq is fine at 250000.

    cat /proc/cpuinfo shows "BogoMIPS: 498.07" Should that be different?
  19. #39  
    Another 'success' story about positive battery improvement with the 800 MHz. Not only did the patch itself improve battery life, but also switching my email to push (from 30 min checking). I took it off the power at 7 AM and it only gave me the 10% warning at midnight (normally I get it at around 6 PM). Normal (obsessive) usage as always.
  20. #40  
    Quote Originally Posted by sbromwich View Post
    Clocking to 800MHz will indeed save battery life, under the condition that the ondemand scheduler is enabled and not the sucky Palm power daemon (no offense guys, but... really?). The reason is explained by a senior kernel hacker at Intel at the end of the posting here: weird interrupts

    Those with bad CPUs may be helped by the following settings which tweak ondemand to:

    * set the system not to step up processor speed until 50% utilisation is hit (default is 95% which is way too stingy, some people are suggesting 20% which I found too lax, 50% is so far for me a happy medium)
    * Double the sampling rate. Some people are recommending increasing this by 1 or 2 orders of magnitude; this will certainly reduce latency (and thereby increase performance) but at the cost of battery life as the CPU is woken more often to sample the load to see if it needs to be increased - this will cause a Heisenbug to some extent as the system may have to step up the processor speed just to cope with the load of the increased sampling rate.
    * Set the powersave_bias to 50 (which is 5%). This causes the system to step down the speed to one below it powersave_bias/10% of the time; so for example if the system is set to run at 800MHz it will step down to 720MHz 5% of the time. If I understand the documentation correctly, when the sampling loop next runs if the load is not sufficient to raise it back to 800MHz it will stick to 720MHz. Whether at that point it also has a 5% chance of stepping down to 600MHz I do not know.

    These settings can be cut and pasted into a novaterm or terminal window (rebooting your Pre will reset these settings to default if anything goes awry):

    echo "800000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
    echo "125000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
    echo "ondemand" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
    echo 50 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/up_threshold
    echo 20000 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/sampling_rate
    echo 50 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/powersave_bias
    Thanks for the info!
    Last edited by Josephc1991; 04/05/2010 at 08:57 PM.
Page 2 of 3 FirstFirst 123 LastLast

Posting Permissions