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. _______________________________________________ Codel mailing list Codel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/codel