[Make-wifi-fast] On the 802.11 performance anomaly and an airtime fairness scheduler to fix it

[Dave Taht]

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øiland-Jørgensen <toke at toke.dk> 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 at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org