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
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 <[email protected]> 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
Klaus Kinski <[email protected]> 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
On Mon, Jan 30, 2017 at 8:17 AM, Toke H=C3=B8iland-J=C3=B8rgensen <toke@tok=
e.dk> wrote:
> Klaus Kinski <[email protected]> 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
Klaus Kinski <[email protected]> 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