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 4771E3BA8E for ; Fri, 6 Oct 2017 18:40:17 -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 v96MeEBf024678; Fri, 6 Oct 2017 15:40:14 -0700 Date: Fri, 6 Oct 2017 15:40:14 -0700 (PDT) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: Johannes Berg cc: =?ISO-8859-15?Q?Toke_H=F8iland-J=F8rgensen?= , make-wifi-fast@lists.bufferbloat.net, linux-wireless@vger.kernel.org In-Reply-To: <1507310319.19300.28.camel@sipsolutions.net> Message-ID: References: <20171006115232.28688-1-toke@toke.dk> <1507298832.19300.20.camel@sipsolutions.net> <87lgkoqrhs.fsf@toke.dk> <1507310319.19300.28.camel@sipsolutions.net> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [Make-wifi-fast] [RFC] mac80211: Add airtime fairness accounting 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, 06 Oct 2017 22:40:17 -0000 On Fri, 6 Oct 2017, Johannes Berg wrote: >> Well, calculating the duration from the rate and size is what ath9k >> is currently doing, and that has all the information available to do >> so (I did verify that the airtime was almost identical on the TX and >> RX side for the same traffic). > > It's still iffy - with aggregation you might have a better idea of the > total airtime, but not really see - in the higher layers - all the > padding that comes between A-MPDUs etc. I think many drivers could do > better by exposing the total airtime from the device/firmware, whereas > exposing _all_ the little details that you need to calculate it post- > facto will be really difficult, and make the calculation really hard. perfect is the enemy of good enough :-) I don't think the intent is to try and be a perfect accounting, if the total calculated time ends up being > 100%, it doesn't really matter, what matters is the relative behavior of the stations, and while the naive calculation fails to properly reward a station that's being more efficient, it is still good enough to punish stations using lower bandwidth modes (which is a far larger cause of problems) while it's ideal to have the driver provide the airtime, falling back to a naive (but relativly cheap) calculation if a time isn't provided. David Lang