Re: [PATCHv4 5/5] mac80211: add debug knobs for codel

On Thu, May 5, 2016 at 10:27 PM, Michal Kazior [off-list ref] wrote:

On 5 May 2016 at 17:21, Dave Taht [off-list ref] wrote:

quoted

On Thu, May 5, 2016 at 4:00 AM, Michal Kazior [off-list ref] wrote:

quoted

This adds a few debugfs entries to make it easier
to test, debug and experiment.

I might argue in favor of moving all these (inc the fq ones) into
their own dir, maybe "aqm" or "sqm".

The mixture of read only stats and configuration vars is a bit confusing.

Also in my testing of the previous patch, actually seeing the stats
get updated seemed to be highly async or inaccurate. For example, it
was obvious from the captures themselves that codel_ce_mark-ing was
happening, but the actual numbers out of wack with the mark seen or
fq_backlog seen.  (I can go back to revisit this)

That's kind of expected since all of these bits are exposed as
separate debugfs entries/files. To avoid that it'd be necessary to
provide a single debugfs entry/file whose contents are generated on
open() while holding local->fq.lock. But then you could argue it
should contain all per-sta-tid info as well (backlog, flows, drops) as
well instead of having them in netdev*/stations/*/txqs.
Hmm..

I have not had time to write up todays results to any full extent, but
they were pretty spectacular.

I have a comparison of the baseline ath10k driver vs your 3.5 patchset
here on the second plot:

http://blog.cerowrt.org/post/predictive_codeling/

The raw data is here:
https://github.com/dtaht/blog-cerowrt/tree/master/content/flent/qca-10.2-fqmac35-codel-5

...

a note: quantum of the mtu (typically 1514) is a saner default than 300,

(the older patch I had, set it to 300, dunno what your default is now).

and quantum 1514, codel target 5ms rather than 20ms for this test
series was *just fine* (but more testing of the lower target is
needed)

However:

quantum "300" only makes sense for very, very low bandwidths (say <
6mbits), in other scenarios it just eats extra cpu (5 passes through
the loop to send a big packet) and disables
the "new/old" queue feature which helps "push" new flows to flow
balance. I'd default it to the larger value.




...

In other news, spacex just landed on the barge a few minutes ago.

The webcast is still going on
https://www.youtube.com/watch?v=L0bMeDj76ig and you can reverse it to
the landing.
:awesome:

Michał

-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org