From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (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 0A5F83B2A3 for ; Sat, 2 Jul 2016 06:26:07 -0400 (EDT) Received: by mail-oi0-x22b.google.com with SMTP id s66so141380780oif.1 for ; Sat, 02 Jul 2016 03:26:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=9HiFfXg7fCVacXzSzwZ+cQ/vEYawuYoKB53ijloqZY4=; b=nC88WtFERECDS4UKnjsXTZlHuwbictlF658CVRccCJinmho1fBmZbbEGmWP8AioP7v GXavmdYuzzoPUW2PY8ID+MqpwvlYTxTWuq6USGS/GjgVwByPYi1RSZ8+BDtIaik6R9NV z69n1Uwvrw27bv+rYTgKH1jx1C69Vf3IzPBNiqrSLhhnuKWPDP+Af9HHH6WCeB//kj9k q9CiFk/RE5v9Dix7JTXNcIVr8Qsp8lbFnitJEe1SJXy2ujcsf6Bbs3gvnju9qI1ONomO rMaMmq3MDBxH6iWkcuswVf1CNZcvtgAGTsmfMM3PhIAKe7NAz1Y7sSwAcU+A3O3Tr6OP otnw== 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:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=9HiFfXg7fCVacXzSzwZ+cQ/vEYawuYoKB53ijloqZY4=; b=nMMDgwKlVXz00s+09mye+4r+rdRH+5wba7R3v0fkmGv9m8BIzToTiRjuJk+zDFSLHT PFdPbL/l0tacY7axThdvm2KhSKT3YRmjJKHNkihxlESlBq3NO9S/lR2Y+KS9G2gjJ1ep AEc8x+JI3Fcr5lI2ygXiEPjnFOkqcT9yqtiaDAj+2slVLJI+Dx88cZR4PFKWF9AgFQM0 wGqigoeaQwGTcnFjRZFo6WpnSIdU7mXwJ7I6bfgk2i225Cl/I3ehO6pSDOvYssczbzfU s8ZgOXdoxbEnHgj5eXwsh3T968CjsL0tDZVGCp+0abKcyo9I06jYG0arvleuuEbOMLm5 CO/w== X-Gm-Message-State: ALyK8tKIvF2nhMIYNIHyr/dcWWxfXKecNkOAxCzpW6P7eTewUQgmwW+R8TJqAe9CLDP3gT0dm3IrWo8TE9fUkg== X-Received: by 10.157.26.87 with SMTP id u23mr1537318otu.169.1467455167195; Sat, 02 Jul 2016 03:26:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.175.130 with HTTP; Sat, 2 Jul 2016 03:26:06 -0700 (PDT) In-Reply-To: <87ziq2o07z.fsf@toke.dk> References: <87ziq2o07z.fsf@toke.dk> From: Dave Taht Date: Sat, 2 Jul 2016 11:26:06 +0100 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: make-wifi-fast@lists.bufferbloat.net Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [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: Sat, 02 Jul 2016 10:26:08 -0000 Comments: (my overall take on things is these patches should all go upstream yesterday, we get some .debs built for others to use, and iterate from there) (some of the below has already been discussed but I've lost track on what was discussed privately or not) A) I would put down the issues you had in fig 3, 4, to the enormous client latencies still apparent in fig 5. While proving that these patches help an AP's performance enormously, and are thus valuable there, clients should show an enormous benefit as well. I am dying for a "full enchalada" test, as "The stations are running a stock Ubuntu 16.04, while the access point is running a 4.6-based kernel with the appropriate patches applied"... but maybe not with 30 iterations? 5? :) the benefit on the client is mostly covered by the switch to the soft queues and fq_codel at the mac80211 layer. B) Similarly, in fig 6, I would put down to the clients using slightly more TXOPs to do what they are doing, due to the existing (borken) structure of the ath9k driver, primarily. Or - what was the volume of the ping traffic? isochronous (voip-like) testing is better... Clamping the txop size further under contention would be "interesting". A possible synergetic enhancement to the fast/slow queue concept is to more aggressively cut the max txop size for all "slow queue" stations, when a new station appears. A simpler enhancement to test is to cut the max txop size as a function of the number of stations with backlogs to something smaller than the max, say 2ms. (my mental vision was max(2ms,5.6/stations)) C) What was the performance loss, with airtime fairness achieved, for the slow station? 3x? Was ecn enabled? D) Fig 2 is in 10^8, it's easier to read if not in that notation E) The download/upload asymmetry is a bit bothersome, there are multiple potential root causes. It's not clear which way the upload was? 1) Usually the AP has much better antennas, but I don't think this is the case here 2) rx accounting not correct? 3) codel breakage? (what was the target and quantum?). We can drop acks all day long but dropping tcp data too early is problematic. The codel target is currently set to 20ms in the ath10k patchset, I think. Hope is to make that dynamic based on the aftereffects of fiddling on B. One of the experiments I did was to clamp the max txop size as distributed in the beacon to "94" in hostapd. This led to much better symmetry on some tests of mine, and cost throughput. Again this could one day be a dynamically set option based on the workload, if it helps. I was told recently that the beacon interval is set to 3 or more in some APs nowadays, notably apple's, but that's probably not relevant. Longer term tests: F) Differences in ad-hoc mode? G) Hardware mq tests H) Minstrel-blues integration Random tests Reducing retries, reducing the size of the retry chain, etc. On Thu, Jun 30, 2016 at 10: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-ath9k.html > > -Toke > _______________________________________________ > Make-wifi-fast mailing list > Make-wifi-fast@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/make-wifi-fast --=20 Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org