From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2.tohojo.dk (mail2.tohojo.dk [77.235.48.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 8C32B3B260 for ; Wed, 11 May 2016 11:28:22 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail2.tohojo.dk DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=201310; t=1462980500; bh=DrlGEhw3l99rC3k7Y2cFjfWdVBOWnhnH8vDFaVdUnGg=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=nqTfy6EQdp9DT2L9DYJnEEhPApKNU4LYVNoPM/ol41zjwhtBEbdjqRdxTdyl2mulM EDXohNAXh+mSLFAWQx3TsHLLtccN0JCdzP/SpkRE6OzAAioAy2UpZ2EQzL7EejpdJv qQ04pbINED7uCXa9h3sEKPOp09Eipp+SSgfxHP7Q= Received: by alrua-kau.kau.toke.dk (Postfix, from userid 1000) id E9FA7C400C4; Wed, 11 May 2016 17:28:19 +0200 (CEST) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: David Lang Cc: make-wifi-fast@lists.bufferbloat.net References: <871t58n5wk.fsf@toke.dk> <87futolndh.fsf@toke.dk> <874ma4ljfz.fsf@toke.dk> Date: Wed, 11 May 2016 17:28:19 +0200 In-Reply-To: (David Lang's message of "Wed, 11 May 2016 08:20:34 -0700 (PDT)") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87r3d8k418.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Make-wifi-fast] Thoughts on tackling airtime fairness 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, 11 May 2016 15:28:22 -0000 David Lang writes: >> I expect that if you were able to change this even once/sec and >> account for the rate you would be far better than what we have now. I suspect so too, but would like to have someone who actually tried it before confirm it ;) > by the way, I have logs from the last two scale conferences of the > /sys data per-station showing the rate info. if you give me a way to > send you the multi-G file you can look through it to see how rapidly > the rate changes for a given station under real-world > high-user-density conditions. Hmm, can probably give you and sftp dump space; will set it up and message you off-list :) > I suspect that the biggest problem right now is that the higher level > scheduling isn't accounting for "station X is at rate 1, station Y is > at rate 100" and is trying to be 'fair' by sending the same amount of > data to each of them. Well, from a scheduling perspective, there really is no "higher level scheduling". There's just a FIFO queue. However, the throughput-based fairness you describe is an intrinsic property of the 802.11 DCF. This is known in the academic literature as "the 802.11 performance anomaly", It was first described in 2003(!) for 802.11b [1]. There has been several academic publications on ways to fix this (just finished the one Lucas linked, which was pretty good), but none of this seems to have percolated into mainline Linux. Surprise, surprise. -Toke [1] M. Heusse, F. Rousseau, G. Berger-Sabbatel and A. Duda, "Performance anomaly of 802.11b," http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1208921&isnumber=27206