Dynamic Bandwidth in hw rate control

[Gaurang Ramesh Naik]

Thanks Ben and Dave for your replies. So what I understand is that
dynamic bandwidth management is a part of the rate control algorithm
(which is implemented in firmware) and hence I have not much control
over how that works.

I am assuming your firmware is the one that can be downloaded from
http://www.candelatech.com/ath10k.php Is your kernel a modified one
too? When you say I can see the tx rate for each frame, is it through
some logs? I could try to get some info by using that. Thanks again.

Slightly unrelated, but is there a way I can play around with PIFS
value? I could not locate it in the ath10k source, so I am assuming it
is implemented in the firmware. I am trying to study some fairness
issues when legacy devices operate in the secondary channels.

On Thu, Jun 16, 2016 at 4:54 PM, Ben Greear <greearb at candelatech.com> wrote:
> On 06/16/2016 12:57 PM, Gaurang Ramesh Naik wrote:
>>
>> Hi Ben,
>>
>> Thanks for your reply.
>>
>> I wanted to know if the dynamic bandwidth option implemented in ath10k
>> is the same as that mentioned in the standard, or does it deviate? I
>> tried to look for any documentation on ath10k dynamic bandwidth, but
>> could not find any.
>>
>> If I am not wrong, on the secondary channel, the sender senses the
>> channel for PIFS interval of time immediately preceding the start of
>> the TXOP (9.19.2.8 in the standard). In the static mode, if the
>> secondary channel is sensed busy, the sender waits until all channels
>> become idle; but in the dynamic mode, the sender sends on the primary
>> and (adjacent) secondary channel that are not busy.
>>
>> However, the documentation for dynamic bandwidth in ath10k/mac.c seems
>> to suggest that the transmission retries are carried over narrower
>> bandwidth in dynamic mode. Does this mean the same as what is given in
>> the standard? Or is the dynamic mode implemented differently? Any help
>> is appreciated.
>
>
> I don't know exactly how this works.  At least the sensing and stuff is
> probably
> baked into the hardware.  What I notice is that the firmware passes a series
> of rates to the hardware to use for each packet, and it includes different
> bandwidth rates.
>
> If you used my firmware and my kernel, you can see the (successful) transmit
> rate for each frame.  Perhaps you could discover some info about how it
> works
> in that manner if you could reliably add noise on an adjacent channel.
>
> Upstream firmware can see tx rates using pktlog I think, but I have
> never tried that.
>
> Thanks,
> Ben
>
>
>>
>> Thanks,
>> Gaurang.
>>
>> On Thu, Jun 9, 2016 at 1:23 AM, Ben Greear <greearb at candelatech.com>
>> wrote:
>>>
>>>
>>>
>>> On 06/08/2016 08:10 PM, Gaurang Ramesh Naik wrote:
>>>>
>>>>
>>>> Hi,
>>>>
>>>> I needed a small clarification related to dynamic bandwidth setup. The
>>>> documentation in wmi.h says " When enabled HW rate control tries
>>>> different bandwidths when retransmitting frames."
>>>>
>>>> Does this mean that each packet is first always tried over VHT80 and
>>>> if that fails it goes to HT40 and then to HT20? I tried this with one
>>>> AP-Sta operating in VHT80 and one AP operating in its first secondary
>>>> channel. When I check the rx rate info using "iw dev wlanx station
>>>> dump", the bandwidth seems to sometimes alternate between 20 and 80,
>>>> but sometimes it stays fixed at 20. Hence, I was wondering what really
>>>> happens.
>>>
>>>
>>>
>>> For one thing, if the hardware detects interference on secondary
>>> channels,
>>> then it may decide to transmit a 20Mhz encoding.
>>>
>>> The rate-ctrl algs in the firmware differ from release to release, but
>>> the general goal is to transmit with the fastest encoding rate.
>>>
>>> Thanks,
>>> Ben
>>>
>>>>
>>>> Thanks,
>>>> Gaurang.
>>>>
>>>> _______________________________________________
>>>> ath10k mailing list
>>>> ath10k at lists.infradead.org
>>>> http://lists.infradead.org/mailman/listinfo/ath10k
>>>>
>>>
>>> --
>>> Ben Greear <greearb at candelatech.com>
>>> Candela Technologies Inc  http://www.candelatech.com
>>
>>
>> _______________________________________________
>> ath10k mailing list
>> ath10k at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/ath10k
>>
>
>
> --
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
>