From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-f194.google.com (mail-pf1-f194.google.com [209.85.210.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 8B7903BA8E for ; Mon, 19 Nov 2018 19:52:33 -0500 (EST) Received: by mail-pf1-f194.google.com with SMTP id u3-v6so116808pfm.4 for ; Mon, 19 Nov 2018 16:52:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=YJZ8f3Ck3QbzbzvOgd9jmPGhcYw7zyOlUml0LfUjur8=; b=C4udASpAohZwKBW63PyN9UnLdtSXL/EE070J12Lv/gw7obmfMnmUBV2/t0+nf6/MV+ hFc7TRuhzTwNXrI5mOYS5rTRaga48SKJNvHWgtYhtXbSyeNhmaj/e8unD37gT+DcS1xa 8W9Vh/89yLf4URwVagJ+fYpw5yKMdRTaPGpf8/qQJ+/9nZ1xFVYGHu00Twe5FJtvOxpt yap4fIw+ekpDOYwUcmLPeTm2S6zMQWgu4GWubwwgG4eIx/3dvqiXbL5a8cuj58bRrRsk CqWzmPypBk1ScPxNlPbp1Wn/JAYNYL328c4OfSlGjTIHB6RrvifufpzH0HnV0yLw9A1/ WDTA== X-Gm-Message-State: AGRZ1gITjCOLKucS3d4/LdXB3sFSkRUJjXx0hZjG1cXcnaIlIAflWeYD RjTUXYapl1Lm9bGOQu8QsqU= X-Google-Smtp-Source: AJdET5f+eHmD/QEQDKagSS3nu9cpWhrKBokAHjvI02J/0GRiZS8kz22A//pVDTiXNDidpmtdSiD27A== X-Received: by 2002:a63:eb52:: with SMTP id b18mr21632110pgk.213.1542675152531; Mon, 19 Nov 2018 16:52:32 -0800 (PST) Received: from jkreiss-x250.corp.meraki.com (192-195-83-200.static.monkeybrains.net. [192.195.83.200]) by smtp.gmail.com with ESMTPSA id q35sm28555427pgk.12.2018.11.19.16.52.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Nov 2018 16:52:31 -0800 (PST) From: Simon Barber Message-Id: <46F43681-DF84-4E08-9426-328BA7AE1CED@superduper.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_45932A96-F115-4643-991C-3002457E964A" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Mon, 19 Nov 2018 16:52:28 -0800 In-Reply-To: <6beaeb84-b705-335b-93a7-36176495099b@candelatech.com> Cc: Dave Taht , =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , Rajkumar Manoharan , Make-Wifi-fast , linux-wireless , ath10k , Felix Fietkau To: Ben Greear References: <1542063113-22438-1-git-send-email-rmanohar@codeaurora.org> <1542063113-22438-4-git-send-email-rmanohar@codeaurora.org> <871s7nv9pl.fsf@toke.dk> <8e7847ff-4c88-10ae-2223-2fc7321641d9@nbd.name> <87sh02tfsp.fsf@toke.dk> <878t1p2bqz.fsf@taht.net> <87muq4sn50.fsf@toke.dk> <4DD985B6-7DBE-42F8-AC87-D6B40CEAE553@superduper.net> <6beaeb84-b705-335b-93a7-36176495099b@candelatech.com> X-Mailer: Apple Mail (2.3445.6.18) Subject: Re: [Make-wifi-fast] [PATCH v3 3/6] mac80211: Add airtime accounting and scheduling to TXQs 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: Tue, 20 Nov 2018 00:52:33 -0000 --Apple-Mail=_45932A96-F115-4643-991C-3002457E964A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Low-e glass, it=E2=80=99s 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 = wrote: >=20 > On 11/19/2018 04:13 PM, Dave Taht wrote: >> On Mon, Nov 19, 2018 at 3:56 PM Ben Greear = wrote: >>>=20 >>> On 11/19/2018 03:47 PM, Dave Taht wrote: >>>> On Mon, Nov 19, 2018 at 3:30 PM Simon Barber = wrote: >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Nov 19, 2018, at 2:44 PM, Toke H=C3=B8iland-J=C3=B8rgensen = wrote: >>>>>=20 >>>>> Dave Taht writes: >>>>>=20 >>>>> Toke H=C3=B8iland-J=C3=B8rgensen writes: >>>>>=20 >>>>> Felix Fietkau writes: >>>>>=20 >>>>> On 2018-11-14 18:40, Toke H=C3=B8iland-J=C3=B8rgensen wrote: >>>>>=20 >>>>> 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 >>>>>=20 >>>>> =E2=80=A6. >>>>>=20 >>>>>=20 >>>>> 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. >>>>>=20 >>>>>=20 >>>>> Very happy to read this - I first talked to Dave Taht about the = need for Time Queue Limits more than 5 years ago! >>>>=20 >>>> Michal faked up a dql estimator 3 (?) years ago. it worked. >>>>=20 >>>> http://blog.cerowrt.org/post/dql_on_wifi_2/ >>>>=20 >>>> 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? >>>>=20 >>>> 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. >>>>=20 >>>> In a office or apartment complex, I figured interference and so = forth >>>> would make it a negative benefit due to retransmits. >>>>=20 >>>> 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. >>>=20 >>> 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. >>=20 >> 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. >=20 > I especially like when someone uses channel 3 because, I guess, they > think it is un-used :) >=20 > 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. >=20 > Thanks, > Ben >=20 >=20 > --=20 > Ben Greear > > Candela Technologies Inc http://www.candelatech.com = --Apple-Mail=_45932A96-F115-4643-991C-3002457E964A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Low-e= glass, it=E2=80=99s 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=C3=B8iland-J=C3=B8rgensen <toke@toke.dk> wrote:

Dave Taht <dave@taht.net> writes:

Toke= H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk> writes:

Felix= Fietkau <nbd@nbd.name> writes:

On = 2018-11-14 18:40, Toke H=C3=B8iland-J=C3=B8rgensen 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

=E2=80=A6.


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>
Candela Technologies Inc  http://www.candelatech.com

= --Apple-Mail=_45932A96-F115-4643-991C-3002457E964A--