Re: [RFC PATCHv3 1/2] mac80211: Determine dynamic PS timeout based on ps-qos network latency

[Johannes Berg <johannes@sipsolutions.net>]

On Thu, 2010-04-22 at 11:55 +0300, Juuso Oikarinen wrote:

> > > Well you have to see where I'm coming from - I must come up with a way
> > > to tune the dynamic ps timeout value from user-space in a way that is
> > > agreeable with others, and that is somewhat future-proof.
> > 
> > Well I personally think that's your first mistake ;)
> > 
> > Why does userspace care about the dynamic PS timeout value to start
> > with? All it should care about is the latency with which it can react to
> > network packets, no?
> > 
> > > That said, obviously the network latency should be tuned as, well, the
> > > expected network latency. In this phase though, there are no other
> > > parameters affected by the network latency, so the result is quite
> > > obvious - your fear will realise itself ;)
> > 
> > But there are, like the max sleep period in # of beacons.
> 
> Yeah, okay there is. You probably noticed I posted a version of the
> patches with "saner" latency-values for this reason.

Right.

> I think there is something fishy in the max-sleep-period implementation.
> I don't yet understand it fully, but it seems to me the host is trying
> to set up it's own dtim interval, regardless of what the AP is
> configured with. It seems to me that this could lead to loss of
> broadcast/multicast frames, if the sta is not waking up a AP dtim
> beacons, but instead has its own cycle. But I have to look into this
> deeper at some point, so let's not get caught in this now.

Ah, I guess you can't just use the value we calculate as the real
period, it's just the max. This depends on the device implementation
though. If your device needs to have a value "wake up ever N beacons"
then in fact you cannot use the value but have to use gcd(value, dtim).
But if the device can e.g. "wake up after N, N, N, M beacons" then you
can set N=value, M=dtim_period-3*value or something like that ...

johannes