From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 631E03BA8E for ; Wed, 17 Jan 2018 05:48:33 -0500 (EST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1516186105; bh=c/0kVGiKByrGF5+P0d+jnzQhO0K99s2alGULjBdlhnY=; h=From:To:Subject:In-Reply-To:References:Date:From; b=iwQMwYk9wMnIumsX5LPUTf0pRAO4dS6JBmH/yKBfaKFfj/s/3qv9+uE6zm69so9YE gd2xuyyP3OA7+FDISTL/9nkaLn3C1giQ7XGgggTTFLDx9hYW2sYo1ADx18oBsLqrq1 NyIDwWUnB7W8sx+M+e/PxfAgAizKHe56OGjq9B/i95R+5zwpM8+njOBzGZ1KKWslkF rDMSSReyxvh4IrmkA6izLTM5oUAUiy2lDpfey/F/n/Aa1yFXkY6nqSwPSW7DWNxb5F QGC9ywKOoQl0SsuymqbEkwZa40Nf5/24/f2VCIo2019r6V7sLdkOJK6hUuBD/p9/dh v9jyP/LTKuLRw== To: David Lang , make-wifi-fast@lists.bufferbloat.net In-Reply-To: References: Date: Wed, 17 Jan 2018 11:48:31 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87efmovk00.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Make-wifi-fast] what is the state of the airtime fairness patches? 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, 17 Jan 2018 10:48:33 -0000 David Lang writes: > I'm getting ready to finalize the build for the Scale conference, is airtime > fairness upstream in LEDE for both ath9 and ath10? > > Has it been ported to anything else? Airtime fairness is upstream in both mainline and LEDE for ath9k. There have been some preliminary developments for ath10k (looks like we can get the data we need), but nothing that works yet. Should be possible to get it to work for mt76 as well, at least. The fq_codel-based queueing stuff is active for both ath9k, ath10k and mt76, though. > Is there anything you would like me to gather in this environment? Hmm, things that might be interesting: - Distribution of client capabilities (5/2.4Ghz, MIMO mode, n/ac, achieved rates, etc. - however much data you can reasonably gather) - Lasthop latency experienced by the clients (you could get this by capturing TCP handshakes and measuring the ACK-SYNACK delay, as shown in Figure 1 of this paper: https://dl.acm.org/citation.cfm?doid=2999572.2999603) - this could give an indication of bloat in the client drivers. - QoS usage (how much traffic is sent on each of the VO/VI/BE/BK queues). > I've got a lot of the wndr3700/3800 APs (ath9k) and would like to get > a handful of -ac devices to see if there are enough users who would > take advantage of the higher speeds to matter. I think we are getting to the point where ac is fairly common, at least in phones. But data on this would be good of course :) -Toke