linux-kernel - Re: [linux-pm] suspend blockers & Android integration

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 6 Jun 2010 02:56:04 -0700 (PDT)
From:	david@...g.hm
To:	Brian Swetland <swetland@...gle.com>
cc:	Vitaly Wool <vitalywool@...il.com>,
	Arve Hjønnevåg <arve@...roid.com>,
	Arjan van de Ven <arjan@...radead.org>, tytso@....edu,
	Florian Mickler <florian@...kler.org>,
	Peter Zijlstra <peterz@...radead.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	LKML <linux-kernel@...r.kernel.org>, Neil Brown <neilb@...e.de>,
	James Bottomley <James.Bottomley@...e.de>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Linux PM <linux-pm@...ts.linux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Felipe Balbi <felipe.balbi@...ia.com>
Subject: Re: [linux-pm] suspend blockers & Android integration

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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/