From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (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 8695E3B2A4 for ; Sat, 9 Jun 2018 11:33:19 -0400 (EDT) Received: by mail-oi0-x232.google.com with SMTP id e8-v6so14417855oii.2 for ; Sat, 09 Jun 2018 08:33:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=0EZ/tTf8Fal/aU9P9eZhWxBr8pJ2ccHaku8d0BxvR7I=; b=A0v0V8yyi1cwfwY9JCvwPcWqkvhc9oc7isk93oThT7brjQSgAEi0/yVIp2zJO8kbG1 An+vezmrROCkW4ruOaXFvvne08F4uCKquRuym0j3s3XF91TFNlgiQ8WaLA4QBzrHQwwC Ks2qWRo3sVmUF/ol+EZedK3ClfwkqrkBc56Kzpq/kOg5Gsh8VClaAcvI7NqP8UuGCgFw DZIeVNtO3vQnv0NML8u/L67C1OaxKMFFZulZm6JBCPqoiUtv3Qun1y1VeSSIrD4Cg5Ot yUOZmQ+QC7wPdhfabSkguoXHzMhSTQK4cIXt4EX/qKo7nzsOtyK1j/1TG1LaHSpbc97Z hlnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=0EZ/tTf8Fal/aU9P9eZhWxBr8pJ2ccHaku8d0BxvR7I=; b=b3JA7u88V7G86nmJ81vaklxF1B2Y3/ppOBr3l1pT67R7u3MUGnnVoeIWJzmxds3VZ+ ek5gNUF6NDeTuRPzZEPnCKhOG2BcipiKAArMbRyWDtPH7C+Q8qvqQx1EMnoXMLa+5sNw yJlTvhmEZ4wXDLl4P4djs+fpJypN/TesouYmW5C5D21U2e8cScRidvL2ixPROgvXY9lP NEnJqcTuRZRwSulufY3BgXXCZuQPI8TMBnqPuEcoR21WVD7gaIXDXA2dNDswuEqS9L0E KwplE1Zl5e7IxCVGFnFLZ0B8l7JBYun4kbrrblat8YgK0RlhmG8K2UcDNbfhs5yT1PLx 1ZUg== X-Gm-Message-State: APt69E3BLag7iNN5N2LNeLuWKvZ0rKm8Kt+GU1GWvAvOzvQzx0eRH5ZK m0mXCttLTge6GCcDhoekXo9evDkgPpCPdz+O+JsO4w== X-Google-Smtp-Source: ADUXVKIo6QEmsMbphI5HSC7RO2b1cimfcwOI1rn/gxTtrmOPtyWl7CrlRF8a+k+LeMF01MVIqUPK6ky2jI6VnTXLk6c= X-Received: by 2002:aca:3c02:: with SMTP id j2-v6mr687079oia.238.1528558398737; Sat, 09 Jun 2018 08:33:18 -0700 (PDT) MIME-Version: 1.0 Sender: bkil.hu@gmail.com Received: by 2002:a9d:1d28:0:0:0:0:0 with HTTP; Sat, 9 Jun 2018 08:32:58 -0700 (PDT) In-Reply-To: References: From: bkil Date: Sat, 9 Jun 2018 17:32:58 +0200 X-Google-Sender-Auth: uPiHq3nxLk2p_ivPmsS4NAM52w0 Message-ID: To: Pete Heist Cc: David Lang , make-wifi-fast@lists.bufferbloat.net Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Make-wifi-fast] mesh deployment with ath9k driver changes 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: Sat, 09 Jun 2018 15:33:19 -0000 Hello, That's nice. You would probably get most of the benefits already if you could manage to prune B/G rates. You're right in that pruning the N rates is a different question. I think it is good enough already to allow G >=3D 12Mb/s and N >=3D MCS-0. Using N rates by itself would also enable all the benefits of LDPC, STBC, aggregation, (beam forming) and other goodies your chipsets could offer, thereby freeing up your spectrum some more. legacy_rates=3D0 seems to be an alias for enabling all g-rates and disabling b-rates: https://github.com/lede-project/source/blob/69f544937f8498e856690f9809a016f= 0d7f5f68b/package/network/services/hostapd/files/hostapd.sh#L110 So this should be the way to go in your device section: option hwmode g option htmode HT20 # probably already set option distance 450 # minimal coverage option beacon_int 200 # power/bandwidth saving option basic_rate '12000 24000' option supported_rates '12000 18000 24000 36000 48000 54000' ... (some other options automatically generated) I also add these to the interface section: option isolate 1 # intra-BSS option dtim_period 5 # cheap power saving Although I've seen a site where they mention that pruning N rates (and announcing a strange restricted set in the beacons) could cause issues with some drivers, they didn't say which specific drivers or devices had this issue. Maybe it was just a rule of thumb of theirs. Anyway, wpa_supplicant has a setting for this as well (ht_mcs): https://github.com/helmut-jacob/hostapd/blob/a35e34106723eb0b23df9114364d6f= bc46fffab6/wpa_supplicant/wpa_supplicant.conf#L893 https://github.com/helmut-jacob/hostapd/blob/a35e34106723eb0b23df9114364d6f= bc46fffab6/wpa_supplicant/config_ssid.h#L551 So some higher level patching might also be possible to enable hostapd doing the same. Although the effect is not entirely the same, it is already possible to instruct the AP TX to use only the higher rates (except for lookaround) by running these after wifi is up (in conjunction with the config above): iw dev wlan0 set bitrates # clear mask iw dev wlan0 set bitrates legacy-2.4 12 18 24 36 48 54 ht-mcs-2.4 1 2 3 4 5 6 7 # ... up to max MCS Regarding isolation, correct me if I'm wrong, but ap_isolate in hostapd should be at another level and is enabled default, so it is also a good idea to disable it: # Client isolation can be used to prevent low-level bridging of frames betw= een # associated stations in the BSS. By default, this bridging is allowed. # https://w1.fi/cgit/hostap/plain/hostapd/hostapd.conf This came up on the forums as well recently: https://forum.lede-project.org/t/how-to-prevent-guest-network-clients-to-co= mmunicate-with-each-other/14831 Could you please verify that when you connect two devices to the same AP, they can't reach each other? (firewalls put aside) Even disabling local broadcasts could help a bit if you say that complete isolation is not feasible. Not sure if the said campers have already arrived, but SmokePing stats for today had greatly improved compared to the previous days. We'll see after a few more days, but it's good to know that you still have some more options to tweak. It would be great if OpenWrt shipped with 802.11b disabled by default and let the user decide whether she wants to enable it for legacy users. I haven't encountered a 802.11b-only device in many years, and they say that >95% of clients are already N/AC capable. Regards On Fri, Jun 8, 2018 at 11:37 AM, Pete Heist wrote: > > On May 31, 2018, at 2:52 AM, David Lang wrote: > > On Sat, 19 May 2018, bkil wrote: > > In reply to this thread: > https://lists.bufferbloat.net/pipermail/make-wifi-fast/2018-April/001787.= html > > Sorry for the late response, although I can see from yesterday's > SmokePing plots that the issue still prevails. > > 1. > You should definitely not allow rates as low as 1Mb/s considering: > * plots of signal vs. rate, > * topology of closely packed cabins; > * mostly static, noise-free camp ground. > > Almost all of your clients were able to link with >20Mb/s even at > 70-80dBm. Those below were probably just idling. I'd limit the network > to 802.11g/n-only, and would even consider disabling all rates below > 12Mb/s. > > > I have been wanting to do this on my APs for Scale (wndr3800 APs with ath= 9k > chipsets) and have been unable to find how to do this on these chipsets. > > > I also didn=E2=80=99t manage to disable specific MCS rates: > - supported_rates and basic_rate in /etc/config/wireless seem to only aff= ect > legacy rates, not ht-mcs-2.4 rates. > - "iw dev wlan0 set bitrates=E2=80=9D only sets the transmit rate for the= AP > > But what I did do at 10:45am today, June 8, was disable 802.11b rates wit= h: > > uci set wireless.radio0.legacy_rates=3D=E2=80=980' > uci commit > reboot > > So at least the minimum rate should be limited to 6Mbit. We=E2=80=99ll se= e if this > helps in the next few days as the camp fills, and if I hear any complaint= s: > > https://www.drhleny.cz/smokeping/ > -- If you need an encryption key / ha kell titkos=C3=ADt=C3=B3 kulcs: http://bkil.blogspot.hu/2014/08/public-key.html On Fri, Jun 8, 2018 at 11:37 AM, Pete Heist wrote: > > On May 31, 2018, at 2:52 AM, David Lang wrote: > > On Sat, 19 May 2018, bkil wrote: > > In reply to this thread: > https://lists.bufferbloat.net/pipermail/make-wifi-fast/2018-April/001787.= html > > Sorry for the late response, although I can see from yesterday's > SmokePing plots that the issue still prevails. > > 1. > You should definitely not allow rates as low as 1Mb/s considering: > * plots of signal vs. rate, > * topology of closely packed cabins; > * mostly static, noise-free camp ground. > > Almost all of your clients were able to link with >20Mb/s even at > 70-80dBm. Those below were probably just idling. I'd limit the network > to 802.11g/n-only, and would even consider disabling all rates below > 12Mb/s. > > > I have been wanting to do this on my APs for Scale (wndr3800 APs with ath= 9k > chipsets) and have been unable to find how to do this on these chipsets. > > > I also didn=E2=80=99t manage to disable specific MCS rates: > - supported_rates and basic_rate in /etc/config/wireless seem to only aff= ect > legacy rates, not ht-mcs-2.4 rates. > - "iw dev wlan0 set bitrates=E2=80=9D only sets the transmit rate for the= AP > > But what I did do at 10:45am today, June 8, was disable 802.11b rates wit= h: > > uci set wireless.radio0.legacy_rates=3D=E2=80=980' > uci commit > reboot > > So at least the minimum rate should be limited to 6Mbit. We=E2=80=99ll se= e if this > helps in the next few days as the camp fills, and if I hear any complaint= s: > > https://www.drhleny.cz/smokeping/ >