Re: [Make-wifi-fast] [PATCH v3 3/6] mac80211: Add airtime accounting and scheduling to TXQs

[Simon Barber <simon@superduper.net>]

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

Low-e glass, it’s a thin metallic film used to reflect infra-red to keep heat in or out. Totally blocks/reflects RF.

Simon

> On Nov 19, 2018, at 4:20 PM, Ben Greear <greearb@candelatech.com> wrote:
> 
> On 11/19/2018 04:13 PM, Dave Taht wrote:
>> On Mon, Nov 19, 2018 at 3:56 PM Ben Greear <greearb@candelatech.com> wrote:
>>> 
>>> On 11/19/2018 03:47 PM, Dave Taht wrote:
>>>> On Mon, Nov 19, 2018 at 3:30 PM Simon Barber <simon@superduper.net> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>> On Nov 19, 2018, at 2:44 PM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>>>>> 
>>>>> Dave Taht <dave@taht.net> writes:
>>>>> 
>>>>> Toke Høiland-Jørgensen <toke@toke.dk> writes:
>>>>> 
>>>>> Felix Fietkau <nbd@nbd.name> writes:
>>>>> 
>>>>> On 2018-11-14 18:40, Toke Høiland-Jørgensen wrote:
>>>>> 
>>>>> This part doesn't really make much sense to me, but maybe I'm
>>>>> misunderstanding how the code works.
>>>>> Let's assume we have a driver like ath9k or mt76, which tries to keep a
>>>>> 
>>>>> ….
>>>>> 
>>>>> 
>>>>> Well, there's going to be a BQL-like queue limit (but for airtime) on
>>>>> top, which drivers can opt-in to if the hardware has too much queueing.
>>>>> 
>>>>> 
>>>>> Very happy to read this - I first talked to Dave Taht about the need for Time Queue Limits more than 5 years ago!
>>>> 
>>>> Michal faked up a dql estimator 3 (?) years ago. it worked.
>>>> 
>>>> http://blog.cerowrt.org/post/dql_on_wifi_2/
>>>> 
>>>> As a side note, in *any* real world working mu-mimo situation at any
>>>> scale, on any equipment, does anyone have any stats on how often the
>>>> feature is actually used and useful?
>>>> 
>>>> My personal guess, from looking at the standard, was in home
>>>> scenarios, usage would be about... 0, and in a controlled environment
>>>> in a football stadium, quite a lot.
>>>> 
>>>> In a office or apartment complex, I figured interference and so forth
>>>> would make it a negative benefit due to retransmits.
>>>> 
>>>> I felt when that part of the standard rolled around... that mu-mimo
>>>> was an idea that should never have escaped the lab. I can be convinced
>>>> by data, that we can aim for a higher goal here. But it would be
>>>> comforting to have a measured non-lab, real-world, at real world
>>>> rates, result for it, on some platform, of it actually being useful.
>>> 
>>> We're working on building a lab with 20 or 30 mixed 'real' devices
>>> using various different /AC NICs (QCA wave2 on OpenWRT, Fedora, realtek USB 8812au on OpenWRT, Fedora,
>>> and some Intel NICs in NUCs on Windows, and maybe more).  I'm not actually sure if that realtek
>>>  or the NUCs can do MU-MIMO or not, but the QCA NICs will be able to.  It should be at least somewhat similar
>>> to a classroom environment or coffee shop.
>> 
>> In the last 3 coffee shops I went to, I could hear over 30 APs on
>> competing SSIDs, running G, N, and AC,
>> occupying every available channel.
> 
> I especially like when someone uses channel 3 because, I guess, they
> think it is un-used :)
> 
> I'm not sure if this was a fluke or not, but at Starbucks recently I sat outside,
> right next to their window, and could not scan their AP at all.  Previously, I sat
> inside, 3 feet away through the glass, and got great signal.  I wonder what that was
> all about!  Maybe special tinting that blocks RF?  Or just dumb luck of some sort.
> 
> Thanks,
> Ben
> 
> 
> -- 
> Ben Greear <greearb@candelatech.com <mailto:greearb@candelatech.com>>
> Candela Technologies Inc  http://www.candelatech.com <http://www.candelatech.com/>

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