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 6581A3B2A3 for ; Wed, 11 May 2016 11:07:54 -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 u4BF7pvI024245; Wed, 11 May 2016 08:07:51 -0700 Date: Wed, 11 May 2016 08:07:51 -0700 (PDT) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: =?ISO-8859-15?Q?Toke_H=F8iland-J=F8rgensen?= cc: Luca Muscariello , make-wifi-fast@lists.bufferbloat.net In-Reply-To: <87futolndh.fsf@toke.dk> Message-ID: References: <871t58n5wk.fsf@toke.dk> <87futolndh.fsf@toke.dk> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="680960-623404938-1462979271=:1548" 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:07:54 -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-623404938-1462979271=:1548 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Wed, 11 May 2016, Toke Høiland-Jørgensen wrote: >> Ten years ago I played with SFQ and madwifi for 802.11g to get max-min >> time fairness (and so proportional rate fairness) with excellent >> results. The hacking I made was based on using time quanta instead of >> bytes. Which required me to get the current PHY rates (AP to all >> STAtions) and dynamically compute/update SFQ time quanta. > > Do you happen to recall what precision you achieved or how much the > precision was really important? Several papers seem to assume that very > high precision is not terribly important since it all evens out in the > end, and I can see how that could be true; but would like to have it > confirmed :) I think the point here is that perfect is the enemy of good enough. Right now the only attempt at fairness is packet counts. Anything that improved this would be a win. We can probably get several orders of magnatude improvement from even the most crude measurements. So start simple/cheap and see how much improvement there is, only go to more precision (more expensive) if you find there's a need to. for that matter, retries may be something that you start off ignoring, just like multicast David Lang --680960-623404938-1462979271=:1548--