Date:	Sun, 1 Aug 2010 15:49:04 -0700
From:	Arjan van de Ven <arjan@...radead.org>
To:	paulmck@...ux.vnet.ibm.com
Cc:	Mikael Abrahamsson <swmike@....pp.se>,
	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 12:27:08 -0700
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com> wrote:

> On Sun, Aug 01, 2010 at 08:49:43AM +0200, Mikael Abrahamsson wrote:
> > 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.
> 
> Good points in both this and your earlier post!!!
> 
> > 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.
> 
> This is a good point.  Within some limits, the timer-aggregation
> changes that have gone into Linux can handle this, but I am not sure
> whether or not 180 seconds is within the reasonable boundaries for
> timer jitter.

this is why operating systems for mobile devices offer heartbeat
services... where apps subscribe to and do background work like
checking email at "convenient" times.

I'm not sure if the OS you use on your desktop has one, but MeeGo and
Maemo and I'm pretty sure Android and most other mobile Linux OSes have
one. It's a higher level activity alignment layer, well above the
kernel.


-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org
--
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/

Powered by blists - more mailing lists