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 B89A53B2A4 for ; Fri, 19 May 2017 05:27:42 -0400 (EDT) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1495186060; bh=EPgLqwxY4Zcikvz42EAWnl/IQNs2HINcKCjrROjhZ1A=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=y4xR8qSQ0FYNmIDY7d21fuJ4A3lwlEdTmMaM3JpReQWbmwZjtqfNClTezISIgXlio 1XJHyf4X9/UGUogvU7d2U3fK3KpNYVkGMFmKBLZDkRWGardSAxsq3LrJugtAKygmZ7 XFxrZy7zW4i+L44LWjtbXUf9HRfO5L+dfkKcLytAxntAPDo1q4fydkWPHxcVFuXTNh aVh1XKkTlUqmhNP1ARXG3GtXGQww6uLhtBhdBvsFHHoie30u9gof7tDktBEwlY0fCO 05wmLKMWzK+VlYQHFr76gOLl2JByf4gNEohGeLljB2Ayn1Gy0/EAbSnpLVUGWF8dtn dlpunwkqbMQXA== To: Johannes Berg Cc: make-wifi-fast@lists.bufferbloat.net, linux-wireless@vger.kernel.org References: <20170405161810.30671-1-toke@toke.dk> <20170406093826.16626-1-toke@toke.dk> <1495029987.2442.19.camel@sipsolutions.net> Date: Fri, 19 May 2017 11:27:38 +0200 In-Reply-To: <1495029987.2442.19.camel@sipsolutions.net> (Johannes Berg's message of "Wed, 17 May 2017 16:06:27 +0200") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87efvldwmt.fsf@alrua-kau> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Make-wifi-fast] [PATCH v3] mac80211: Dynamically set CoDel parameters per station 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: Fri, 19 May 2017 09:27:43 -0000 Johannes Berg writes: > On Thu, 2017-04-06 at 11:38 +0200, Toke H=C3=B8iland-J=C3=B8rgensen wrote: >> CoDel can be too aggressive if a station sends at a very low rate, >> leading reduced throughput. This gets worse the more stations are >> present, as each station gets more bursty the longer the round-robin >> scheduling between stations takes. >>=20 > [...] > > I've applied this now (with some minor fixups) - the whole discussion > didn't really conclude in anything, and we can just try it. Okidoki. FWIW, the reason I never got any further was that my experiments with other approaches proved somewhat inconclusive. Partly because a reorganisation of my testbed has caused the physical conditions to change which has caused the original problem to be less severe. So yeah, some wider testing would be good, and I agree that it is low risk. I'll revisit this myself at some point after I get my testbed rebased on a new kernel and figure out why the physical conditions changed... :) -Toke