From: David Lang <david@lang.hm>
To: Luca Muscariello <luca.muscariello@gmail.com>
Cc: Dave Taht <dave.taht@gmail.com>,
"make-wifi-fast@lists.bufferbloat.net"
<make-wifi-fast@lists.bufferbloat.net>
Subject: Re: [Make-wifi-fast] Thoughts on tackling airtime fairness
Date: Thu, 12 May 2016 01:40:55 -0700 (PDT) [thread overview]
Message-ID: <alpine.DEB.2.02.1605120135320.2408@nftneq.ynat.uz> (raw)
In-Reply-To: <CAHx=1M6AshUft2HMDnPQum=AaYR=JTVU6tTV=Z2anbcNyr0Zzg@mail.gmail.com>
I actually have hopes that it will help in the (fairly common) case of multiple
stations streaming video from the Internet at the same time. If the AP ->
endpoint traffic can send to multiple stations in the same txop, it can greatly
reduce the amount of airtime needed.
unfortunantly, from what I hear, the factory AP firmware breaks down if there
are more than about a dozen stations connected, just as it becomes the most
valuable.
But to make it work, we can't have two layers of buffering, we need the firmware
to be able to grab several aggregates worth of data from different queues, and
some of the data grabbed may be an 'unfair' share for that source, but it should
still be grabbed because there is nothing else that could be sent at the same
time, so the transmission is effectively free.
but to do that sort of thing, we really need to be operating close to the
hardware, not with some firmware buffers between us.
David Lang
On Thu, 12 May 2016, Luca Muscariello wrote:
> I share your skepticism about beam forming. It depends of course on the kind
> of usage you make of wifi. If it's to cover a city in a small cell
> optimized deployment
> I don't think beam forming is going to help. When cell traffic is high only
> TDMA can help.
>
> If you use beam forming to reach non mobile users and traffic is not to
> high it's going to
> give best performance.
>
> Both are valuable use cases with economic incentives behind.
> The first one is more difficult and time fairness is gonna help a lot there
> as the average cell throughput is gonna be a lot better.
>
>
>
> On Wed, May 11, 2016 at 8:13 PM, Dave Taht <dave.taht@gmail.com> wrote:
>
>> On Wed, May 11, 2016 at 9:41 AM, Dave Taht <dave.taht@gmail.com> wrote:
>>> On Wed, May 11, 2016 at 9:09 AM, Luca Muscariello
>>> <luca.muscariello@gmail.com> wrote:
>>>> Correct, but in between that time and now a lot has been done in
>> different
>>>> areas but not much on this point.
>>>> The fact that some part of the industry is looking at LTE-U is also
>> because
>>>> 802.11 standard is not good enough.
>>>
>>> What do you think of LTE-LAA?
>>>
>>> I do think very strongly that actual usage of 802.11 can be made
>>> vastly more efficient, that we can use up a great deal of the mac
>>> currently being left unused, and schedule txops way more efficiently -
>>> and that I'd love to test with michal's patch set against the LTE-U
>>> tests cablelabs, etc which did
>>>
>>> 100 stations before (stock):
>>>
>>> http://blog.cerowrt.org/flent/drr/10tothe5.svg
>>>
>>> after
>>>
>>> http://blog.cerowrt.org/flent/drr/newcode.svg
>>
>> Seeing "only" 250ms worth of delay for 100 stations here was what
>> kicked off a prior thread, my understanding of a theoretical base
>> number here would be about 70ms. (?)
>>
>
> I miss many details about these tests. And probably I missed the thread...
> Can you give me pointers?
>
>
>
>>
>> ...
>>
>> Adding in mu-mimo to the picture makes my head hurt. My understanding
>> of how mu-mimo is supposed to work is you have to have accumulated
>> 2-3ms worth of packets for the number of stations you are going to
>> schedule before it's worthwhile at all.
>>
>> The stations are going to typically be limited to 1 antenna (most
>> laptops have 2), I think. So a 4 antenna system *could* send to 4
>> stations if all have traffic pending... at a cost of a (proposed, I
>> don't agree with it) 500 usec sounding phase every 10ms. My take on
>> that is you should only sound when you actually have some potential to
>> share that many flows to that many stations, sounding being more of an
>> aspect of rate control, also.
>>
>> Having only 2 stations that you can mu-mimo to seems like a lose generally.
>>
>> Based on normal traffic behaviors the stations that could be sent to
>> varies, and gang scheduling with lots of stations would require even
>> more soundings...
>>
>> ...
>>
>> I don't have a lot of hope for mu-mimo, although what I kind of expect
>> is the work done here will end up marketed as due to that feature in
>> the wave2 stuff...
>>
>
next prev parent reply other threads:[~2016-05-12 8:40 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
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 [this message]
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=alpine.DEB.2.02.1605120135320.2408@nftneq.ynat.uz \
--to=david@lang.hm \
--cc=dave.taht@gmail.com \
--cc=luca.muscariello@gmail.com \
--cc=make-wifi-fast@lists.bufferbloat.net \
/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