From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 AF3113B29E for ; Wed, 13 Jun 2018 09:07:47 -0400 (EDT) Received: by mail-wm0-x234.google.com with SMTP id 69-v6so5283572wmf.3 for ; Wed, 13 Jun 2018 06:07:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eventide.io; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=t47N38y8IPIg4dkPzPYdsEPI2J0NQbMzNnITlm2cHKM=; b=L7jLNKZCIk86+vPgy0P9xqkvfGA2wAsENwgkZmFhPdOHNlint0uGOv6dnxccI3RpHt r2PxKdoBac5OVb/mrjwAnRX6nx46Upk5h/Sumpk6XkE1gDNNggaLdIpIrj0YH7ftWpz8 XqZToBhAQIGPRL9yszgmptnlgGIKxogoERZ29e7t4SQw0HAbVQYFwxToY/L9vM41B/Pe Sau8E0q4u6iJWjFRYCLqyAwDadU4k/U/IFHtnD3RYUn7L5GlcY66SKiLRRGPbBW0nhy+ qq9mjC8s1YKp4hiDJHAhcqznplwsP6h3ZA9Yc7/skwGl6NvNFrmw3M38h1EgzoPAUoHD 2pwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=t47N38y8IPIg4dkPzPYdsEPI2J0NQbMzNnITlm2cHKM=; b=IuKlYZ+o/IHY/PWDW2MxMj4S9KVQY8K6DprhYNh+SxpVC0fOpSeabxKC2uYDM39hmL KtHoq+/31vkHuzc2AUKsZYnU4oq61fk+o7el78QwUVJaYBdf+4JE0P17LhmxpBeVcIzO jU54JJiQ51VziROXudbk/9+G9aVTUyzUM+4O08XIQTyOmJxwJeLtHuhQXKDVVFLtvbby btgsjDj9SqMtU88vfo26i3pWcyuZfcaKKOcBJJKeeF5LJ2CiTTwiF3d2ZdNp1hpFz4sp 2d4lv9dhHqZuz2xSxVh1tBvkfpikl/Ksw96QEy4r9XVNgXAEovNU0vJYA34ebyCNVn2Q RHhw== X-Gm-Message-State: APt69E32khJCLF9QS6HiMBJsap/csM2aed9B45cf57J0K/Mrj5ERcPTL 7ZgeLlUB7iELknVULBw3vvUKKg== X-Google-Smtp-Source: ADUXVKJU4bpJScevoQoFvehE5xYdyw0RNgDX7bFCkjSuJ+K8bTxZcZ4UZ6EmtT/QJUADADy94lM/hQ== X-Received: by 2002:a50:863d:: with SMTP id o58-v6mr4041410edo.243.1528895266631; Wed, 13 Jun 2018 06:07:46 -0700 (PDT) Received: from tron.lt2.drhleny.cz ([185.15.109.151]) by smtp.gmail.com with ESMTPSA id q22-v6sm1314438edd.69.2018.06.13.06.07.45 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 13 Jun 2018 06:07:46 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Pete Heist In-Reply-To: Date: Wed, 13 Jun 2018 15:07:44 +0200 Cc: make-wifi-fast@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <9E7E043B-2373-46ED-B122-38A287422999@eventide.io> References: To: bkil X-Mailer: Apple Mail (2.3124) X-Mailman-Approved-At: Wed, 13 Jun 2018 09:22:26 -0400 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: Wed, 13 Jun 2018 13:07:48 -0000 Trying one thing at a time, as legacy_rates=3D=E2=80=981=E2=80=99 = didn=E2=80=99t do anything noticeable, which is not surprising when we = probably don=E2=80=99t have many =E2=80=98b' devices connecting. We hit = 4.9s ping times this morning, good work. :) Even though isolation couldn=E2=80=99t be turned on in the admin = interface (because it says it can=E2=80=99t do it when bridging to a = VLAN, for some reason), I was able to enable isolation for both SSIDs = and it still seems to work, so that=E2=80=99s the change as of now: wireless.ap0_1.isolate=3D'1' wireless.ap0_2.isolate=3D=E2=80=981=E2=80=99 Before I could ping between clients, and now I can=E2=80=99t, so = apparently isolation is doing what it should. The next test will be = tonight. I=E2=80=99m still waiting for the digging / cabling project to happen, = which is what I expect to bring the biggest benefit. Again, that will = add a new cabled AP which will serve as a gateway for cabin 12 and split = cabins 12 and 20. This should also improve the signal to 12 vastly, = which is one of the most loaded APs and currently only has RSSI -71 / = MCS 5 or 6 to its parent AP, now that the leaves are full on the trees. > On Jun 9, 2018, at 5:32 PM, bkil wrote: >=20 > Hello, >=20 > 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. >=20 > legacy_rates=3D0 seems to be an alias for enabling all g-rates and > disabling b-rates: >=20 > = https://github.com/lede-project/source/blob/69f544937f8498e856690f9809a016= f0d7f5f68b/package/network/services/hostapd/files/hostapd.sh#L110 >=20 > So this should be the way to go in your device section: >=20 > 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) >=20 > I also add these to the interface section: >=20 > option isolate 1 # intra-BSS > option dtim_period 5 # cheap power saving >=20 > 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): >=20 > = https://github.com/helmut-jacob/hostapd/blob/a35e34106723eb0b23df9114364d6= fbc46fffab6/wpa_supplicant/wpa_supplicant.conf#L893 >=20 > = https://github.com/helmut-jacob/hostapd/blob/a35e34106723eb0b23df9114364d6= fbc46fffab6/wpa_supplicant/config_ssid.h#L551 >=20 > So some higher level patching might also be possible to enable hostapd > doing the same. >=20 > 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): >=20 > iw dev wlan0 set bitrates # clear mask >=20 > 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 >=20 >=20 > 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: >=20 > # Client isolation can be used to prevent low-level bridging of frames = between > # associated stations in the BSS. By default, this bridging is = allowed. > # https://w1.fi/cgit/hostap/plain/hostapd/hostapd.conf >=20 > This came up on the forums as well recently: > = https://forum.lede-project.org/t/how-to-prevent-guest-network-clients-to-c= ommunicate-with-each-other/14831 >=20 > 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. >=20 > 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. >=20 > 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. >=20 > Regards >=20 > On Fri, Jun 8, 2018 at 11:37 AM, Pete Heist wrote: >>=20 >> On May 31, 2018, at 2:52 AM, David Lang wrote: >>=20 >> On Sat, 19 May 2018, bkil wrote: >>=20 >> In reply to this thread: >> = https://lists.bufferbloat.net/pipermail/make-wifi-fast/2018-April/001787.h= tml >>=20 >> Sorry for the late response, although I can see from yesterday's >> SmokePing plots that the issue still prevails. >>=20 >> 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. >>=20 >> 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. >>=20 >>=20 >> I have been wanting to do this on my APs for Scale (wndr3800 APs with = ath9k >> chipsets) and have been unable to find how to do this on these = chipsets. >>=20 >>=20 >> I also didn=E2=80=99t manage to disable specific MCS rates: >> - supported_rates and basic_rate in /etc/config/wireless seem to only = affect >> legacy rates, not ht-mcs-2.4 rates. >> - "iw dev wlan0 set bitrates=E2=80=9D only sets the transmit rate for = the AP >>=20 >> But what I did do at 10:45am today, June 8, was disable 802.11b rates = with: >>=20 >> uci set wireless.radio0.legacy_rates=3D=E2=80=980' >> uci commit >> reboot >>=20 >> So at least the minimum rate should be limited to 6Mbit. We=E2=80=99ll = see if this >> helps in the next few days as the camp fills, and if I hear any = complaints: >>=20 >> https://www.drhleny.cz/smokeping/ >>=20 >=20 > -- > If you need an encryption key / ha kell titkos=C3=ADt=C3=B3 kulcs: > http://bkil.blogspot.hu/2014/08/public-key.html >=20 >=20 > On Fri, Jun 8, 2018 at 11:37 AM, Pete Heist wrote: >>=20 >> On May 31, 2018, at 2:52 AM, David Lang wrote: >>=20 >> On Sat, 19 May 2018, bkil wrote: >>=20 >> In reply to this thread: >> = https://lists.bufferbloat.net/pipermail/make-wifi-fast/2018-April/001787.h= tml >>=20 >> Sorry for the late response, although I can see from yesterday's >> SmokePing plots that the issue still prevails. >>=20 >> 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. >>=20 >> 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. >>=20 >>=20 >> I have been wanting to do this on my APs for Scale (wndr3800 APs with = ath9k >> chipsets) and have been unable to find how to do this on these = chipsets. >>=20 >>=20 >> I also didn=E2=80=99t manage to disable specific MCS rates: >> - supported_rates and basic_rate in /etc/config/wireless seem to only = affect >> legacy rates, not ht-mcs-2.4 rates. >> - "iw dev wlan0 set bitrates=E2=80=9D only sets the transmit rate for = the AP >>=20 >> But what I did do at 10:45am today, June 8, was disable 802.11b rates = with: >>=20 >> uci set wireless.radio0.legacy_rates=3D=E2=80=980' >> uci commit >> reboot >>=20 >> So at least the minimum rate should be limited to 6Mbit. We=E2=80=99ll = see if this >> helps in the next few days as the camp fills, and if I hear any = complaints: >>=20 >> https://www.drhleny.cz/smokeping/ >>=20