Lets make wifi fast again!
 help / color / mirror / Atom feed
From: Luca Muscariello <luca.muscariello@gmail.com>
To: "Toke Høiland-Jørgensen" <toke@toke.dk>
Cc: "make-wifi-fast@lists.bufferbloat.net"
	<make-wifi-fast@lists.bufferbloat.net>
Subject: Re: [Make-wifi-fast] Thoughts on tackling airtime fairness
Date: Wed, 11 May 2016 17:33:24 +0200	[thread overview]
Message-ID: <CAHx=1M7dX_p80TZjYNJe44+x+QGerzSC8uUg8yiQ1MR5XSuCGA@mail.gmail.com> (raw)
In-Reply-To: <874ma4ljfz.fsf@toke.dk>

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

What I did was just a hack to demonstrate the principle. Today 802.11n is
very different assuming you only use HT.
The APware project at MIT will give you some good hints.

Short term fairness was bad, long term fairness very good.

Short term I believe is very difficult to achieve because of the EDCF.
Short term fairness can be very good only using time slotted MAC.


On Wednesday, 11 May 2016, Toke Høiland-Jørgensen <toke@toke.dk> wrote:

> Luca Muscariello <luca.muscariello@gmail.com <javascript:;>> writes:
>
> >  Do you happen to recall what precision you achieved or how much the
> >  precision was really important? Several papers seem to assume that very
> >  high precision is not terribly important since it all evens out in the
> >  end, and I can see how that could be true; but would like to have it
> >  confirmed :)
> >
> > what do you mean with precision?
> > Do you mean in measuring the PHY rate?
> > Short term vs long term measurements? else?
>
> Yes, in measuring the rate. Was this a per-packet thing, and were you
> actually able to get information sufficiently accurate to achieve the
> desired level of fairness? And by what mechanism? Was this in the driver
> or higher up in the stack?
>
> > The hard part was adaptiveness. Correlation between the speed of the
> > STA, the PHY rate controller and quanta updates in SFQ.
>
> Yes, that's what I though :)
>
> > Ideally we were trying to approach something like
> > downlink channel scheduling in HSDPA where you have slotted time TX
> > and polling. A slot in HSDPA (but also LTE) is a burst  of fixed time
> size of several packets.
> > Similar to what you want to achieve in your email point 1.
>
> Yeah, if we could just switch to TDMA a lot of things would be much
> simpler...
>
> > As a side note, there are several differences in aggregates in 802.11n
> > and HSDPA/LTE as in the latter the scheduler can send an aggregate
> > containing packets using different modulation/coding schemes to reach
> > different stations with a single aggregate transmission.
>
> Neat.
>
> > For the records, this feature was rejected in the 802.11n amendement
> > but discussed by the group as it makes the chip more expensive.
>
> Right; not terribly surprised, but still a shame.
>
> -Toke
>

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

  parent reply	other threads:[~2016-05-11 15:33 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-11 12:19 Toke Høiland-Jørgensen
2016-05-11 12:55 ` Luca Muscariello
2016-05-11 13:45   ` Toke Høiland-Jørgensen
2016-05-11 14:48     ` Luca Muscariello
2016-05-11 15:10       ` Toke Høiland-Jørgensen
2016-05-11 15:17         ` David Lang
2016-05-11 15:20           ` David Lang
2016-05-11 15:28             ` Toke Høiland-Jørgensen
2016-05-11 15:33         ` Luca Muscariello [this message]
2016-05-11 16:19           ` Dave Taht
2016-05-11 16:29             ` Dave Taht
2016-05-11 16:40               ` Toke Høiland-Jørgensen
2016-05-11 16:33             ` Luca Muscariello
2016-05-11 15:07     ` David Lang
2016-05-12 15:59     ` Dave Taht
2016-05-11 15:04   ` David Lang
2016-05-11 16:09     ` Luca Muscariello
2016-05-11 16:41       ` Dave Taht
2016-05-11 18:13         ` Dave Taht
2016-05-12  7:26           ` Michal Kazior
2016-05-12  8:21           ` Luca Muscariello
2016-05-12  8:40             ` David Lang
2016-05-12  8:48               ` Michal Kazior
2016-05-11 18:28         ` Luca Muscariello
2016-05-11 18:35           ` Luca Muscariello
2016-05-11 15:03 ` David Lang
2016-05-11 15:15   ` Toke Høiland-Jørgensen
2016-05-11 15:24     ` David Lang
2016-05-11 16:35     ` moeller0
2016-05-11 23:25       ` David Lang
2016-05-12  6:41         ` moeller0

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/make-wifi-fast.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHx=1M7dX_p80TZjYNJe44+x+QGerzSC8uUg8yiQ1MR5XSuCGA@mail.gmail.com' \
    --to=luca.muscariello@gmail.com \
    --cc=make-wifi-fast@lists.bufferbloat.net \
    --cc=toke@toke.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox