Optimal speed (slot) distribution...

Discussion in 'Android Hacks and Help' started by mikes, Apr 4, 2010.

  1. mikes

    mikes Member

    Joined:
    Jan 10, 2010
    Messages:
    304
    Likes Received:
    0
    Trophy Points:
    16
    Ratings:
    +0
    I've been giving this some thought - how best should speeds be distributed between the available slots?

    The default ondemand governor works by monitoring utilization, so (as an example), when utilization hits 80% at one speed, the processor would be moved to the next speed up. It's not clear how the decision to throttle down is made. More info on Linux cpufreq governers here.

    This argues for a logarithmic progression of speeds. For example, a 5 slot, with a 125/800 min/max would be 125/200/325/500/800 (averaged to nearest 25 MHz), so each step is ~60% increase in performance. Throughout this post, I'm assuming that a 25 MHz granularity is possible across-the-board, correct me if that's not right.

    But, there's also the effect on power consumption to consider. As a general rule, power consumption in CMOS gates increases linearly with clock speed. More correctly, there's also a static power draw which gets added, so it never goes to zero. Taking a look at a power estimation spreadsheet for the OMAP3540, leaving the assumptions unmodified, and looking at the power for the available speeds, gives the following:
    Code:
    MHz  mW   mW/MHz
    125  442   3.54
    250  541   2.16
    500  818   1.64
    600  1057  1.68
    720  1190  1.65
    From this, it can be seen that lower speeds, although they use less power, are also less efficient. So, when more than minimal processor performance is needed, it's probably best to accelerate quickly to gain efficiency and get the job done, so we can throttle back down to idle. A range of constant efficiency is achieved starting somewhere between 250 and 500 MHz.

    For those reasons, I'm thinking the optimal speed/slot distribution should start with the min (and you do want a low min, for battery life), but have an unevenly large jump to the second available speed, and then logarithmic progression to max speed. Once you're in the range of constant efficiency, you want to run the processor as slowly as possible to support the load, for maximum power savings.

    So, for a 125/800 min/max, 5 slot, optimal may be closer to 125/325/450/600/800, with a large initial jump (~160%), followed by evenly spaced increases of ~35%.

    Some others, based on the same proposition, starting with 125/325:
    Code:
    5 slot:
    125/325/400/500/600 (23% increases)
    125/325/475/700/1000 (45%)
    125/325/500/775/1200 (55%)
    
    7 slot:
    125/325/375/425/475/525/600 (13%)
    125/325/400/475/550/675/800 (20%)
    125/325/400/500/650/800/1000 (25%)
    125/325/425/550/700/925/1200  (30%)

     
    #1 mikes, Apr 4, 2010
    Last edited: Apr 4, 2010
  2. virtualhuman

    virtualhuman Member

    Joined:
    Mar 7, 2010
    Messages:
    246
    Likes Received:
    0
    Trophy Points:
    16
    Ratings:
    +0
    I think the one and only constructive contribution I can make to this thread is that I think the last column in the first table should be labeled mW/MHz and not MHz/mW.

    Now I'll go back to the sideline and listen to you more knowledgeable peeps. Looks good though. :)
     
  3. mikes

    mikes Member

    Joined:
    Jan 10, 2010
    Messages:
    304
    Likes Received:
    0
    Trophy Points:
    16
    Ratings:
    +0
    Thanks. fixed
     
  4. DroidxRage

    DroidxRage Member

    Joined:
    Nov 17, 2009
    Messages:
    627
    Likes Received:
    0
    Trophy Points:
    16
    Location:
    New England - Home of Champions
    Ratings:
    +0
    Wow, good read man!!!

    Very interesting concept you have here, and I think it may have a lot of validity. Thanks for breaking it down like this, now to wrap my head around it.


    So what keeps the mid range speeds from becoming less efficient when power draw becomes more than the clock speed at that range? (Edit: NVM - you lowered the percent increase through the successive steps to compensate, I was looking at it simply from the low end of the clock)

    It almost seems like we need a little more info about the underlying scaling algorithms to really get a complete grasp on how to trick the scaling on when it throttles up or scales back.
     
  5. adrynalyne

    adrynalyne Premium Member
    Premium Member Developer

    Joined:
    Dec 21, 2009
    Messages:
    2,896
    Likes Received:
    5
    Trophy Points:
    103
    Ratings:
    +5
    Interesting read. I would have never put that much thought into it ;)
     
  6. adrynalyne

    adrynalyne Premium Member
    Premium Member Developer

    Joined:
    Dec 21, 2009
    Messages:
    2,896
    Likes Received:
    5
    Trophy Points:
    103
    Ratings:
    +5
    @mikes

    I'm willing to test this and see how it works out. It would take a while for a worthwhile conclusion, but I'll make the kernels for ya. Let me know.
     
  7. jrod1990

    jrod1990 Member

    Joined:
    Jan 4, 2010
    Messages:
    188
    Likes Received:
    0
    Trophy Points:
    16
    Ratings:
    +0
    I would be willing to test a 7 slot 800Mhz or 1000Mhz for a week or two and keep track of battery life and temps...
     
    #7 jrod1990, Apr 6, 2010
    Last edited: Apr 6, 2010
  8. hypura

    hypura Member

    Joined:
    Nov 20, 2009
    Messages:
    88
    Likes Received:
    0
    Trophy Points:
    6
    Ratings:
    +0
    I'd be willing to test this out as well.
     
  9. adrynalyne

    adrynalyne Premium Member
    Premium Member Developer

    Joined:
    Dec 21, 2009
    Messages:
    2,896
    Likes Received:
    5
    Trophy Points:
    103
    Ratings:
    +5
    He has been PMing me for compiling advice, so I assume he is working on it for you folks to try.
     
Search tags for this page

android lower mhz less power