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 579723B2A2 for ; Wed, 11 May 2016 11:20:36 -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 u4BFKYcG024384; Wed, 11 May 2016 08:20:34 -0700 Date: Wed, 11 May 2016 08:20:34 -0700 (PDT) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: =?ISO-8859-15?Q?Toke_H=F8iland-J=F8rgensen?= cc: make-wifi-fast@lists.bufferbloat.net In-Reply-To: Message-ID: References: <871t58n5wk.fsf@toke.dk> <87futolndh.fsf@toke.dk> <874ma4ljfz.fsf@toke.dk> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY="680960-1323166343-1462979844=:1548" Content-ID: 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:20:36 -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-1323166343-1462979844=:1548 Content-Type: TEXT/PLAIN; CHARSET=utf-8; FORMAT=flowed Content-Transfer-Encoding: 8BIT Content-ID: On Wed, 11 May 2016, David Lang wrote: > On Wed, 11 May 2016, Toke Høiland-Jørgensen wrote: > >> Luca Muscariello writes: >> >>> 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 :) >>> >>> what do you mean with precision? >>> Do you mean in measuring the PHY rate? Short term vs long term >>> measurements? else? >> >> Yes, in measuring the rate. Was this a per-packet thing, and were you >> actually able to get information sufficiently accurate to achieve the >> desired level of fairness? And by what mechanism? Was this in the driver >> or higher up in the stack? > > 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. 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. 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. David Lang --680960-1323166343-1462979844=:1548 Content-Type: TEXT/PLAIN; CHARSET=utf-8 Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: INLINE X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KTWFrZS13aWZp LWZhc3QgbWFpbGluZyBsaXN0Ck1ha2Utd2lmaS1mYXN0QGxpc3RzLmJ1ZmZlcmJsb2F0Lm5ldApo dHRwczovL2xpc3RzLmJ1ZmZlcmJsb2F0Lm5ldC9saXN0aW5mby9tYWtlLXdpZmktZmFzdAo= --680960-1323166343-1462979844=:1548--