Results 1 to 17 of 17
  1.    #1  
    Has anyone else found that scaling doesn't help save battery?

    I've been doing some tests of battery life under different conditions. I completed 2 tests so far. I was wondering if there's something obvious that I'm missing that would explain these findings.

    Test 1:
    • CPU Scaling enabled via CPU Scaler Uber
    • 500 - 800 MHz
    • Wifi On
    • Device left on countertop, unused
    • Test Duration: 4 hrs
    • Drain Per Hour reported by Battery Monitor: 2.0% dph


    Test 2:
    • CPU Scaling disabled
    • 800 MHz fixed kernel speed
    • Wifi On
    • Device left on countertop, unused
    • Test Duration: 4 hrs
    • Drain Per Hour: 1.5% dph


    I was surprised that the drain per hour was less at the fixed maximum kernel speed than it was for scaling.

    I'm currently running Test 3 which is the same as Test 2 except at stock kernel speeds. After that, I plan on running Test 4 which will scale 250 - 800 MHz.

    Appreciate any feedback you might have.
    Twitter: dullgeek
  2. #2  
    Well there's a few things in play here, that I can think of.

    One is that whatever background tasks are happening on your Pre are getting done faster when it's at 800MHz, so the chip is just idling after it completes them.

    Secondly, I can't remember exactly, but I'm pretty sure the CPU Scaling app uses a very aggressive up_threshold. I want to say it's something like 10%, though I'm not entirely certain. That means that whenever your Pre goes above 10% CPU usage at one frequency, it'll move up to the next frequency. It might be the case that the phone is just spending most of its time at 800MHz anyway.

    Thirdly of course, there's no guarantees that your signal would be the same even at the same place, but the four hour test periods should help reduce random differences like that.

    But honestly, not entirely sure if those reasons are definitely why, just throwing a couple ideas out there.
  3. #3  
    LessWatts.org - Saving Power on Intel systems with Linux is one theory. Whether it applies here or not is up to the reader to decide.

    -- 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
  4. #4  
    I've noticed it too.

    I'm doing a less scientific test. I'm going to strip out the 800 mhz kernel and see how I do today with just the CPU scaler set to scale between 125 and 500. Then tomorrow, 250 - 500. Etc.

    I'm very busy right now, but hopefully I'll be able to report back soon.
  5. #5  
    anecdotally, I have been kinda disappointed with battery life using the scaler at 125-800. I'm no sure if it's worse than without scaling, but it's not much better, if at all (around 6% dph under moderate usage, no wifi).
  6. #6  
    Just chiming in to say that I've had the same experience (using a script rather than that app though). And my scaling Pre crashes much more often than it did without the scaling script (six times in three days as opposed to maybe once a month, if that).
  7. #7  
    Scaler only helps for when your phone is idle. All other times its going to run at or near the maximum speed. For heavy use you're not going to much improvement between scaling 125 - 800 and just sitting at 800. You'll see more benefit, if you set it to the stock speed for situations where speed doesn't help (ie playing any media or texting). The scaler app, if nothing else makes it convienent to appropriately set your clock speed based on what you're doing.

    The best test would be to let it sit idle in Airplane mode. WiFi and phone signal strength can vary, thus affecting battery draw.
  8. #8  
    I use the Battery Saver app @ night and believe that results in a .5% drain per hour without CPU scaling. Since CPU scaling that has dropped to a rate of .25% per hour (probably lower since its only down 2 and sometimes only 1% by the morning which is 7-8 hours later).
  9. #9  
    Quote Originally Posted by Mordbane View Post
    The best test would be to let it sit idle in Airplane mode. WiFi and phone signal strength can vary, thus affecting battery draw.
    To call this the 'best' test is misleading. What would you really be testing? Lab conditions are about the worst conditions for a test, unless you're a producer and need to move some product (hence the 350 hours standby time, I guess). For all normal intents and purposes, stable real world conditions are the best because they give the most useful information.

    Like for example, my 800MHz Pre uses less than 0.3% per hour when idling in airplane mode. Sadly this doesn't tell me (or anyone else) jack about how it will behave when you're actually using it.

    There are few things that I'd like more than having 10 pres for a month to conduct a scientific study of the device's battery life under different, but stable, real-world conditions. I probably have to wear a star trek uniform or something to become nerdier than I am now.
  10. #10  
    Quote Originally Posted by Mordbane View Post
    The best test would be to let it sit idle in Airplane mode.
    That's exatly what the Battery Saver app does and the CPU scaler has provided returns of at least 50% in battery life improvement.

    It's nice but I don't know if most people are wlling to turn off their radio for that purpose. So under less than ideal circumstances the gains will be alot less and possibly non-existent.
    Last edited by foosball; 04/21/2010 at 09:13 AM.
  11. #11  
    Quote Originally Posted by GodShapedHole View Post
    To call this the 'best' test is misleading. What would you really be testing? Lab conditions are about the worst conditions for a test, unless you're a producer and need to move some product (hence the 350 hours standby time, I guess). For all normal intents and purposes, stable real world conditions are the best because they give the most useful information.

    Like for example, my 800MHz Pre uses less than 0.3% per hour when idling in airplane mode. Sadly this doesn't tell me (or anyone else) jack about how it will behave when you're actually using it.

    There are few things that I'd like more than having 10 pres for a month to conduct a scientific study of the device's battery life under different, but stable, real-world conditions. I probably have to wear a star trek uniform or something to become nerdier than I am now.
    Good point. I should have qualified that with "The best test for someone with one Pre". Multiple cloned Pres would be ideal, but who other than Palm has that. This is in reference to the premise and question set by the OP: sitting idle for four hours, the scaler app gets 0.5% worst battery draw than setting a constant clock speed. It was never targeted toward comparing the two scenarios under everyday operating parameters or actual use of the phone.
  12. #12  
    Are you sure scaling is being enabled? When I was trying to use the scaling app, scaling wasn't actually getting enabled.

    If you do:
    cat /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state

    in the command line, it will tell you how long it has been using each frequency. When I used the scaling app, it was still only using 800mhz. When I ran the scaling commands through the command line, scaling was enabled successfully.

    Since enabling scaling, my battery life has been increased significantly. Going from charging at least twice a day to being able to go 1 and a half days without a charge. (and still having 20% at that.)

    Code:
    echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
    echo 800000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
    echo 125000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
    echo 11 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/up_threshold
    echo 1 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/powersave_bias
    Those are the commands I use to enable scaling from 125 - 800mhz
  13.    #13  
    Quote Originally Posted by Mordbane View Post
    Scaler only helps for when your phone is idle.
    In both of my tests, my phone was not used by anyone over the entire test period. The only card left active was Battery Monitor. All other background tasks were left to run (e.g. Twee notification checking, facebook notification checking, etc). I wanted something to kick off that would cause the device to use the CPU to bring it up to 800MHz. Otherwise, if the phone did nothing, then I might as well just test 500MHz (the min scaling frequency) vs 800MHz. Something had to happen on the phone to kick it up to 800MHz in order to test the impact of scaling.
    The best test would be to let it sit idle in Airplane mode. WiFi and phone signal strength can vary, thus affecting battery draw.
    Yes that's true. But that's why I ran the test over 4 hours. To average out signal fluctuations. Over that period of time the average signal strength is going to be pretty consistent unless a tower or wifi router breaks.
    Quote Originally Posted by merkel85 View Post
    Are you sure scaling is being enabled? When I was trying to use the scaling app, scaling wasn't actually getting enabled.
    Yes I'm sure. The CPU Scaler Uber app doesn't save scaling after a reboot. I wonder if that may have been why you weren't seeing it working. I have had no problems w/CPU Scaler Uber working properly.
    Last edited by mu7efcer; 04/21/2010 at 04:26 PM.
    Twitter: dullgeek
  14. schlk21's Avatar
    Posts
    775 Posts
    Global Posts
    776 Global Posts
    #14  
    I have the 800 MHz kernel installed and tried the Uber version of CPUscaler. After applying different scaling options or even different speeds, the CPU speed never changed. I checked the speed using Linux command line in WebOS Quick Install: cat /proc/cpuinfo
  15. Daemon's Avatar
    Posts
    796 Posts
    Global Posts
    809 Global Posts
    #15  
    My problem is, I already get phenomenal battery life while on standby and
    scaling hasn't helped at all, but 800Mhz kernel has hurt a lot when it matters to me. Data
    on all the time, usually on Wifi, two polling email accounts, and Battery Monitor app
    running all the time, I can sit on standby for 60 hours between charges, whether I'm
    running at 500Mhz or 800Mhz. Problem is, while the phone is perfectly capable of streaming
    audio (Pandora or various apps that serve Shoutcast streams) at 500Mhz or less, if the
    800Mhz kernel is installed and scaling enabled, it runs the CPU at 800Mhz while streaming
    and the battery drain goes up in almost direct proportion. Pandora uses a different audio
    streaming API (palm's own that they won't let anyone else use) than all the rest of the
    apps, so it uses about half the power, but it's still a noticeable increase when streaming at
    800Mhz. Other streaming apps like Radio Hibiki, Net2Streams etc, can burn close to 400mA
    while streaming anything at all at 800Mhz, which is just brutal on battery life.
    YouTube.. forget about it. 500+mA (or close to 50%/hr on stock battery).

    Basically scaling is worthless to me so I've forced my kernel to stay at 500Mhz
    and only bump it up to 800Mhz with a shell script to show off.
    If someone could come up with a scaling profile that would actually try hard to
    scale down, when it's definitely not necessary to run at 800Mhz (in particular, streaming
    audio), then I'd happily run that.

    ian
  16. schlk21's Avatar
    Posts
    775 Posts
    Global Posts
    776 Global Posts
    #16  
    Quote Originally Posted by schlk21 View Post
    I have the 800 MHz kernel installed and tried the Uber version of CPUscaler. After applying different scaling options or even different speeds, the CPU speed never changed. I checked the speed using Linux command line in WebOS Quick Install: cat /proc/cpuinfo
    bump, Is this an accurate way to check the clock time in real time?
  17. #17  
    Quote Originally Posted by schlk21 View Post
    bump, Is this an accurate way to check the clock time in real time?
    You can run the Govnah app from the WebOS Internals testing feed to see a real-time graph of the frequency (and internal CPU temperature too if you're running the WebOS Internals Uber-Kernel).

    See http://bit.ly/next-gen-kernels and http://bit.ly/uber-kernel-alpha

    -- 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

Posting Permissions