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 875623BA8E for ; Wed, 25 Apr 2018 20:38:34 -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 w3Q0cVL9026205; Wed, 25 Apr 2018 17:38:32 -0700 Date: Wed, 25 Apr 2018 17:38:31 -0700 (PDT) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: =?ISO-8859-15?Q?Toke_H=F8iland-J=F8rgensen?= cc: Pete Heist , make-wifi-fast@lists.bufferbloat.net In-Reply-To: <878t9c70jd.fsf@toke.dk> Message-ID: References: <66BDCA6E-D7C4-4E76-8591-8FDC35B09EA3@eventide.io> <871sf495vs.fsf@toke.dk> <87po2o7lwb.fsf@toke.dk> <1BA3CECA-8C05-4E94-9E2A-1AEA3C2F20B3@eventide.io> <87k1sw7jxj.fsf@toke.dk> <878t9c70jd.fsf@toke.dk> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="680960-97697697-1524703112=:12043" 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: Thu, 26 Apr 2018 00:38:34 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --680960-97697697-1524703112=:12043 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Tue, 24 Apr 2018, Toke Høiland-Jørgensen wrote: > Pete Heist writes: > >>> On Apr 24, 2018, at 4:34 PM, Toke Høiland-Jørgensen wrote: >>> >>> Not sure. You do get HOL blocking while a packet is retried, basically. >>> And ath9k will keep trying way after it should have given up (up to 30 >>> retries per packet). If you combine this with a lot of backoff for each >>> transmission (which is also quite likely in a very congested setting), >>> and I suppose it might be possible… >> >> So that means everyone else waits while a packet is sent and re-sent >> to a station with a weak signal, for example? I see how that would >> wreck the latency pretty quick with the number of stations connected, >> plus channel contention with another repeater. It may be a much bigger >> factor than bloat. > > Yup, exactly... https://www.usenix.org/publications/login/april-2013-volume-38-number-2/wireless-means-radio https://www.usenix.org/conference/lisa12/technical-sessions/presentation/lang_david_wireless http://lang.hm/talks/topics/Wireless/Cascadia_2012/ (apologies for never cleaning this up to one set of good audio/video and slides) can you make a map of how well each AP hears every other AP? (iw scan on each device in turn to report the signal strength of the others) --680960-97697697-1524703112=:12043--