On 6 May 2016 at 07:51, Dave Taht <dave.taht@xxxxxxxxx> wrote: > On Thu, May 5, 2016 at 10:27 PM, Michal Kazior <michal.kazior@xxxxxxxxx> wrote: >> On 5 May 2016 at 17:21, Dave Taht <dave.taht@xxxxxxxxx> wrote: >>> On Thu, May 5, 2016 at 4:00 AM, Michal Kazior <michal.kazior@xxxxxxxxx> wrote: >>>> 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 It's probably good to explicitly mention that you test(ed) ath10k with my RFC DQL patch applied. Without it the fqcodel benefits are a lot less significant. (oh, and the "3.5" is pre-PATCHv4 before fq/codel split work: https://github.com/kazikcz/linux/tree/fqmac-v3.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). I still use 300. > 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) I would keep 20ms for now until we get more test data. I'm mostly concerned about MU performance on ath10k which requires significant amount of buffering. > 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. Perhaps this could be dynamically adjusted to match the slowest station known to rate control in the future? Oh, and there's multicast.. Michał -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
