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 <[email protected] <mailto:[email protected]>> schrieb
> am Di., 31. Jan. 2017 um 10:37 Uhr:
>
> I'm mostly interested in Ad-Hoc mode, e.g. IBSS.
>
> Wojciech Dubowik <[email protected]
> <mailto:[email protected]>> 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 <[email protected]
>> <mailto:[email protected]>> 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 <[email protected]
>> <mailto:[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
>> <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
>>
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 <[email protected] <mailto:[email protected]>> schrieb am Di., 31. Jan. 2017 um 10:37 Uhr:
>>
>> I'm mostly interested in Ad-Hoc mode, e.g. IBSS.
>>
>> Wojciech Dubowik <[email protected]
>> <mailto:[email protected]>> 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 <[email protected]
>>> <mailto:[email protected]>> 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 <[email protected]
>>> <mailto:[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
>>> <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 <[email protected]>
Candela Technologies Inc http://www.candelatech.com
On 31 January 2017 at 10:52, Wojciech Dubowik
<[email protected]> 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.