linux-kernel - Re: Attempted summary of suspend-blockers LKML thread

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, 1 Aug 2010 08:49:43 +0200 (CEST)
From:	Mikael Abrahamsson <swmike@....pp.se>
To:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
cc:	Arjan van de Ven <arjan@...radead.org>,
	linux-pm@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
	arve@...roid.com, mjg59@...f.ucam.org, pavel@....cz,
	florian@...kler.org, rjw@...k.pl, stern@...land.harvard.edu,
	swetland@...gle.com, peterz@...radead.org, tglx@...utronix.de,
	alan@...rguk.ukuu.org.uk
Subject: Re: Attempted summary of suspend-blockers LKML thread

On Sun, 1 Aug 2010, Mikael Abrahamsson wrote:

> it's just that mobile (low power) wasn't the intended target of the 
> application when it was written, and this commonly shows.

I have another aspect I just thought about. I work for a telephony 
company. We provide Internet connectivity throught various means, DSL, 
Ethernet to the Home, mobile etc.

For ETTH and DSL, network usage is pretty straight forward, you send 
packets, they get delivered pretty quickly with low marginal cost per 
packet. For mobile, this is not quite so simple. Mobile networks are 
designed for terminal/UE (user equipment) to use low power, so they go 
down in low power state after a while. Let's take the case of 3G/HSPA:

After a short while (second) of idleness (no packets being sent), the 
mobile network negotiates away the high speed resources (the one that 
enables multimegabit/s transfers) and tries to give it to someone else. 
After approximately 30 seconds, the terminal goes to "idle", meaning it 
has no network resources at all. Next time it wants to send something (or 
the network wants to deliver something to it), network resources need to 
be negotiated again. This can take 1-2 seconds and uses battery power of 
course. It also consumes resources in the operator network (because 
mobility control units need to talk to base stations, tunnels need to be 
re-negotiated etc).

Anyhow, my point is that not only is there a benefit in having multiple 
applications wake up at the same time for power reasons within the device, 
there is also a point in having coordination of their network access. If a 
device is running 3 IM programs at the same time, it'd be beneficial if 
they were coordinated in their communication with their Internet servers. 
Same goes for the "check for new email" application. If they all were 
optimized to only wake up the network connectivity once every 180 seconds 
instead of doing it when the individual application felt like it, power 
and other resources would be saved by all involved parties.

-- 
Mikael Abrahamsson    email: swmike@....pp.se
--
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/