* Dynamic Bandwidth in hw rate control @ 2016-06-09 3:10 Gaurang Ramesh Naik 2016-06-09 5:23 ` Ben Greear 0 siblings, 1 reply; 7+ messages in thread From: Gaurang Ramesh Naik @ 2016-06-09 3:10 UTC (permalink / raw) To: ath10k 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. Thanks, Gaurang. _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Dynamic Bandwidth in hw rate control 2016-06-09 3:10 Dynamic Bandwidth in hw rate control Gaurang Ramesh Naik @ 2016-06-09 5:23 ` Ben Greear 2016-06-16 19:57 ` Gaurang Ramesh Naik 0 siblings, 1 reply; 7+ messages in thread From: Ben Greear @ 2016-06-09 5:23 UTC (permalink / raw) To: Gaurang Ramesh Naik, ath10k 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@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/ath10k > -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Dynamic Bandwidth in hw rate control 2016-06-09 5:23 ` Ben Greear @ 2016-06-16 19:57 ` Gaurang Ramesh Naik 2016-06-16 20:06 ` Dave Taht 2016-06-16 20:54 ` Ben Greear 0 siblings, 2 replies; 7+ messages in thread From: Gaurang Ramesh Naik @ 2016-06-16 19:57 UTC (permalink / raw) To: Ben Greear; +Cc: ath10k 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. Thanks, Gaurang. On Thu, Jun 9, 2016 at 1:23 AM, Ben Greear <greearb@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@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/ath10k >> > > -- > Ben Greear <greearb@candelatech.com> > Candela Technologies Inc http://www.candelatech.com _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Dynamic Bandwidth in hw rate control 2016-06-16 19:57 ` Gaurang Ramesh Naik @ 2016-06-16 20:06 ` Dave Taht 2016-06-16 20:54 ` Ben Greear 1 sibling, 0 replies; 7+ messages in thread From: Dave Taht @ 2016-06-16 20:06 UTC (permalink / raw) To: Gaurang Ramesh Naik; +Cc: Ben Greear, ath10k On Thu, Jun 16, 2016 at 12:57 PM, Gaurang Ramesh Naik <gaurang@vt.edu> 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. So far as I know "rate control" is one of the major handwaves in the standard and differs from vendor to vendor and 802.11 standard to another. The pieces of how 802.11ac should fall back to narrower channels, I think you've correctly identified below (as for width)... but actually choosing a MCS rate, number of retries, formatting an aggregate... and other factors, are... different. I've tried to point at the first and best paper that shows how minstrel works here: http://blog.cerowrt.org/post/minstrel/ (and minstrel's known problems) but that's not what ath10k uses. I would *welcome* full documentation (or code!) on how ath10k choses its rates. Or any other wifi chipset's blob, frankly. > 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. > > Thanks, > Gaurang. > > On Thu, Jun 9, 2016 at 1:23 AM, Ben Greear <greearb@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@lists.infradead.org >>> http://lists.infradead.org/mailman/listinfo/ath10k >>> >> >> -- >> Ben Greear <greearb@candelatech.com> >> Candela Technologies Inc http://www.candelatech.com > > _______________________________________________ > ath10k mailing list > ath10k@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/ath10k -- Dave Täht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Dynamic Bandwidth in hw rate control 2016-06-16 19:57 ` Gaurang Ramesh Naik 2016-06-16 20:06 ` Dave Taht @ 2016-06-16 20:54 ` Ben Greear 2016-06-16 22:44 ` Gaurang Ramesh Naik 1 sibling, 1 reply; 7+ messages in thread From: Ben Greear @ 2016-06-16 20:54 UTC (permalink / raw) To: Gaurang Ramesh Naik; +Cc: ath10k 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@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@lists.infradead.org >>> http://lists.infradead.org/mailman/listinfo/ath10k >>> >> >> -- >> Ben Greear <greearb@candelatech.com> >> Candela Technologies Inc http://www.candelatech.com > > _______________________________________________ > ath10k mailing list > ath10k@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/ath10k > -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Dynamic Bandwidth in hw rate control 2016-06-16 20:54 ` Ben Greear @ 2016-06-16 22:44 ` Gaurang Ramesh Naik 2016-06-17 0:11 ` Ben Greear 0 siblings, 1 reply; 7+ messages in thread From: Gaurang Ramesh Naik @ 2016-06-16 22:44 UTC (permalink / raw) To: Ben Greear; +Cc: ath10k 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@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@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@lists.infradead.org >>>> http://lists.infradead.org/mailman/listinfo/ath10k >>>> >>> >>> -- >>> Ben Greear <greearb@candelatech.com> >>> Candela Technologies Inc http://www.candelatech.com >> >> >> _______________________________________________ >> ath10k mailing list >> ath10k@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/ath10k >> > > > -- > Ben Greear <greearb@candelatech.com> > Candela Technologies Inc http://www.candelatech.com > _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Dynamic Bandwidth in hw rate control 2016-06-16 22:44 ` Gaurang Ramesh Naik @ 2016-06-17 0:11 ` Ben Greear 0 siblings, 0 replies; 7+ messages in thread From: Ben Greear @ 2016-06-17 0:11 UTC (permalink / raw) To: Gaurang Ramesh Naik; +Cc: ath10k On 06/16/2016 03:44 PM, Gaurang Ramesh Naik wrote: > 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. With stock firmware you have very little control, though newer stock firmware has some tweaks to rate-ctrl that the driver does not yet support. With my firmware and driver, you can at least disable any particular rate. So, you could disable all 40Mhz rates, for instance. I'm not sure how useful that would be... > 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. Please read that page, it has links to kernel source. tx-rate will be reported up the stack in a normal manner (ie, somewhat like ath9k does it). You could instrument the kernel to save a histogram of tx-rates or something similar, perhaps. 'iw dev wlan0 station dump' and similar will now show expected tx rate, but that is an average or maybe the last tx rate reported, so it does not give a detailed view of what is happening. You can also sniff the air and see the rates in that manner (on any firmware, including stock). > 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. I don't have time to dig into this right now, but if you don't see anything in the driver related to this, then probably it requires firmware changes. Thanks, Ben > > On Thu, Jun 16, 2016 at 4:54 PM, Ben Greear <greearb@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@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@lists.infradead.org >>>>> http://lists.infradead.org/mailman/listinfo/ath10k >>>>> >>>> >>>> -- >>>> Ben Greear <greearb@candelatech.com> >>>> Candela Technologies Inc http://www.candelatech.com >>> >>> >>> _______________________________________________ >>> ath10k mailing list >>> ath10k@lists.infradead.org >>> http://lists.infradead.org/mailman/listinfo/ath10k >>> >> >> >> -- >> Ben Greear <greearb@candelatech.com> >> Candela Technologies Inc http://www.candelatech.com >> > -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2016-06-17 0:12 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-06-09 3:10 Dynamic Bandwidth in hw rate control Gaurang Ramesh Naik 2016-06-09 5:23 ` Ben Greear 2016-06-16 19:57 ` Gaurang Ramesh Naik 2016-06-16 20:06 ` Dave Taht 2016-06-16 20:54 ` Ben Greear 2016-06-16 22:44 ` Gaurang Ramesh Naik 2016-06-17 0:11 ` Ben Greear
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.