Packet throughput (and those iperf data rate) with mac80211/ath9k is 20% worse than net80211/madwifi

[Klaus Kinski]

Hello all,

this is a blast from the past, but something that still bothers me.
I have two systems with Atheros/QCA cards:

System A:
  OS and driver: Linux 3.18.36 with last Madwifi/sample code from trunk

  WLAN card: AR5413 (Senao EMP-8602 PLUS-S)

System B:
  OS and driver: Linux 3.18.36 with mac80211/minstrel and ath9k from 
backports-4.2

  WLAN card: AR9280 (Compex WLE200NX)

While doing the performance measurements both systems are connected to a 
reference system

with a HF cable, so there should be no outside influences.

Both systems are running in 802.11a mode on channel 40.
The following table shows 802.11 data packets sent from system A and B 
generated by

iperf in UDP mode over a 2s interval:


Data rate  madwifi  %of total ath9k minstrel %of total

6.0855  2,3137  0,12
9.00  0,00220,07
12.0  0  0,00  230,07
18.0  0  0,00200,06
24.0  9  0,02210,07
36.0  8552,31200,06
48.0  8562,31240,08
54.0  34413  93,04  3156699,47
total  36988 100,00  31733100,00


It shows how many packets where sent at what data rate and the percentage of 
these packets
from the total. Both stacks are sending most packets with 54Mbit/s (93% and 
99%).

Overall Madwifi sends 36988 (= 100%) data packets whereas mac80211 only sends 
31733 (= 85%) data packets.

Does anybody know where this difference comes from? It's not the CPU; both 
systems

have plenty enough for the task. I'm pretty sure that the reason is in the 
stack,

probably mac80211.

I have asked basically the same question almost 6 years ago (see 
http://narkive.com/F8xI8bUp.1 ).

An interesting proposal at that time came from Adrian Chadd in 
http://narkive.com/F8xI8bUp.15:

  does madwifi have that net80211 "aggressive mode" by default, where it

  overrides the best-effort WME queue parameters to allow for bursting?

I could not find a mac80211 option to control this "aggressive mode". Is there 
one? Or a patch

to test it out?

Thanks in advance
  Joerg

Re: Packet throughput (and those iperf data rate) with mac80211/ath9k is 20% worse than net80211/madwifi

[Toke Høiland-Jørgensen]

Klaus Kinski  writes:

> Hello all,
>
> this is a blast from the past, but something that still bothers me.
> I have two systems with Atheros/QCA cards:
>
> System A:
>   OS and driver: Linux 3.18.36 with last Madwifi/sample code from trunk
>
>   WLAN card: AR5413 (Senao EMP-8602 PLUS-S)
>
> System B:
>   OS and driver: Linux 3.18.36 with mac80211/minstrel and ath9k from 
> backports-4.2
>
>   WLAN card: AR9280 (Compex WLE200NX)
>
> While doing the performance measurements both systems are connected to a 
> reference system
>
> with a HF cable, so there should be no outside influences.
>
> Both systems are running in 802.11a mode on channel 40.
> The following table shows 802.11 data packets sent from system A and B 
> generated by
>
> iperf in UDP mode over a 2s interval:

What version of iperf, and configured to which rate? Some versions of
iperf will send its traffic in very large bursts (see
http://burntchrome.blogspot.se/2016/09/iperf3-and-microbursts.html?m=1)
which could cause the queue inside ath9k to overflow (it is only 123
packets pre-4.10).

Did you try the latest mac80211/ath9k from 4.10? The queueing structure
changed dramatically, which would impact this, at least if it's a queue
overflow problem...

-Toke

Re: Packet throughput (and those iperf data rate) with mac80211/ath9k is 20% worse than net80211/madwifi

[Dave Taht]

On Mon, Jan 30, 2017 at 8:17 AM, Toke Høiland-Jørgensen  wrote:
> Klaus Kinski  writes:
>
>> Hello all,
>>
>> this is a blast from the past, but something that still bothers me.
>> I have two systems with Atheros/QCA cards:
>>
>> System A:
>>   OS and driver: Linux 3.18.36 with last Madwifi/sample code from trunk
>>
>>   WLAN card: AR5413 (Senao EMP-8602 PLUS-S)
>>
>> System B:
>>   OS and driver: Linux 3.18.36 with mac80211/minstrel and ath9k from 
>> backports-4.2
>>
>>   WLAN card: AR9280 (Compex WLE200NX)
>>
>> While doing the performance measurements both systems are connected to a 
>> reference system
>>
>> with a HF cable, so there should be no outside influences.
>>
>> Both systems are running in 802.11a mode on channel 40.
>> The following table shows 802.11 data packets sent from system A and B 
>> generated by
>>
>> iperf in UDP mode over a 2s interval:
>
> What version of iperf, and configured to which rate? Some versions of
> iperf will send its traffic in very large bursts (see
> http://burntchrome.blogspot.se/2016/09/iperf3-and-microbursts.html?m=1)
> which could cause the queue inside ath9k to overflow (it is only 123
> packets pre-4.10).
>
> Did you try the latest mac80211/ath9k from 4.10? The queueing structure
> changed dramatically, which would impact this, at least if it's a queue
> overflow problem...

Packet captures would be helpful. Aircaps, if possible, also.

> -Toke



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

Re: Packet throughput (and those iperf data rate) with mac80211/ath9k is 20% worse than net80211/madwifi

[Toke Høiland-Jørgensen]

Klaus Kinski  writes:

> The captures I used to create the statistics are here:
> https://drive.google.com/open?id=0ByFGz3ZH6JcYMGp0a05lYzBPNzA
>
> An obvious difference is, that Madwifi sends 5 packets in a row
> without waiting for an ACK whereas ath9k/mac80211 always seems to wait
> for an ACK. This seems to point to the "net80211 aggressive mode
> theory" https://wiki.freebsd.org/WifiAggressiveMode, IMHO.

I'm not too familiar with that part of the stack, but that seems
reasonable, yeah. AFAIK the "aggresive mode" is a pre-802.11n feature,
though, which is why you won't see that in ath9k. In 802.11n this kind
of bursting was replaced by aggregation, which you're not getting any of
since you're running in 802.11a mode, obviously.

The lack of bursting will translate to slightly lower throughput, which
will be why you see fewer packets transmitted by ath9k. Of course, if
your receiver supported aggregation, the numbers would look dramatically
better in ath9k's favour... ;)

-Toke

Re: Packet throughput (and those iperf data rate) with mac80211/ath9k is 20% worse than net80211/madwifi

[Wojciech Dubowik]

Madwifi has default best effort queue "tuned" for throughout

and its parameters are different from mac80211 defaults when

qos  (WME) is disabled.

You would have to dump qos settings for both systems before

comparing them. I guess the easiest way is to make sure QoS

is enabled and send video type of packets with iperf ... -S 0xa0

Wojtek


On 30/01/17 20:43, Toke Høiland-Jørgensen wrote:

Klaus Kinski  writes:


The captures I used to create the statistics are here:
https://drive.google.com/open?id=0ByFGz3ZH6JcYMGp0a05lYzBPNzA

An obvious difference is, that Madwifi sends 5 packets in a row
without waiting for an ACK whereas ath9k/mac80211 always seems to wait
for an ACK. This seems to point to the "net80211 aggressive mode
theory" https://wiki.freebsd.org/WifiAggressiveMode, IMHO.

I'm not too familiar with that part of the stack, but that seems
reasonable, yeah. AFAIK the "aggresive mode" is a pre-802.11n feature,
though, which is why you won't see that in ath9k. In 802.11n this kind
of bursting was replaced by aggregation, which you're not getting any of
since you're running in 802.11a mode, obviously.

The lack of bursting will translate to slightly lower throughput, which
will be why you see fewer packets transmitted by ath9k. Of course, if
your receiver supported aggregation, the numbers would look dramatically
better in ath9k's favour... ;)

-Toke

Re: Packet throughput (and those iperf data rate) with mac80211/ath9k is 20% worse than net80211/madwifi

[Wojciech Dubowik]

Then you need to use CONFIG debug flag. WMM parameters are not set when

MESH compile flag is enabled. At least I have had once such problem.

Wojtek

PS It would be actually nice to have sth like madwifi's wlanconfig ... 
list wme to


print QoS settings in current systems.


On 31/01/17 10:38, Klaus Kinski wrote:

I'm mostly interested in Ad-Hoc mode, e.g. IBSS.

Wojciech Dubowik > schrieb am Di., 31. Jan. 2017 
um 10:35 Uhr:


That's tricky but look at
http://w1.fi/cgit/hostap/tree/hostapd/hostapd.conf


tx_queue... are for AP and wmm_... for STA (over beacons).

These should be default parameters. You can also enable CONFIG
debug flag

for ath9k and it prints wme parameters when it starts.

Wojtek


On 31/01/17 10:18, Klaus Kinski wrote:

It seems that bursting can be controlled over nl80211 (see ,
specifically with NL80211_ATTR_WIPHY_TXQ_PARAMS. Unfortunately
this seems not to be exposed in iw. It's an attribute of
NL80211_CMD_SET_WIPHY.
Is there another tool that exposes txq params? If not, has
anybody thought about exposing it in iw? I might take a stab at it...

Regards
  Joerg

Wojciech Dubowik mailto:wojciech.dubo...@neratec.com>> schrieb am Di., 31. Jan.
2017 um 08:55 Uhr:

Madwifi has default best effort queue "tuned" for throughout

and its parameters are different from mac80211 defaults when

qos  (WME) is disabled.

You would have to dump qos settings for both systems before

comparing them. I guess the easiest way is to make sure QoS

is enabled and send video type of packets with iperf ... -S 0xa0

Wojtek


On 30/01/17 20:43, Toke Høiland-Jørgensen wrote:
> Klaus Kinski mailto:jpo...@outlook.de>>
writes:
>
>> The captures I used to create the statistics are here:
>> https://drive.google.com/open?id=0ByFGz3ZH6JcYMGp0a05lYzBPNzA
>>
>> An obvious difference is, that Madwifi sends 5 packets in
a row
>> without waiting for an ACK whereas ath9k/mac80211 always
seems to wait
>> for an ACK. This seems to point to the "net80211
aggressive mode
>> theory" https://wiki.freebsd.org/WifiAggressiveMode
, IMHO.
> I'm not too familiar with that part of the stack, but that
seems
> reasonable, yeah. AFAIK the "aggresive mode" is a
pre-802.11n feature,
> though, which is why you won't see that in ath9k. In
802.11n this kind
> of bursting was replaced by aggregation, which you're not
getting any of
> since you're running in 802.11a mode, obviously.
>
> The lack of bursting will translate to slightly lower
throughput, which
> will be why you see fewer packets transmitted by ath9k. Of
course, if
> your receiver supported aggregation, the numbers would look
dramatically
> better in ath9k's favour... ;)
>
> -Toke

Re: Packet throughput (and those iperf data rate) with mac80211/ath9k is 20% worse than net80211/madwifi

[Wojciech Dubowik]

On 31/01/17 10:46, Klaus Kinski wrote:
BTW, if I read the sources correctly, than IBSS mode uses the TXQ 
parameters from ieee80211_set_wmm_default with enable_qos = false 
which means that qparam.txop = 0, e.g. bursting is disabled. Am I right?
I guess so. But you need to look also at contention window sizes because 
it make a big impact on throughout with retries and collisions.


Jörg Pommnitz mailto:jpo...@outlook.de>> schrieb 
am Di., 31. Jan. 2017 um 10:37 Uhr:


I'm mostly interested in Ad-Hoc mode, e.g. IBSS.

Wojciech Dubowik mailto:wojciech.dubo...@neratec.com>> schrieb am Di., 31. Jan.
2017 um 10:35 Uhr:

That's tricky but look at
http://w1.fi/cgit/hostap/tree/hostapd/hostapd.conf


tx_queue... are for AP and wmm_... for STA (over beacons).

These should be default parameters. You can also enable CONFIG
debug flag

for ath9k and it prints wme parameters when it starts.

Wojtek


On 31/01/17 10:18, Klaus Kinski wrote:

It seems that bursting can be controlled over nl80211 (see ,
specifically with NL80211_ATTR_WIPHY_TXQ_PARAMS.
Unfortunately this seems not to be exposed in iw. It's an
attribute of NL80211_CMD_SET_WIPHY.
Is there another tool that exposes txq params? If not, has
anybody thought about exposing it in iw? I might take a stab
at it...

Regards
  Joerg

Wojciech Dubowik mailto:wojciech.dubo...@neratec.com>> schrieb am Di., 31.
Jan. 2017 um 08:55 Uhr:

Madwifi has default best effort queue "tuned" for throughout

and its parameters are different from mac80211 defaults when

qos  (WME) is disabled.

You would have to dump qos settings for both systems before

comparing them. I guess the easiest way is to make sure QoS

is enabled and send video type of packets with iperf ...
-S 0xa0

Wojtek


On 30/01/17 20:43, Toke Høiland-Jørgensen wrote:
> Klaus Kinski mailto:jpo...@outlook.de>> writes:
>
>> The captures I used to create the statistics are here:
>>
https://drive.google.com/open?id=0ByFGz3ZH6JcYMGp0a05lYzBPNzA
>>
>> An obvious difference is, that Madwifi sends 5 packets
in a row
>> without waiting for an ACK whereas ath9k/mac80211
always seems to wait
>> for an ACK. This seems to point to the "net80211
aggressive mode
>> theory" https://wiki.freebsd.org/WifiAggressiveMode
, IMHO.
> I'm not too familiar with that part of the stack, but
that seems
> reasonable, yeah. AFAIK the "aggresive mode" is a
pre-802.11n feature,
> though, which is why you won't see that in ath9k. In
802.11n this kind
> of bursting was replaced by aggregation, which you're
not getting any of
> since you're running in 802.11a mode, obviously.
>
> The lack of bursting will translate to slightly lower
throughput, which
> will be why you see fewer packets transmitted by ath9k.
Of course, if
> your receiver supported aggregation, the numbers would
look dramatically
> better in ath9k's favour... ;)
>
> -Toke

Re: Packet throughput (and those iperf data rate) with mac80211/ath9k is 20% worse than net80211/madwifi

[Rafał Miłecki]

On 31 January 2017 at 10:52, Wojciech Dubowik
 wrote:
> On 31/01/17 10:46, Klaus Kinski wrote:
>>
>> BTW, if I read the sources correctly, than IBSS mode uses the TXQ
>> parameters from ieee80211_set_wmm_default with enable_qos = false which
>> means that qparam.txop = 0, e.g. bursting is disabled. Am I right?
>
> I guess so. But you need to look also at contention window sizes because it
> make a big impact on throughout with retries and collisions.

Klaus: I feel you keep dropping linux-wireless when sending your
replies. Please don't do that.

Re: Packet throughput (and those iperf data rate) with mac80211/ath9k is 20% worse than net80211/madwifi

[Ben Greear]

One thing to consider:  Older ath9k and maybe madwifi used a different 
congestion control,
and it got higher throughput in optimal situations in our testing.  When it was 
removed
from the kernel, there was some effort to improve the minstrel_ht algorithm, 
but I don't
think it ever performed quite as well as far as bulk transfer is concerned.

Thanks,
Ben

On 01/31/2017 01:52 AM, Wojciech Dubowik wrote:



On 31/01/17 10:46, Klaus Kinski wrote:

BTW, if I read the sources correctly, than IBSS mode uses the TXQ parameters 
from ieee80211_set_wmm_default with enable_qos = false which means that 
qparam.txop = 0, e.g. bursting is disabled. Am I right?

I guess so. But you need to look also at contention window sizes because it 
make a big impact on throughout with retries and collisions.


Jörg Pommnitz mailto:jpo...@outlook.de>> schrieb am Di., 
31. Jan. 2017 um 10:37 Uhr:

I'm mostly interested in Ad-Hoc mode, e.g. IBSS.

Wojciech Dubowik mailto:wojciech.dubo...@neratec.com>> schrieb am Di., 31. Jan.
2017 um 10:35 Uhr:

That's tricky but look at
http://w1.fi/cgit/hostap/tree/hostapd/hostapd.conf


tx_queue... are for AP and wmm_... for STA (over beacons).

These should be default parameters. You can also enable CONFIG
debug flag

for ath9k and it prints wme parameters when it starts.

Wojtek


On 31/01/17 10:18, Klaus Kinski wrote:

It seems that bursting can be controlled over nl80211 (see ,
specifically with NL80211_ATTR_WIPHY_TXQ_PARAMS.
Unfortunately this seems not to be exposed in iw. It's an
attribute of NL80211_CMD_SET_WIPHY.
Is there another tool that exposes txq params? If not, has
anybody thought about exposing it in iw? I might take a stab
at it...

Regards
  Joerg

Wojciech Dubowik mailto:wojciech.dubo...@neratec.com>> schrieb am Di., 31.
Jan. 2017 um 08:55 Uhr:

Madwifi has default best effort queue "tuned" for throughout

and its parameters are different from mac80211 defaults when

qos  (WME) is disabled.

You would have to dump qos settings for both systems before

comparing them. I guess the easiest way is to make sure QoS

is enabled and send video type of packets with iperf ...
-S 0xa0

Wojtek


On 30/01/17 20:43, Toke Høiland-Jørgensen wrote:
> Klaus Kinski mailto:jpo...@outlook.de>> writes:
>
>> The captures I used to create the statistics are here:
>>
https://drive.google.com/open?id=0ByFGz3ZH6JcYMGp0a05lYzBPNzA
>>
>> An obvious difference is, that Madwifi sends 5 packets
in a row
>> without waiting for an ACK whereas ath9k/mac80211
always seems to wait
>> for an ACK. This seems to point to the "net80211
aggressive mode
>> theory" https://wiki.freebsd.org/WifiAggressiveMode
, IMHO.
> I'm not too familiar with that part of the stack, but
that seems
> reasonable, yeah. AFAIK the "aggresive mode" is a
pre-802.11n feature,
> though, which is why you won't see that in ath9k. In
802.11n this kind
> of bursting was replaced by aggregation, which you're
not getting any of
> since you're running in 802.11a mode, obviously.
>
> The lack of bursting will translate to slightly lower
throughput, which
> will be why you see fewer packets transmitted by ath9k.
Of course, if
> your receiver supported aggregation, the numbers would
look dramatically
> better in ath9k's favour... ;)
>
> -Toke





--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com