Re: [Codel] [RFC] ath10k: implement dql for htt tx

2016-04-01 Thread Michal Kazior
Re-posting text only as it was blocked by most mailing list servers: The original attachment can be fetched at: http://kazikcz.github.io/dl/2016-04-01-flent-ath10k-dql.tar.gz On 25 March 2016 at 10:55, Michal Kazior wrote: > On 25 March 2016 at 10:39, Michal Kazior

Re: [Codel] [RFC] ath10k: implement dql for htt tx

2016-03-30 Thread Ben Greear
On 03/30/2016 02:22 AM, Michal Kazior wrote: On 29 March 2016 at 17:54, Ben Greear wrote: On 03/29/2016 12:49 AM, Michal Kazior wrote: if you are getting a pure codel result of 160ms, that means the implementation is broken. But I think (after having read your

Re: [Codel] [RFC] ath10k: implement dql for htt tx

2016-03-30 Thread Michal Kazior
On 29 March 2016 at 17:54, Ben Greear wrote: > On 03/29/2016 12:49 AM, Michal Kazior wrote: > >>> if you are getting a pure codel result of 160ms, that means the >>> implementation is broken. But I think (after having read your >>> description twice), the baseline result

Re: [Codel] [RFC] ath10k: implement dql for htt tx

2016-03-29 Thread Michal Kazior
On 26 March 2016 at 17:44, Dave Taht wrote: > Dear Michal: [...] > I am running behind on this patch set, but a couple quick comments. [...] >> - no rrul tests, sorry Dave! :) > > rrul would be a good baseline to have, but no need to waste your time > on running it every

Re: [Codel] [RFC] ath10k: implement dql for htt tx

2016-03-26 Thread Dave Taht
Dear Michal: I commented on and put up your results for the baseline driver here: http://blog.cerowrt.org/post/rtt_fair_on_wifi/ And the wonderful result you got for the first ever fq_codel-ish implementation here: http://blog.cerowrt.org/post/fq_codel_on_ath10k/ I am running behind on this

[Codel] [RFC] ath10k: implement dql for htt tx

2016-03-25 Thread Michal Kazior
This implements a very naive dynamic queue limits on the flat HTT Tx. In some of my tests (using flent) it seems to reduce induced latency by orders of magnitude (e.g. when enforcing 6mbps tx rates 2500ms -> 150ms). But at the same time it introduces TCP throughput buildup over time (instead of