* [Make-wifi-fast] the wifi airtime-fair fq_codel stuff on net-next looks mostly good
@ 2016-10-12 15:18 Dave Taht
2016-10-12 15:32 ` Jim Gettys
0 siblings, 1 reply; 5+ messages in thread
From: Dave Taht @ 2016-10-12 15:18 UTC (permalink / raw)
To: make-wifi-fast, bloat
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Make-wifi-fast] the wifi airtime-fair fq_codel stuff on net-next looks mostly good
2016-10-12 15:18 [Make-wifi-fast] the wifi airtime-fair fq_codel stuff on net-next looks mostly good Dave Taht
@ 2016-10-12 15:32 ` Jim Gettys
2016-10-12 15:46 ` Dave Taht
0 siblings, 1 reply; 5+ messages in thread
From: Jim Gettys @ 2016-10-12 15:32 UTC (permalink / raw)
To: Dave Taht; +Cc: make-wifi-fast, bloat
[-- 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 --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Make-wifi-fast] the wifi airtime-fair fq_codel stuff on net-next looks mostly good
2016-10-12 15:32 ` Jim Gettys
@ 2016-10-12 15:46 ` Dave Taht
2016-10-15 7:24 ` [Make-wifi-fast] [Bloat] " Mikael Abrahamsson
0 siblings, 1 reply; 5+ messages in thread
From: Dave Taht @ 2016-10-12 15:46 UTC (permalink / raw)
To: Jim Gettys; +Cc: make-wifi-fast, bloat
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Make-wifi-fast] [Bloat] the wifi airtime-fair fq_codel stuff on net-next looks mostly good
2016-10-12 15:46 ` Dave Taht
@ 2016-10-15 7:24 ` Mikael Abrahamsson
2016-10-15 7:59 ` [Make-wifi-fast] " Luca Muscariello
0 siblings, 1 reply; 5+ messages in thread
From: Mikael Abrahamsson @ 2016-10-15 7:24 UTC (permalink / raw)
To: Dave Taht; +Cc: make-wifi-fast, bloat
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Make-wifi-fast] the wifi airtime-fair fq_codel stuff on net-next looks mostly good
2016-10-15 7:24 ` [Make-wifi-fast] [Bloat] " Mikael Abrahamsson
@ 2016-10-15 7:59 ` Luca Muscariello
0 siblings, 0 replies; 5+ messages in thread
From: Luca Muscariello @ 2016-10-15 7:59 UTC (permalink / raw)
To: Mikael Abrahamsson; +Cc: Dave Taht, make-wifi-fast, bloat
[-- 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 --]
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2016-10-15 7:59 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-10-12 15:18 [Make-wifi-fast] the wifi airtime-fair fq_codel stuff on net-next looks mostly good Dave Taht
2016-10-12 15:32 ` Jim Gettys
2016-10-12 15:46 ` Dave Taht
2016-10-15 7:24 ` [Make-wifi-fast] [Bloat] " Mikael Abrahamsson
2016-10-15 7:59 ` [Make-wifi-fast] " Luca Muscariello
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox