Re: Attempted summary of suspend-blockers LKML thread

[Paul E. McKenney]

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.

Of course, the timers might be synchronized upon wakeup after a
sufficiently long suspension, but they would not necessarily stay
synchronized without the help of some other mechanism, such as the
afore-mentioned timer-aggregation changes.

						Thanx, Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/