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@xxxxxxxxxx <mailto:jpo234@xxxxxxxxxx>> 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@xxxxxxxxxxx
<mailto:wojciech.dubowik@xxxxxxxxxxx>> 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@xxxxxxxxxxx
<mailto:wojciech.dubowik@xxxxxxxxxxx>> 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@xxxxxxxxxx
<mailto:jpo234@xxxxxxxxxx>> 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@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
