Thanks for the feedback...I've been trying out the following based on debloat.sh: The ath10k access point has two interfaces for these tests: 1. virtual access point - vap1 tc qdisc add dev vap1 handle 1 root mq tc qdisc add dev vap1 parent 1:1 fq_codel target 30ms quantum 4500 noecn tc qdisc add dev vap1 parent 1:2 fq_codel target 30ms quantum 4500 tc qdisc add dev vap1 parent 1:3 fq_codel target 30ms quantum 4500 tc qdisc add dev vap1 parent 1:4 fq_codel target 30ms quantum 4500 noecn 2. ethernet - eth1 tc qdisc add dev eth1 root fq_codel For the netperf-wrapper tests, the 4 stations in use: tc qdisc add dev sta101 root fq_codel target 30ms quantum 300 tc qdisc add dev sta102 root fq_codel target 30ms quantum 300 tc qdisc add dev sta103 root fq_codel target 30ms quantum 300 tc qdisc add dev sta104 root fq_codel target 30ms quantum 300 I'm planning to re-run with these settings and then again at a lower mcs. On 03/27/2015 08:31 PM, Dave Taht wrote: > wonderful dataset isaac! A lot to learn there and quite a bit I can > explain, which might take me days to do with graphs and the like. > > But it's late, and unless you are planning on doing another test run I > will defer. > > It is mildly easier to look at this stuff in bulk, so I did a wget -l > 1- m http://candelatech.com/downloads/wifi-reports/trial1/ on the data. > > Quick top level notes rather than write a massive blog with graph > entry.... > > -1) These are totally artificial tests, stressing out queue > management. There are no > winners, or losers per se', only data. Someday we can get to winners > and losers, > but we have a zillion interrelated variables to isolate and fix first. > So consider this data a *baseline* for what wifi - at the highest rate > possible - looks like today - and I'd dearly like some results that > are below mcs4 on average also as a baseline.... > > Typical wifi traffic looks nothing like rrul, for example. rrul vs > rrul_be is useful for showing how badly 802.11e queues actually work > today, however. > > 0) Pretty hard to get close to the underlying capability of the mac, > isn't it? Plenty of problems besides queue management could exist, > including running out of cpu.... > > 1) SFQ has a default packet limit of 128 packets which does not appear > to be enough at these speeds. Bump it to 1000 for a more direct > comparison to the other qdiscs. > > You will note a rather big difference in cwnd on your packet captures, > and bandwidth usage more similar to pfifo_fast. I would expect, anyway. > > 2) I have generally felt that txops needed more of a "packing" > approach to wedging packets into a txop rather than a pure sfq or drr > approach, as losses tend to be bursty, and maximizing the number of > flows in a txop a goodness. SFQ packs better than DRR. > > That said there are so many compensation stuff (like retries) getting > in the way right now... > > 3) The SFQ results being better than the fq_codel results in several > cases are also due in part to an interaction of the drr quantum and a > not high enough target to compensate for wifi jitter. > > But in looking at SFQ you can't point to a lower latency and say > that's "better" when you also have a much lower achieved bandwidth. > > So I would appreciate a run where the stations had a fq_codel quantum > 300 and target 30ms. APs, on the other hand, would be better a larger > (incalculable, but say 4500) quantum, a similar target, and a per dst > filter rather than the full 5 tuple. > > > > On Fri, Mar 27, 2015 at 12:00 PM, Isaac Konikoff > > wrote: > > Thanks for pointing out horst. > > I've been trying wireshark io graphs such as: > retry comparison: wlan.fc.retry==0 (line) to wlan.fc.retry==1 > (impulse) > beacon delays: wlan.fc.type_subtype==0x08 AVG > frame.time_delta_displayed > > I've uploaded my pcap files, netperf-wrapper results and lanforge > script reports which have some aggregate graphs below all of the > pie charts. The pcap files with 64sta in the name correspond to > the script reports. > > candelatech.com/downloads/wifi-reports/trial1 > > > I'll upload more once I try the qdisc suggestions and I'll > generate comparison plots. > > Isaac > > > On 03/27/2015 10:21 AM, Aaron Wood wrote: >> >> >> On Fri, Mar 27, 2015 at 8:08 AM, Richard Smith >> > wrote: >> >> Using horst I've discovered that the major reason our WiFi >> network sucks is because 90% of the packets are sent at the >> 6mbit rate. Most of the rest show up in the 12 and 24mbit >> zone with a tiny fraction of them using the higher MCS rates. >> >> Trying to couple the radiotap info with the packet decryption >> to discover the sources of those low-bit rate packets is >> where I've been running into difficulty. I can see the what >> but I haven't had much luck on the why. >> >> I totally agree with you that tools other than wireshark for >> analyzing this seem to be non-existent. >> >> >> Using the following filter in Wireshark should get you all that >> 6Mbps traffic: >> >> radiotap.datarate == 6 >> >> Then it's pretty easy to dig into what those are (by wifi >> frame-type, at least). At my network, that's mostly broadcast >> traffic (AP beacons and whatnot), as the corporate wifi has been >> set to use that rate as the broadcast rate. >> >> without capturing the WPA exchange, the contents of the data >> frames can't be seen, of course. >> >> -Aaron > > > > > > -- > Dave Täht > Let's make wifi fast, less jittery and reliable again! > > https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb