[Make-wifi-fast] ath10k+fq_codel+fqmac3.5 test kernel - woot!

[Michal Kazior]

On 27 April 2016 at 07:46, Dave Taht <dave.taht at gmail.com> wrote:
> 1) I am confused - I only see a single phy - this means one phy for
> both 2.4 and 5ghz? or do I just set them up with iw?

1 card is 1 phy. It may be dual-band. You can check this with `iw
list` or `iw phyX info`.


> 2) (long, speaking to the crowd for posterity)
[...]
> while *extremely* useful to see CE (yea! codel working!), seeing no
> wifi media induced loss at all.... is just unnatural!!! :) and rtt
> varies by about 40ms in some of these tests. But most of that was from
> the other side.

Well, wifi does a lot of re-transmits, even within a single "try",
right? And then you have the sw-retry.


Michał

>
> On Tue, Apr 26, 2016 at 10:22 PM, Michal Kazior <michal.kazior at tieto.com> wrote:
>> On 26 April 2016 at 22:03, Dave Taht <dave.taht at gmail.com> wrote:
>>> I got fqmac3.5 booted on the pcengines apu2d4 board and did do a few
>>> tests at 2.4ghz at HT20 to start with.
>>>
>>> 1) Although the captures indicate CE is being asserted, the statistics
>>> do not show that.
>>>
>>> root at apu2:/sys/kernel/debug/ieee80211/phy0# cat codel_ecn_mark
>>> 0
>>
>> Yeah. I've noticed that as well. The in-kernel codel.h does the ecn
>> thing slightly differently compared to codel5.h. I didn't really look
>> into it as my upload tests worked fine.
>
> codel5 added overload and drop and mark support. No tcp actually
> responds to "drop and mark", but it seemed like a good idea to signal
> the endpoint better when catastrophe was immanent & Overload support
> seems needed in a world where evil senders may one day exist. mainline
> fq_codel is pretty robust against that but overload behavior is a bit
> cpu and memory intensive.
>
> I have no problem with sticking with the mainline codel for now.
>
> One of these days I'll pester the tcp wg group (who are all busy
> redefining ecn to not be equivalent to loss) to do something about
> drop and mark....
>
>
>>>
>>> 2) an upload test: http://blog.cerowrt.org/flent/fqmac35/latency_controlled.png
>>>
>>> I also tested a rrul_be test to the heavily optimized ath9k box I
>>> have, it was pretty nice but still over 60ms. I have to figure out how
>>> to go about a/b-ing stuff, I have a few more ath10k boards on order.
>>>
>>> 3) also, the packet capture was *perfect* - not a trace of loss.
>>> really... don't need perfect! well,
>>> I guess, for testing.....
>>
>> Interesting. Did codel_drop show anything?
>
> Not on the ecn enabled tests. :)
>
> I will test harder, I had other issues today, like: I ended up not
> testing the ath10k wifi path at all for a while.
>
> http://blog.cerowrt.org/post/poking_at_powersave/
>
> The last plot was verrah interesting, I don't know what to make of it.
>
> tomorrow two more cards arrive so I can test both sides enabled this way.
>>
>>
>> Michał
>
>
>
> --
> Dave Täht
> Let's go make home routers and wifi faster! With better software!
> http://blog.cerowrt.org