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

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.0        855      2,31        37              0,12
9.0        0          0,00        22                0,07
12.0      0          0,00      23                0,07
18.0          0          0,00        20                0,06
24.0          9          0,02        21                0,07
36.0          855        2,31        20                0,06
48.0          856        2,31        24                0,08
54.0          34413      93,04      31566                99,47
total      36988     100,00      31733                100,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 <jpo234-1ViLX0X+lBKELgA04lAiVw@public.gmane.org> 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=C3=B8iland-J=C3=B8rgensen <toke@tok=
e.dk> wrote:
> Klaus Kinski <jpo234-1ViLX0X+lBKELgA04lAiVw@public.gmane.org> 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 bac=
kports-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 g=
enerated 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=3D1)
> 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



--=20
Dave T=C3=A4ht
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 <jpo234@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]

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 <jpo234@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]

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 <wojciech.dubowik@neratec.com 
> <mailto:wojciech.dubowik@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
>     <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 <wojciech.dubowik@neratec.com
>>     <mailto:wojciech.dubowik@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 <jpo234@outlook.de <mailto:jpo234@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
>>         <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 <jpo234@outlook.de <mailto:jpo234@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 <wojciech.dubowik@neratec.com
>     <mailto:wojciech.dubowik@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
>         <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 <wojciech.dubowik@neratec.com
>>         <mailto:wojciech.dubowik@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 <jpo234@outlook.de
>>             <mailto:jpo234@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
>>             <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
<wojciech.dubowik@neratec.com> 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 <jpo234@outlook.de <mailto:jpo234@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 <wojciech.dubowik@neratec.com
>>     <mailto:wojciech.dubowik@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
>>         <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 <wojciech.dubowik@neratec.com
>>>         <mailto:wojciech.dubowik@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 <jpo234@outlook.de
>>>             <mailto:jpo234@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
>>>             <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 <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com