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