[Make-wifi-fast] [RFC/RFT] mac80211: implement fq_codel for software queuing

[Dave Taht]

Dear Michal:

Can you take a picture of your setup?

Our intent is to continue to improve the flent test suite to be able
to generate repeatable tests, track relevant wifi behaviors and pull
relevant data back, graphed over time (of test) and time (over test
runs). A problem with udp flood tests is that tcp traffic is always
bidirectional (data vs acks), so a naive thought would be, that yes,
you should get half the bandwidth you get with a udp flood test.

But in the age of aggregation that is not correct.

It is my hope for us to join you on testing/evaluating the various
bits, but with so many patches (wonderfully, but suddenly) flying
around in loose formation ( can we start a lowlatency-wifi kernel tree
somewhere? - oy, there are so many other moving parts!), that's going
to take a bit. While we have some ath10k gear, the biggest testbeds
(karstad, san francisco, yurtlab) are all ath9k based.

Some things you could do for us whilst we try to catch up.

Take packet captures! - there are plenty of tcp experts on the codel list.

For single station tests: run a repeatable test series: rrul, rrul_be,
tcp_upload, tcp_download. Provide those flent.gz files.
rrul exercises 3 of the 4 802.11e queues on most systems.
rrul_be one queue

Example:
#!/bin/sh
T="some meaningful title like fq_codel_target_30ms_10meters-crazynewpatch-1"
S=some.netperf.server.nearby
F="fent -x -l 60 "
TESTS="rrul rrul_be tcp_upload tcp_download"

for i in $TESTS
do
$F -H $S -t "$T"
done

flent-gui *.gz

If you are running tests overnight (recommended, wifi data is noisy so
are office environments), iterate on the $T-test number...

You can also track remote queue lengths and stats with other flent
options. My assumption however is that you are almost entirely
bypassing the qdisc queue now(?) and injecting things into a queue
that cannot be seen by userland?

For playing with MU-mimo, the various rtt_fair tests in flent were our
starting point, which test anywhere from 1 to 4 stations.  example
testing 2 stations with two tcp streams.

rtt_fair4be -H station1 -H station2 -H station1 -H station2

The packet captures should be *fascinating* on that.

Aircaps interesting also.

Other variables to tweak:

0) Use the same driver on server and client. Then a reference driver.
1) Disable codel entirely or give it a really big target/interval
(30ms, 300ms) to just look at the fq portion of the algorithm.
2) enabling ECN on the tcps on server and client will give you a clear
idea as to when codel was kicking in vs packets being dropped
elsewhere on the packet captures.
3) One of my biggest ongoing concerns with adapting codel in wifi has
been the impact of multicast on it - mdns-scan (along with any of the
above tests), or some other heavy mcast program in the background
(uftp is not bad). mu-mimo introduces new issues with sounding that I
don't think anyone understands at any detail yet. Can wireshark or
some other tool "see" a sounding?

4) Distance and rate control. MCS4 was my basic rate for transmits
from stations for the longest time as that appeared to be the median
rate I'd got in various coffee shops... while I realize you have to
achieve peak throughput under ideal conditions, it's achieving good
overall performance in more abusive conditions...

... and ...

5) come to battlemesh with what you got.