Home Reading Searching Subscribe Sponsors Statistics Posting Contact Spam Lists Links About Hosting Filtering Features Download Marketing Archives FAQ Blog From: lang.hm> Subject: Re: [linux-pm] suspend blockers & Android integration Newsgroups: gmane.linux.ports.arm.omap Date: Sunday 6th June 2010 09:56:04 UTC (over 7 years ago) ```On Sun, 6 Jun 2010, Brian Swetland wrote: > The savings in airplane mode (apart from preventing data connections, > which saves power by preventing data-hungry background apps from doing > much) is the difference between standby with radio (3-5mA) and without > (1-2mA). I'm not suggesting that airplane mode is a typical case, > just using it as in illustration of the more extreme standby case. for the sake of discussion, let's say that standby is 5ma and full operation is 500ma and a minimal wakeup is 0.1 sec. these are probably fairly pessimistic numbers. waking up every second would be awake 10% of the time, so in an hour you would use .9*5mA + .1*500mA = 4.5mA +45mA = 49.5mAH waking up every 10 seconds would be awake 1% of the time, so in an hour you would use .99*5mA + 0.01*500mA = 4.95mA + 5mA = 9.95mAH waking up every 100 seconds would be awake 0.1% of the time, so in an hour you would use .999*5mA + 0.001*500mA =4.995mA + 0.5mA = 5.495mAH waking up every 1000 seconds would be awake 0.01% of the time so in an hour you would use .9999*5mA + 0.0001*500mA = 4.9995mA + 0.05mAH = 5.0495mAH now if you have a 1000mAH battery (small, but reasonable for a smartphone) your standby life would be .1 second wakeup (on continuously) = 2 hours 1 second wakup = 20 hours 10 second wakeup = 100 hours 100 second wakeup = 182 hours 1000 second wakeup = 198 hours if you could shrink the time awake to 0.01 second per wakeup you would shift this all up a category (and avoiding the need to wake everything up to service a timer would help do this) this effort very definantly has diminishing returns as you go to larger sleep periods as the constant standby power draw becomes more and more dominating. someone mentioned that they were getting the sleep time of normal systems up past the 1 second mark with the 10 second mark looking very attainable. that is where you get the most benifit for whatever changes are needed. getting up to a 2 min sleep time really gives you about all the benifit that you can get, going from there to 15 min makes very little difference. don't let chasing the best possible sleep time prevent you from considering options that would be good enough in time, but would drastically reduce the maintinance effort (as things could be upstreamed more easily), and would be usable on far more systems. David Lang -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html```
CD: 3ms