ath10k performance, master branch from 20160407

Roman Yeryomin leroi.lists at gmail.com
Fri Apr 22 10:02:33 PDT 2016


On 19 April 2016 at 08:28, Michal Kazior <michal.kazior at tieto.com> wrote:
> On 18 April 2016 at 15:00, Roman Yeryomin <leroi.lists at gmail.com> wrote:
>> So it looks like Michal's patch set "ath10k: implement push-pull tx
>> model" introduced this regression - after restoring it from reverts
>> fq_codel_drop is hungry again.
>> Any ideas how to fix?
>
> If my hunch is right there's no easy (and proper) fix for that now.
>
> One of the patchset patches (ath10k: implement wake_tx_queue) starts
> to use mac80211 software queuing. This introduces extra induced
> latency and I'm guessing it results in fill-in-then-drain sequences in
> some cases which end up being long enough to make fq_codel_drop more
> work than normal.
>
> This is required for other changes and MU-MIMO performance
> improvements so this patch can't be removed.
>
> I guess you could try forcing fq_codel to use different target time,
> e.g. 20ms (instead of the default 5). You can do this using `tc`
> command like so:
>
>    tc qdisc replace dev wlan0 parent :1 fq_codel limit 1024 target 20ms
>    tc qdisc replace dev wlan0 parent :2 fq_codel limit 1024 target 20ms
>    tc qdisc replace dev wlan0 parent :3 fq_codel limit 1024 target 20ms
>    tc qdisc replace dev wlan0 parent :4 fq_codel limit 1024 target 20ms

this didn't change anything

qdisc mq 0: dev wlan0 root
qdisc fq_codel 8001: dev wlan0 parent :1 limit 1024p flows 1024
quantum 1514 target 20.0ms interval 100.0ms ecn
qdisc fq_codel 8002: dev wlan0 parent :2 limit 1024p flows 1024
quantum 1514 target 20.0ms interval 100.0ms ecn
qdisc fq_codel 8003: dev wlan0 parent :3 limit 1024p flows 1024
quantum 1514 target 20.0ms interval 100.0ms ecn
qdisc fq_codel 8004: dev wlan0 parent :4 limit 1024p flows 1024
quantum 1514 target 20.0ms interval 100.0ms ecn

> You might also want to try `pfifo` instead of `fq_codel` for comparison as well.

and this did, but for UDP only: 450Mbps instead of 30, TCP remained on 550Mbps


Regards,
Roman



More information about the ath10k mailing list