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 <[email protected]> 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 <[email protected]> >> 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 >>>> [email protected] >>>> http://lists.infradead.org/mailman/listinfo/ath10k >>>> >>> >>> -- >>> Ben Greear <[email protected]> >>> Candela Technologies Inc http://www.candelatech.com >> >> >> _______________________________________________ >> ath10k mailing list >> [email protected] >> http://lists.infradead.org/mailman/listinfo/ath10k >> > > > -- > Ben Greear <[email protected]> > Candela Technologies Inc http://www.candelatech.com > _______________________________________________ ath10k mailing list [email protected] http://lists.infradead.org/mailman/listinfo/ath10k
