ath10k performance, master branch from 20160407

[Roman Yeryomin]

On 9 May 2016 at 15:26, Michal Kazior <michal.kazior at tieto.com> wrote:
> Hi Roman,
>
> On 22 April 2016 at 19:05, Roman Yeryomin <leroi.lists at gmail.com> wrote:
>> On 19 April 2016 at 18:35, Valo, Kalle <kvalo at qca.qualcomm.com> wrote:
>>> Michal Kazior <michal.kazior at tieto.com> writes:
>>>
>>>> On 19 April 2016 at 09:31, Roman Yeryomin <leroi.lists at gmail.com> wrote:
>>>>> On 19 April 2016 at 08:28, Michal Kazior <michal.kazior at tieto.com> wrote:
>>>>>
>>>>>> 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.
>>>>>
>>>>> But qca988x doesn't support MU-MIMO, AFAIK.
>>>>
>>>> Correct.
>>>>
>>>>
>>>>> Can this be made chip dependent?
>>>>
>>>> I guess it could but it'd arguably make the driver more complex and
>>>> harder to maintain. What we want is a long-term fix, not a short-term
>>>> one.
>>>
>>> But we should never go backwards and TCP dropping from 750 Mbps to ~550
>>> Mbps is a huge drop, so this is not ok. We have to do something to fix
>>> this, be it reverting the wake_tx_queue support, somehow disabling it by
>>> default or something.
>>
>> I would agree with Kalle here. This looks like very serious regression.
>> But I'm afraid I can only help with testing here.
>
> Can you give the following patch a try, please? I didn't get to
> reproduce your problem on a real AP135/AP152 board and instead tried
> to simulate a slow uni-proc system via KVM and cooling_device in
> sysfs. The patch does improve things in this synthetic setup for me.
>
>   http://lists.infradead.org/pipermail/ath10k/2016-May/007526.html
>

Unfortunately doesn't seem to make any difference at all (really, if
there is, it's less than 10Mbps).
Please see this thread also:
https://lists.openwrt.org/pipermail/openwrt-devel/2016-May/041445.html
That is with your and Eric's patch applied.

Regards,
Roman