From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2.tohojo.dk (mail2.tohojo.dk [77.235.48.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 579353B260 for ; Wed, 11 May 2016 11:15:58 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail2.tohojo.dk DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=201310; t=1462979755; bh=lU3kVqJmxCCh1jOMFdVWAtAG8wxbJ8FwoiieIOmue9k=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=Ah3sh0EtOh+LluvxIrlPhiu2lXj3U/53ooftoUIGhJKspJ7DZnwTtrQk97JOry27j g18D6JOy3XMnfMvJ2MVWZ17l3nrzOmqgDwdAowDt2gOnRpvk+3M2vsrzGWHhckC6ti gVvs1ycaGwZuU3THit6dq6w2EscRIUhB88LD292U= Sender: toke@toke.dk Received: by alrua-kau.kau.toke.dk (Postfix, from userid 1000) id 10ECCC400C4; Wed, 11 May 2016 17:15:55 +0200 (CEST) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: David Lang Cc: make-wifi-fast@lists.bufferbloat.net References: <871t58n5wk.fsf@toke.dk> Date: Wed, 11 May 2016 17:15:55 +0200 In-Reply-To: (David Lang's message of "Wed, 11 May 2016 08:03:11 -0700 (PDT)") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87zirwk4lw.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain 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:15:58 -0000 David Lang writes: >> Improving the access point behaviour is definitely the straight-forward >> way, and there are many obvious improvements that can result from that, >> as we've already seen in e.g. Michal's patch set. So looking at airtime >> fairness from the point of view of the access point makes sense. > > As a practical matter, we are not going to be able to change the code > on the nodes. There are just too many closed source, and > never-to-be-updated devices out there (IoT) Yes, there's that too. Besides, if we assume most traffic is TCP (or has similar ack-type feedback), we can to a large extent control what the client does by scheduling in the downstream. > I think the problem is that the aggregates are created too soon, and > as a result the rate can change drastically between the time the > aggreagate is formed and when it is sent. I don't believe that they > are really limited to 4ms in practice. Ah, right, hadn't thought of that. Another good reason to reduce queueing in the lower layers I suppose... > Right now, most of the stuff is still doing packet-count based queues. > On wired networks where the rate was constant, moving to BQL was a > huge win. When the rate can vary so drastically, we need to be > factoring rate into the picture somehow. Yes, my thought was to just switch entirely to time-based accounting in the scheduler. Which means that the scheduler has to have this information available to it. Not sure whether that is practical at the mac80211 layer (but suppose it could be done by adding appropriate driver hooks if things are missing). >> - 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). -Toke