[Make-wifi-fast] Thoughts on tackling airtime fairness
dave.taht at gmail.com
Wed May 11 12:29:18 EDT 2016
On Wed, May 11, 2016 at 9:19 AM, Dave Taht <dave.taht at gmail.com> wrote:
> My own foci are going to be around trying to rip every source of
> potential latency out of the current system: be it deferred
> interrupts, bad rate control information, overlong txops, excessive
> retries, insufficient packet loss, busting the block ack window, and
> quashing stations grabbing too much airtime...
and oh, yea, queuing delay. :)
> and then adding back in "bandwidth" from there. We have enough
> bandwidth in wifi nowadays, just now narrow enough time slices to feed
> many stations sanely.
Bandwidth = rate/interval. Humans have a terrible tendency to using
big intervals, like seconds... I'd like to focus on calculating
bandwidth as rate/(minimal achievable txop under contention) rather
> a somewhat subtle distinction is that aiming for airtime fairness
> independently of the behaviors of real traffic is not a goal (for me).
> A system handing out 8 stations 8ms each of airtime is "fair", but
> handing out 1ms each - or just enough, for example, for my
> videoconferencing flow to handle each frame with a single txop - or
> getting a new station started faster on some web traffic - is better.
> Certainly there is a ton of low hanging fruit to excise, and achieving
> something closer to
airtime fairness is *great*
but we ignore multicast, channel scans, and other
> oddities to our peril.
> I don't, for example, think that aiming for airtime fairness over 1sec
> intervals is good, 20-50ms would be way more desirable. And so on.
> Getting a good rate control estimate by the second txop used by a
> previously idle station would be good. And so on.
> this message brought to you from the association for more coffee in the morning.
losing the www.bufferbloat.net server was not helpful, I'd just booked
a vacation ticket.
Let's go make home routers and wifi faster! With better software!
More information about the Make-wifi-fast