From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 317C73B25D for ; Sun, 3 Jul 2016 02:55:26 -0400 (EDT) Received: by mail-yw0-x231.google.com with SMTP id l125so18929556ywb.2 for ; Sat, 02 Jul 2016 23:55:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=G+SuYu2fMG9bfhUm3ywtKkKd+bBfUoxpyiTkJDgfQcc=; b=sBY+hHgNv3jPZpM/RSgtpw8DJhjn2ONhS16RZakZnY0GzNfuKoRVeB5JPz3PItky9c NpOxLxXsHRFGHtu08rlOS46EfwwiWtiMclfATj0HZwSsik0OgNsZYNnCZVVqoAHpcY85 a3UC2dNELsLEvA0wEG+HqwDoPir2oYDhf4GZdpheiJ0B5GWxuOsiETl5FN6bXjJWYPcp zloEZSAfCMUPk1+qU/OAj3R+IdcvkoktGU/yRB4v5J33SBTIfL93Zc8iWD5Pm9mdSQ9S Q1m+yzxx39GMlLhsONQvbTqK50DO8fdars4ZI6tBgxS1zDy7H8q13jxC1Ng7F+E/o/xc h+7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=G+SuYu2fMG9bfhUm3ywtKkKd+bBfUoxpyiTkJDgfQcc=; b=VV8h0gY7zofuHU+LFJGL4TvPdBHAW0sJale8a1cRqYndKf6wsYaOJNQQ7VShcIVhq2 +7StYIE23K4LqQ/IMVRdzGxQxyhDXUlT4BefzacbmeFrqvWdt4+0GagiN+1olA4F5ety IfQwHpfDGQ4MZKGWiBpg+DkCLeFJjCuZoy+FjcBM25kKuBQINZEXK1mkGOfURXxE0tZ+ wZlTsIBkNpA62zy2yut7lpL402P64n+IhT4xnr4JhwVnTEuQY1zpKU8QhmMOBOQA1fx6 XT5LgTmDHfqpwBh6dHMUBre7zMfGCguOK+yu7GqQsTbVxxt/bmfC+waWjZ/wfbrpF85G 0gSw== X-Gm-Message-State: ALyK8tKf8jRIu2z/LjpAN7+WDL36z0DRHR0lAIVCGQ2ventafcaQYkOUTN2S/akkdzHt4Tu1/beX7tXSw71xDA== MIME-Version: 1.0 X-Received: by 10.37.223.202 with SMTP id w193mr3683351ybg.139.1467528925690; Sat, 02 Jul 2016 23:55:25 -0700 (PDT) Received: by 10.37.74.134 with HTTP; Sat, 2 Jul 2016 23:55:25 -0700 (PDT) In-Reply-To: <87ziq2o07z.fsf@toke.dk> References: <87ziq2o07z.fsf@toke.dk> Date: Sun, 3 Jul 2016 08:55:25 +0200 Message-ID: From: Luca Muscariello To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: "make-wifi-fast@lists.bufferbloat.net" Content-Type: multipart/alternative; boundary=94eb2c08ed9850457a0536b5b415 Subject: [Make-wifi-fast] On the 802.11 performance anomaly and an airtime fairness scheduler to fix it 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: Sun, 03 Jul 2016 06:55:26 -0000 --94eb2c08ed9850457a0536b5b415 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Toke, great piece of work. UDP tests show that the scheduler is working quite well. TCP tests: no news that ACK streams are a problem. This is another well known issue in wifi. Every data packet is ACKed already at L2 and L4 sends an ACK that is non contention free. There is an NSDI paper in 2014 that proposes to use the L2 ACK to carry the L4 ACK. It works well but purists might hate that approach. BTW the gains you show are huge. If you add multiple stations uniformly distributed around the AP you'll see tremendous gains. The delay gain is also huge and poorly explored so far. On Thu, Jun 30, 2016 at 11:06 PM, Toke H=C3=B8iland-J=C3=B8rgensen > wrote: > I've previously posted my airtime fairness scheduler patch here. When I > did I promised a more thorough performance evaluation of it. This took a > bit longer to get done than I had anticipated, but I have now put up a > blog post with some pretty graphs. > > The post also explains the background of the 802.11 performance anomaly > to those not familiar with it; feel free to skip to the results if you > are already familiar with it. > > Link: > https://blog.tohojo.dk/2016/06/fixing-the-wifi-performance-anomaly-on-ath= 9k.html > > -Toke > _______________________________________________ > Make-wifi-fast mailing list > Make-wifi-fast@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/make-wifi-fast > --94eb2c08ed9850457a0536b5b415 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Toke,

great piece of=C2=A0work.
UD= P tests show that the scheduler is working quite well.=C2=A0
TCP tests:=C2=A0no news that ACK streams are a problem.
This is another well known issue=C2=A0=C2=A0in wifi.

Every data packet is ACKed already a= t L2 and L4
sends an ACK that is non contention free.

There is an NSDI paper in 2014 that proposes to use the L2 ACK to carry = the L4 ACK.
It works well but purists might hate that approach.

BTW the gains you show are huge.=C2=A0
If you add mu= ltiple stations uniformly distributed around the AP you'll see tremendo= us gains.

The delay gain=C2=A0is also huge and poo= rly explored so far.=C2=A0

On Thu, Jun 30, 2016 at 11:06 PM, Toke H=C3=B8iland-J=C3= =B8rgensen <toke@toke.dk> wrote:
I've previously posted my ai= rtime fairness scheduler patch here. When I
did I promised a more thorough performance evaluation of it. This took a bit longer to get done than I had anticipated, but I have now put up a
blog post with some pretty graphs.

The post also explains the background of the 802.11 performance anomaly
to those not familiar with it; feel free to skip to the results if you
are already familiar with it.

Link: https://blog.t= ohojo.dk/2016/06/fixing-the-wifi-performance-anomaly-on-ath9k.html

-Toke
_______________________________________________
Make-wifi-fast mailing list
Make-wifi-fast@lists.bufferbloat.ne= t
https://lists.bufferbloat.net/listinfo/make-wif= i-fast

--94eb2c08ed9850457a0536b5b415--