From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bifrost.lang.hm (lang.hm [66.167.227.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id AE1033B260 for ; Thu, 12 May 2016 04:40:58 -0400 (EDT) Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id u4C8etqW030061; Thu, 12 May 2016 01:40:55 -0700 Date: Thu, 12 May 2016 01:40:55 -0700 (PDT) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: Luca Muscariello cc: Dave Taht , "make-wifi-fast@lists.bufferbloat.net" In-Reply-To: Message-ID: References: <871t58n5wk.fsf@toke.dk> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: Re: [Make-wifi-fast] Thoughts on tackling airtime fairness X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 08:40:59 -0000 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 wrote: > >> On Wed, May 11, 2016 at 9:41 AM, Dave Taht wrote: >>> On Wed, May 11, 2016 at 9:09 AM, Luca Muscariello >>> 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... >> >