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 1CF0B3B260 for ; Wed, 11 May 2016 12:40:05 -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=1462984801; bh=jF0vwQ/Wx4xJBX411cbTy1F7vhJDZc11iHJrdPCp0DI=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=D1LQG9AgJmIZcDAmT2qMpZH26OHf16HTY9VADvgkwzGp5HNPuVJbsb5hb5TFt5o2R Ln8Y4DM/kAE3dfIcou1dtn6GlzdaXPDbraRwadttmRuGr7Lb7o6kJKVvpQmJEbf68g /I9pNFG7rakomsCe8orbvNMOqBm3/MFRCpjEoqf4= Received: by alrua-kau.kau.toke.dk (Postfix, from userid 1000) id 32BEFC400C4; Wed, 11 May 2016 18:40:00 +0200 (CEST) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: Dave Taht Cc: Luca Muscariello , "make-wifi-fast\@lists.bufferbloat.net" References: <871t58n5wk.fsf@toke.dk> <87futolndh.fsf@toke.dk> <874ma4ljfz.fsf@toke.dk> Date: Wed, 11 May 2016 18:40:00 +0200 In-Reply-To: (Dave Taht's message of "Wed, 11 May 2016 09:29:18 -0700") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87mvnwk0pr.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 16:40:05 -0000 >> My own foci are going to be around trying to rip every source of >> potential latency out of the current system: be it deferred >> interrupts, bad rate control information, overlong txops, excessive >> retries, insufficient packet loss, busting the block ack window, and >> quashing stations grabbing too much airtime... > > and oh, yea, queuing delay. :) What's that? ;) >> and then adding back in "bandwidth" from there. We have enough >> bandwidth in wifi nowadays, just now narrow enough time slices to feed >> many stations sanely. > > Bandwidth = rate/interval. Humans have a terrible tendency to using > big intervals, like seconds... I'd like to focus on calculating > bandwidth as rate/(minimal achievable txop under contention) rather > than maximal. Yes, well, it's a tradeoff to a certain extent. But sure, latency is key; hence the idea to use an FQ-CoDel-based scheduler rather than simply do round-robin. And I figure getting the aggregate size down to a manageable size is another angle of attack. -Toke