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

[Dave Taht <dave.taht@gmail.com>]

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?

2) (long, speaking to the crowd for posterity)

I did, eventually, see codel_ecn_marks stats. Don't know why I did not
see them before. I see ecn marks in the capture, and the corresponding
ecn echo bits and cwr in the capture (with ecn enabled on both sides
via sysctl -w net.ipv4.tcp_ecn=1 )

in wireshark, to see it in acks (I am mostly doing tcp_upload testing)

ip.dsfield.ecn == 3

tcp.flags.cwr == 1 # respond to a mark or drop

and/or - to see the ecn-echo flag set

tcp.flags.ecn == 1

or:

(ip.dsfield.ecn == 3) or (tcp.flags.cwr == 1) or (
tcp.flags.ecn == 1)

you can determine the length of the queue by looking at these
timestamps also (any wireshark lua programmers out there?) but I've
never got further than eyeballing them, and/or using xplot.org (and
tcptrace -G) to look at the caps. Looked nice, queue a bit long,
still. :)

I put a ethernet capture up of a flent rtt_fair (both up and down at
the same time, ath9k with a fq_codel qdisc on the other side).
http://blog.cerowrt.org/captures/ath10k/fqwifi.cap.gz

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.

On Tue, Apr 26, 2016 at 10:22 PM, Michal Kazior <michal.kazior@tieto.com> wrote:
> On 26 April 2016 at 22:03, Dave Taht <dave.taht@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@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