Hi Ben, Thanks for the info. I investigated further to find that the two firmware params ENABLE_RTSCTS and RTS_THRESHOLD are not respected by the firmware rate control. I completely ensured that these params are always set such that RTS/CTS can never happen. Yet I can see RTS/CTS exchanges. Further I found from the sniffed traces that these RTS/CTS exchanges happen whenever there are A-MPDU re-transmissions i.e. the whole A-MPDU is lost. I suppose with such an incident the firmware rate control infers collisions and thus activates RTS/CTS for the next A-MPDU.
Thus a crude workaround would be to bring down the A-MPDU re-transmissions. With lower bitrates (NSS-1, MCS-0), obviously I can see less RTS/CTS exchanges than with the higher ones. However, it doesn't help my purpose. I also played around aggregation. The default aggregation setting is to have AMSDUs of maximum size 3 within an A-MPDU. Unlike I imagined earlier, there is no significant change in the number of A-MPDU re-transmissions when I disable AMSDU completely (of course for the same link quality). I really wished that the firmware rate control totally respected the ENABLE_RTSCTS param. Nevertheless are there any better suggestions to lower the A-MPDU re-transmissions. It would be a great help to know. Thanks, Raj Joshi On Fri, Jul 22, 2016 at 10:21 AM, Ben Greear <[email protected]> wrote: > > > On 07/21/2016 07:54 PM, Raj Joshi wrote: >> >> I am operating VHT (802.11ac) in AP-client configuration and thus >> aggregation is inevitable (as per the standard) as well as desirable >> (I suppose). I am receiving all A-MSDUs and not A-MPDUs. Now since >> losses are expensive to recover in case of A-MSDUs than A-MPDUs, is >> that the reason that there are intermittent RTS/CTS frames by rate >> control? >> >> If the culprit is firmware rate-control, I can try setting the bitrate >> mask and check again. Also how can I force the use of A-MPDUs rather >> than A-MSDUs? If this is outside the purview of firmware rate control, >> then I can try this one as well. > > > AMPDU and AMSDU should work fine in STA and AP mode. If you are using IBSS, > then firmware must disable AMSDU since there seems to be some hardware bug > with > IBSS and AMSDU. > > I don't think you can affect RTS/CTS from the host. I think it would > require > a firmware code change to disable RTS/CTS rate-code entries. > > I think there is a way to set the AMSDU size, and you could make it small > enough to effectively disable AMSDU. > > Thanks, > Ben > > >> >> Thanks, >> Raj Joshi >> >> >> On Fri, Jul 22, 2016 at 12:44 AM, Ben Greear <[email protected]> >> wrote: >>> >>> On 07/21/2016 07:29 AM, Krishna Chaitanya wrote: >>>> >>>> >>>> On Thu, Jul 21, 2016 at 7:45 PM, Raj Joshi <[email protected]> >>>> wrote: >>>>> >>>>> >>>>> Hi all, >>>>> >>>>> I am trying to "completely" disable RTS/CTS. >>>>> >>>>> * Case 1: Using iw/iwconfig when I set the sender's RTS threshold to a >>>>> very high value (RTS thr=10000 B), I expect that no RTS should be >>>>> sent. However, it seems that this threshold is not being honored and I >>>>> can sniff large number of RTS/CTS frames. I verified that no A-MSDU is >>>>> exceeding 10000 B. >>>>> * Case 2: Interestingly, when I set the sender's RTS threshold to off >>>>> (RTS thr:off), compared to case #1 much less number of RTS/CTS frames >>>>> are seen and throughput is seen to improve. But I can still see >>>>> RTS/CTS frames being sent. >>>>> * Since the channel is clear and much isolated, and there is just one >>>>> AP and one STA, there is negligible chance of other factors playing >>>>> any role. >>>>> * There is one change though that I have disabled dynamic bandwidth >>>>> i.e. ar->wmi.pdev_param->dynamic_bw set zero in mac.c. I believe this >>>>> is likely not an issue as similar RTS/CTS behavior is seen even with >>>>> dynamic_bw set to 1 (there are no heterogeneous channel widths in the >>>>> network in any case). >>>>> * Another thing I noticed is that the RTS/CTS protection mode if set, >>>>> it is set to CTS-to-self, rather than "RTS/CTS" i.e. >>>>> ar->wmi.vdev_param->protection_mode in mac.c is either set to 1 or 0 >>>>> (depending upon use_cts_prot), but not 2. This probably seems not >>>>> helpful in hidden node scenarios as the CTS frame is unicasted instead >>>>> broadcasting. >>>>> >>>>> I would appreciate any pointers on completely disabling RTS/CTS as >>>>> well as the ability to choose between complete RTS/CTS versus >>>>> CTS-to-self whenever RTS/CTS is enabled. >>>> >>>> >>>> Which mode is this? For aggregated frames (AMPDU) RTS Threshold is >>>> not checked, so it can still be enabled >>> >>> >>> >>> Probably would require firmware changes to fully disable RTS/CTS >>> from what I recall when I was reading the rate-ctrl code... >>> >>> Thanks, >>> Ben >>> >>>> >>>> _______________________________________________ >>>> ath10k mailing list >>>> [email protected] >>>> http://lists.infradead.org/mailman/listinfo/ath10k >>>> >>> >>> >>> -- >>> Ben Greear <[email protected]> >>> Candela Technologies Inc http://www.candelatech.com >>> >> > > -- > Ben Greear <[email protected]> > Candela Technologies Inc http://www.candelatech.com Raj Joshi On Fri, Jul 22, 2016 at 11:21 AM, Ben Greear <[email protected]> wrote: > > > On 07/21/2016 07:54 PM, Raj Joshi wrote: >> >> I am operating VHT (802.11ac) in AP-client configuration and thus >> aggregation is inevitable (as per the standard) as well as desirable >> (I suppose). I am receiving all A-MSDUs and not A-MPDUs. Now since >> losses are expensive to recover in case of A-MSDUs than A-MPDUs, is >> that the reason that there are intermittent RTS/CTS frames by rate >> control? >> >> If the culprit is firmware rate-control, I can try setting the bitrate >> mask and check again. Also how can I force the use of A-MPDUs rather >> than A-MSDUs? If this is outside the purview of firmware rate control, >> then I can try this one as well. > > > AMPDU and AMSDU should work fine in STA and AP mode. If you are using IBSS, > then firmware must disable AMSDU since there seems to be some hardware bug > with > IBSS and AMSDU. > > I don't think you can affect RTS/CTS from the host. I think it would > require > a firmware code change to disable RTS/CTS rate-code entries. > > I think there is a way to set the AMSDU size, and you could make it small > enough to effectively disable AMSDU. > > Thanks, > Ben > > >> >> Thanks, >> Raj Joshi >> >> >> On Fri, Jul 22, 2016 at 12:44 AM, Ben Greear <[email protected]> >> wrote: >>> >>> On 07/21/2016 07:29 AM, Krishna Chaitanya wrote: >>>> >>>> >>>> On Thu, Jul 21, 2016 at 7:45 PM, Raj Joshi <[email protected]> >>>> wrote: >>>>> >>>>> >>>>> Hi all, >>>>> >>>>> I am trying to "completely" disable RTS/CTS. >>>>> >>>>> * Case 1: Using iw/iwconfig when I set the sender's RTS threshold to a >>>>> very high value (RTS thr=10000 B), I expect that no RTS should be >>>>> sent. However, it seems that this threshold is not being honored and I >>>>> can sniff large number of RTS/CTS frames. I verified that no A-MSDU is >>>>> exceeding 10000 B. >>>>> * Case 2: Interestingly, when I set the sender's RTS threshold to off >>>>> (RTS thr:off), compared to case #1 much less number of RTS/CTS frames >>>>> are seen and throughput is seen to improve. But I can still see >>>>> RTS/CTS frames being sent. >>>>> * Since the channel is clear and much isolated, and there is just one >>>>> AP and one STA, there is negligible chance of other factors playing >>>>> any role. >>>>> * There is one change though that I have disabled dynamic bandwidth >>>>> i.e. ar->wmi.pdev_param->dynamic_bw set zero in mac.c. I believe this >>>>> is likely not an issue as similar RTS/CTS behavior is seen even with >>>>> dynamic_bw set to 1 (there are no heterogeneous channel widths in the >>>>> network in any case). >>>>> * Another thing I noticed is that the RTS/CTS protection mode if set, >>>>> it is set to CTS-to-self, rather than "RTS/CTS" i.e. >>>>> ar->wmi.vdev_param->protection_mode in mac.c is either set to 1 or 0 >>>>> (depending upon use_cts_prot), but not 2. This probably seems not >>>>> helpful in hidden node scenarios as the CTS frame is unicasted instead >>>>> broadcasting. >>>>> >>>>> I would appreciate any pointers on completely disabling RTS/CTS as >>>>> well as the ability to choose between complete RTS/CTS versus >>>>> CTS-to-self whenever RTS/CTS is enabled. >>>> >>>> >>>> Which mode is this? For aggregated frames (AMPDU) RTS Threshold is >>>> not checked, so it can still be enabled >>> >>> >>> >>> Probably would require firmware changes to fully disable RTS/CTS >>> from what I recall when I was reading the rate-ctrl code... >>> >>> Thanks, >>> Ben >>> >>>> >>>> _______________________________________________ >>>> ath10k mailing list >>>> [email protected] >>>> http://lists.infradead.org/mailman/listinfo/ath10k >>>> >>> >>> >>> -- >>> Ben Greear <[email protected]> >>> Candela Technologies Inc http://www.candelatech.com >>> >> > > -- > Ben Greear <[email protected]> > Candela Technologies Inc http://www.candelatech.com Raj Joshi On Fri, Jul 22, 2016 at 10:21 AM, Ben Greear <[email protected]> wrote: > > > On 07/21/2016 07:54 PM, Raj Joshi wrote: >> >> I am operating VHT (802.11ac) in AP-client configuration and thus >> aggregation is inevitable (as per the standard) as well as desirable >> (I suppose). I am receiving all A-MSDUs and not A-MPDUs. Now since >> losses are expensive to recover in case of A-MSDUs than A-MPDUs, is >> that the reason that there are intermittent RTS/CTS frames by rate >> control? >> >> If the culprit is firmware rate-control, I can try setting the bitrate >> mask and check again. Also how can I force the use of A-MPDUs rather >> than A-MSDUs? If this is outside the purview of firmware rate control, >> then I can try this one as well. > > > AMPDU and AMSDU should work fine in STA and AP mode. If you are using IBSS, > then firmware must disable AMSDU since there seems to be some hardware bug > with > IBSS and AMSDU. > > I don't think you can affect RTS/CTS from the host. I think it would > require > a firmware code change to disable RTS/CTS rate-code entries. > > I think there is a way to set the AMSDU size, and you could make it small > enough to effectively disable AMSDU. > > Thanks, > Ben > > >> >> Thanks, >> Raj Joshi >> >> >> On Fri, Jul 22, 2016 at 12:44 AM, Ben Greear <[email protected]> >> wrote: >>> >>> On 07/21/2016 07:29 AM, Krishna Chaitanya wrote: >>>> >>>> >>>> On Thu, Jul 21, 2016 at 7:45 PM, Raj Joshi <[email protected]> >>>> wrote: >>>>> >>>>> >>>>> Hi all, >>>>> >>>>> I am trying to "completely" disable RTS/CTS. >>>>> >>>>> * Case 1: Using iw/iwconfig when I set the sender's RTS threshold to a >>>>> very high value (RTS thr=10000 B), I expect that no RTS should be >>>>> sent. However, it seems that this threshold is not being honored and I >>>>> can sniff large number of RTS/CTS frames. I verified that no A-MSDU is >>>>> exceeding 10000 B. >>>>> * Case 2: Interestingly, when I set the sender's RTS threshold to off >>>>> (RTS thr:off), compared to case #1 much less number of RTS/CTS frames >>>>> are seen and throughput is seen to improve. But I can still see >>>>> RTS/CTS frames being sent. >>>>> * Since the channel is clear and much isolated, and there is just one >>>>> AP and one STA, there is negligible chance of other factors playing >>>>> any role. >>>>> * There is one change though that I have disabled dynamic bandwidth >>>>> i.e. ar->wmi.pdev_param->dynamic_bw set zero in mac.c. I believe this >>>>> is likely not an issue as similar RTS/CTS behavior is seen even with >>>>> dynamic_bw set to 1 (there are no heterogeneous channel widths in the >>>>> network in any case). >>>>> * Another thing I noticed is that the RTS/CTS protection mode if set, >>>>> it is set to CTS-to-self, rather than "RTS/CTS" i.e. >>>>> ar->wmi.vdev_param->protection_mode in mac.c is either set to 1 or 0 >>>>> (depending upon use_cts_prot), but not 2. This probably seems not >>>>> helpful in hidden node scenarios as the CTS frame is unicasted instead >>>>> broadcasting. >>>>> >>>>> I would appreciate any pointers on completely disabling RTS/CTS as >>>>> well as the ability to choose between complete RTS/CTS versus >>>>> CTS-to-self whenever RTS/CTS is enabled. >>>> >>>> >>>> Which mode is this? For aggregated frames (AMPDU) RTS Threshold is >>>> not checked, so it can still be enabled >>> >>> >>> >>> Probably would require firmware changes to fully disable RTS/CTS >>> from what I recall when I was reading the rate-ctrl code... >>> >>> Thanks, >>> Ben >>> >>>> >>>> _______________________________________________ >>>> ath10k mailing list >>>> [email protected] >>>> http://lists.infradead.org/mailman/listinfo/ath10k >>>> >>> >>> >>> -- >>> Ben Greear <[email protected]> >>> Candela Technologies Inc http://www.candelatech.com >>> >> > > -- > Ben Greear <[email protected]> > Candela Technologies Inc http://www.candelatech.com _______________________________________________ ath10k mailing list [email protected] http://lists.infradead.org/mailman/listinfo/ath10k
