Re: [RFCv2 0/3] mac80211: implement fq codel

Michal Kazior writes: > traffic-gen generates only BE traffic. Everything else runs UDP_RR > which doesn't generate a lot of traffic. Good point. Fixed that: the newest git version of traffic-gen supports a -t parameter which will be set as the TOS byte on outgoing

Re: [RFCv2 0/3] mac80211: implement fq codel

On 21 March 2016 at 18:10, Dave Taht wrote: > thx. > > a lot to digest. > > A) quick notes on "flent-gui bursts_11e-2016-03-21T09*.gz" > > 1) the new bursts_11e test *should* have stuck stuff in the VI and VO > queues, and there *should* have been some sort of difference

Re: [RFCv2 0/3] mac80211: implement fq codel

I've re-tested selected cases with wmm_enabled=0 set on the DUT AP. I'm attaching results. Naming: * "old-" is without mac/ath10k changes (referred to as kvalo-reverts previously) and fq_codel on qdiscs, * "patched-" is all patches applied (both mac and ath), * "-be-bursts" is stock "bursts"

Re: [Codel] [RFCv2 0/3] mac80211: implement fq codel

On 03/17/2016 10:00 AM, Dave Taht wrote: netperf's udp_rr is not how much traffic conventionally behaves. It doesn't do tcp slow start or congestion control in particular... Nor would one expect it to need to, unless one were using "burst mode" to have more than one transaction inflight at

Re: [RFCv2 0/3] mac80211: implement fq codel

On Thu, Mar 17, 2016 at 1:55 AM, Michal Kazior wrote: > I suspect the BK/BE latency difference has to do with the fact that > there's bulk traffic going on BE queues (this isn't reflected > explicitly in the plots). The `bursts` flent test includes short > bursts of

Re: [RFCv2 0/3] mac80211: implement fq codel

it is helpful to name the test files coherently in the flent tests, in addition to using a directory structure and timestamp. It makes doing comparison plots in data->add-other-open-data-files simpler. "-t patched-mac-300mbps", for example. Also netperf from svn (maybe 2.7, don't remember) will

Re: [RFCv2 0/3] mac80211: implement fq codel

On Wed, Mar 16, 2016 at 11:36:31AM -0700, Dave Taht wrote: > That is the sanest 802.11e queue behavior I have ever seen! (at both > 6 and 300mbit! in the ath10k patched mac test) Out of curiosity, why does BE have larger latency than BK in that chart? I'd have expected the opposite. -- Bob

Re: [RFCv2 0/3] mac80211: implement fq codel

On 16 March 2016 at 16:37, Dave Taht wrote: > it is helpful to name the test files coherently in the flent tests, in > addition to using a directory structure and timestamp. It makes doing > comparison plots in data->add-other-open-data-files simpler. "-t >

Re: [RFCv2 0/3] mac80211: implement fq codel

TxOP 0 has a special meaning in the standard. For HT/VHT it means the it is actually limited to 5484us (mixed-mode) or 1us (greenfield). I suspect the BK/BE latency difference has to do with the fact that there's bulk traffic going on BE queues (this isn't reflected explicitly in the plots).

Re: [RFCv2 0/3] mac80211: implement fq codel

On Thu, Mar 17, 2016 at 09:55:03AM +0100, Michal Kazior wrote: > If you consider Wi-Fi is half-duplex and latency in the entire stack > (for processing ICMP and UDP_RR) is greater than 11e contention window > timings you can get your BE flow responses with extra delay (since > other queues might

Re: [RFCv2 0/3] mac80211: implement fq codel

On 16 March 2016 at 11:17, Michal Kazior wrote: > Hi, > > Most notable changes: [...] > * ath10k proof-of-concept that uses the new tx >scheduling (will post results in separate >email) I'm attaching a bunch of tests I've done using flent. They are all "burst"

[RFCv2 0/3] mac80211: implement fq codel

Hi, Most notable changes: * fixes (duh); fairness should work better now, * EWMA codel target based on estimated service time, * new tx scheduling helper with in-flight duration limiting (same idea Emmanuel had for iwlwifi), * added a few debugfs hooks. * ath10k proof-of-concept