Lets make wifi fast again!
 help / color / mirror / Atom feed
* [Make-wifi-fast] ath10k+fq_codel+fqmac3.5 test kernel - woot!
@ 2016-04-26 20:03 Dave Taht
  2016-04-27  5:22 ` Michal Kazior
  0 siblings, 1 reply; 4+ messages in thread
From: Dave Taht @ 2016-04-26 20:03 UTC (permalink / raw)
  To: Michal Kazior, make-wifi-fast

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

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.....

4) I put .deb files of the build for ubuntu 16.04 at: http://www.taht.net/~d/

-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [Make-wifi-fast] ath10k+fq_codel+fqmac3.5 test kernel - woot!
  2016-04-26 20:03 [Make-wifi-fast] ath10k+fq_codel+fqmac3.5 test kernel - woot! Dave Taht
@ 2016-04-27  5:22 ` Michal Kazior
  2016-04-27  5:46   ` Dave Taht
  0 siblings, 1 reply; 4+ messages in thread
From: Michal Kazior @ 2016-04-27  5:22 UTC (permalink / raw)
  To: Dave Taht; +Cc: make-wifi-fast

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.


>
> 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?


Michał

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [Make-wifi-fast] ath10k+fq_codel+fqmac3.5 test kernel - woot!
  2016-04-27  5:22 ` Michal Kazior
@ 2016-04-27  5:46   ` Dave Taht
  2016-04-27  6:28     ` Michal Kazior
  0 siblings, 1 reply; 4+ messages in thread
From: Dave Taht @ 2016-04-27  5:46 UTC (permalink / raw)
  To: Michal Kazior; +Cc: make-wifi-fast

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [Make-wifi-fast] ath10k+fq_codel+fqmac3.5 test kernel - woot!
  2016-04-27  5:46   ` Dave Taht
@ 2016-04-27  6:28     ` Michal Kazior
  0 siblings, 0 replies; 4+ messages in thread
From: Michal Kazior @ 2016-04-27  6:28 UTC (permalink / raw)
  To: Dave Taht; +Cc: make-wifi-fast

On 27 April 2016 at 07:46, Dave Taht <dave.taht@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@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

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2016-04-27  6:28 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-04-26 20:03 [Make-wifi-fast] ath10k+fq_codel+fqmac3.5 test kernel - woot! Dave Taht
2016-04-27  5:22 ` Michal Kazior
2016-04-27  5:46   ` Dave Taht
2016-04-27  6:28     ` Michal Kazior

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox