[Codel] [Cerowrt-devel] [Bloat] capturing packets and applying qdiscs

[Isaac Konikoff]

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 
> <konikofi at candelatech.com <mailto:konikofi at candelatech.com>> 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
>     <http://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
>>     <smithbone at gmail.com <mailto:smithbone at gmail.com>> 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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/codel/attachments/20150331/43343054/attachment-0002.html>