[Make-wifi-fast] the wifi airtime-fair fq_codel stuff on net-next looks mostly good

[Make-wifi-fast] the wifi airtime-fair fq_codel stuff on net-next looks mostly good

[Dave Taht]

Which I just wrote up here:

http://blog.cerowrt.org/post/real_results/

Warning: includes a dancing cat video!

My principal goal was to make sure *they didn't crash*, and I got
carried away.  .. we seem to have a problem with the local TCP stack
in some cases and I went through some hell with OSX discussed in
earlier blog entries.

Everybody else (hopefully) took a 3 day holiday this past weekend. I'm
taking one.... starting now.

Re: [Make-wifi-fast] the wifi airtime-fair fq_codel stuff on net-next looks mostly good

[Jim Gettys]

[-- Attachment #1: Type: text/plain, Size: 816 bytes --]

All I can say is I bow down to your persistence...

Congratulations!
                              - Jim


On Wed, Oct 12, 2016 at 11:18 AM, Dave Taht <dave.taht@gmail.com> wrote:

> Which I just wrote up here:
>
> http://blog.cerowrt.org/post/real_results/
>
> Warning: includes a dancing cat video!
>
> My principal goal was to make sure *they didn't crash*, and I got
> carried away.  .. we seem to have a problem with the local TCP stack
> in some cases and I went through some hell with OSX discussed in
> earlier blog entries.
>
> Everybody else (hopefully) took a 3 day holiday this past weekend. I'm
> taking one.... starting now.
> _______________________________________________
> Make-wifi-fast mailing list
> Make-wifi-fast@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>

[-- Attachment #2: Type: text/html, Size: 1745 bytes --]

Re: [Make-wifi-fast] the wifi airtime-fair fq_codel stuff on net-next looks mostly good

[Dave Taht]

On Wed, Oct 12, 2016 at 8:32 AM, Jim Gettys <jg@freedesktop.org> wrote:
> All I can say is I bow down to your persistence...

The .debs are airtime-8 for a reason. I kept bisecting until I
bothered to boot into a normal kernel and realized that my main test
box had broken in the move during the loma prieta fire. I can show you
some really horrible graphs of what happens to wifi under stress with
no antennas attached....

> Congratulations!

Thx. I'm logging out for a few days. Toke's giving a talk wednesday...

http://openwrtsummit.org/#quick-details

>                               - Jim

Re: [Make-wifi-fast] [Bloat] the wifi airtime-fair fq_codel stuff on net-next looks mostly good

[Mikael Abrahamsson]

On Wed, 12 Oct 2016, Dave Taht wrote:

> http://openwrtsummit.org/#quick-details

I've had the discussion with "radio guys" before regarding "fairness" of 
radio resources. They kept talking about "optimising the cell for 
throughput". I told them "then we should give the speaker with the highest 
bitrate and demand for bits as much radio resources as possible, and 
starve everybody else". This is of course not good for general customer 
satisfaction.

After a lot of discussions back and forth, we came to the same conclusion 
as you seem to have come to (if I understood Tokes talk correctly), in 
that "radio time" is the most fair resource. If someone has bad radio 
conditions then they get lower total throughput than the one with good 
radio conditions, so the fairness is "equal air time". This means 
everybody get equal part of the shared resource, and gives people an 
incentive to try to improve radio reception if they have trouble, and 
doesn't starve everybody else of airtime just because one device is having 
a bad radio day.

So full support for this approach from me, good job!

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

Re: [Make-wifi-fast] the wifi airtime-fair fq_codel stuff on net-next looks mostly good

[Luca Muscariello]

[-- Attachment #1: Type: text/plain, Size: 2456 bytes --]

Air time fairness has a strong theoretical foundation.
So I should cite Newton and say that Toke is sitting on giants' schoulders
:)

In multi rate systems  in a shared channel, time is the right resource to
share.

Then one could discuss about which fairness criterion to use, but that's
secondary.

The criterion used by toke is max-min in time.
I guess this is the best you can do in wifi.
This turns out to be proportional fairness in throughput.

In LTE the shared channel is time shared (slotted)
and fairness is slightly different to max-min in time.

In LTE thanks to the feedback channel, multi user diversity can be used to
schedule transmissions towards the UE with best radio conditions at a given
time.
David Tse showed that this is proportional fairness
with multi user diversity gain. The cell throughout increases
logarithmically with the number of users.
And this is the best criterion for many reasons that I skip here.

This is out of target for wifi but what Toke is doing is really solid.

Luca




On Saturday, 15 October 2016, Mikael Abrahamsson <swmike@swm.pp.se> wrote:

> On Wed, 12 Oct 2016, Dave Taht wrote:
>
> http://openwrtsummit.org/#quick-details
>>
>
> I've had the discussion with "radio guys" before regarding "fairness" of
> radio resources. They kept talking about "optimising the cell for
> throughput". I told them "then we should give the speaker with the highest
> bitrate and demand for bits as much radio resources as possible, and starve
> everybody else". This is of course not good for general customer
> satisfaction.
>
> After a lot of discussions back and forth, we came to the same conclusion
> as you seem to have come to (if I understood Tokes talk correctly), in that
> "radio time" is the most fair resource. If someone has bad radio conditions
> then they get lower total throughput than the one with good radio
> conditions, so the fairness is "equal air time". This means everybody get
> equal part of the shared resource, and gives people an incentive to try to
> improve radio reception if they have trouble, and doesn't starve everybody
> else of airtime just because one device is having a bad radio day.
>
> So full support for this approach from me, good job!
>
> --
> Mikael Abrahamsson    email: swmike@swm.pp.se
> _______________________________________________
> Make-wifi-fast mailing list
> Make-wifi-fast@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>

[-- Attachment #2: Type: text/html, Size: 3419 bytes --]