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 0BAB23B260 for ; Wed, 11 May 2016 11:24:05 -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 u4BFO3lQ024410; Wed, 11 May 2016 08:24:03 -0700 Date: Wed, 11 May 2016 08:24:03 -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: <87zirwk4lw.fsf@toke.dk> Message-ID: References: <871t58n5wk.fsf@toke.dk> <87zirwk4lw.fsf@toke.dk> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="680960-907673581-1462980243=: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:24:06 -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-907673581-1462980243=:1548 Content-Type: TEXT/PLAIN; format=flowed; charset=ISO-8859-15 Content-Transfer-Encoding: 8BIT On Wed, 11 May 2016, Toke Høiland-Jørgensen wrote: > David Lang writes: > >>> - How to measure the results? Can we dump the information from the >>> driver (and is it accurate)? Do we need to parse aircaps? Something >>> else? >> >> we need to be able to instrament the driver (I don't know if we can >> get enough data there or not currently) >> >> trying to work with aircaps has the problem that what you see in the >> aircap doesn't match what either the sender or receiver sees >> >> Take retransmissions as an example. They only happen because the >> receiver didn't see them. If you were to get an aircap off the same >> antenna as the receiver, you also wouldn't see them and therefor could >> not account for them. In the real world, you are doing the aircap from >> a different device, with a different antenna so what you see will be >> even more different. Now think about the normal case where you have >> two stations taking in two very different locations and one device to >> do the aircap. >> >> If we don't have anything else, aircaps are what we have to fall back >> on, but we need to realize how much we can't see at that point. > > Hmm, hadn't thought of that. Damn. Well, guess we'll have to trust the > driver (or make it trustworthy if we can't). the good news is that getting this information out of the driver should not be hard. It knows when it does a retransmit. I also suspect that we could get away without explictly tracking retransmits for now. As it retransmits to a station, it's also going to end up slowing down if it's a long-term problem. we need to think of the scale we are trying to be fair on. I think that if we are fair on the scale of seconds we will gain 80% of the effect that we would get if we were trying to be fair on the order of ms, and it's much easier to do :-) David Lang --680960-907673581-1462980243=:1548--