* Completely disabling RTS/CTS @ 2016-07-21 14:15 Raj Joshi 2016-07-21 14:29 ` Krishna Chaitanya 0 siblings, 1 reply; 6+ messages in thread From: Raj Joshi @ 2016-07-21 14:15 UTC (permalink / raw) To: ath10k 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. Thanks, Raj Joshi -------------------------- More info on setup -------------------------- - QCA9880 (Compex wle900vx) - Ubuntu 16.04 x64 running kernel 4.7.0-rc4-wt-ath-201606202115 from ath.git - firmware-version: 10.2.4.70.9-2 _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Completely disabling RTS/CTS 2016-07-21 14:15 Completely disabling RTS/CTS Raj Joshi @ 2016-07-21 14:29 ` Krishna Chaitanya 2016-07-21 16:44 ` Ben Greear 0 siblings, 1 reply; 6+ messages in thread From: Krishna Chaitanya @ 2016-07-21 14:29 UTC (permalink / raw) To: Raj Joshi; +Cc: ath10k On Thu, Jul 21, 2016 at 7:45 PM, Raj Joshi <rajjoshi@comp.nus.edu.sg> 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 _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Completely disabling RTS/CTS 2016-07-21 14:29 ` Krishna Chaitanya @ 2016-07-21 16:44 ` Ben Greear 2016-07-22 2:54 ` Raj Joshi 0 siblings, 1 reply; 6+ messages in thread From: Ben Greear @ 2016-07-21 16:44 UTC (permalink / raw) To: Krishna Chaitanya, Raj Joshi; +Cc: ath10k On 07/21/2016 07:29 AM, Krishna Chaitanya wrote: > On Thu, Jul 21, 2016 at 7:45 PM, Raj Joshi <rajjoshi@comp.nus.edu.sg> 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 > 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] 6+ messages in thread
* Re: Completely disabling RTS/CTS 2016-07-21 16:44 ` Ben Greear @ 2016-07-22 2:54 ` Raj Joshi 2016-07-22 3:21 ` Ben Greear 0 siblings, 1 reply; 6+ messages in thread From: Raj Joshi @ 2016-07-22 2:54 UTC (permalink / raw) To: Ben Greear; +Cc: Krishna Chaitanya, ath10k 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. Thanks, Raj Joshi On Fri, Jul 22, 2016 at 12:44 AM, Ben Greear <greearb@candelatech.com> wrote: > On 07/21/2016 07:29 AM, Krishna Chaitanya wrote: >> >> On Thu, Jul 21, 2016 at 7:45 PM, Raj Joshi <rajjoshi@comp.nus.edu.sg> >> 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 >> 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] 6+ messages in thread
* Re: Completely disabling RTS/CTS 2016-07-22 2:54 ` Raj Joshi @ 2016-07-22 3:21 ` Ben Greear 2016-07-27 13:23 ` Raj Joshi 0 siblings, 1 reply; 6+ messages in thread From: Ben Greear @ 2016-07-22 3:21 UTC (permalink / raw) To: Raj Joshi; +Cc: Krishna Chaitanya, ath10k 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 <greearb@candelatech.com> wrote: >> On 07/21/2016 07:29 AM, Krishna Chaitanya wrote: >>> >>> On Thu, Jul 21, 2016 at 7:45 PM, Raj Joshi <rajjoshi@comp.nus.edu.sg> >>> 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 >>> 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] 6+ messages in thread
* Re: Completely disabling RTS/CTS 2016-07-22 3:21 ` Ben Greear @ 2016-07-27 13:23 ` Raj Joshi 0 siblings, 0 replies; 6+ messages in thread From: Raj Joshi @ 2016-07-27 13:23 UTC (permalink / raw) To: Ben Greear; +Cc: Krishna Chaitanya, ath10k 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 <greearb@candelatech.com> 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 <greearb@candelatech.com> >> wrote: >>> >>> On 07/21/2016 07:29 AM, Krishna Chaitanya wrote: >>>> >>>> >>>> On Thu, Jul 21, 2016 at 7:45 PM, Raj Joshi <rajjoshi@comp.nus.edu.sg> >>>> 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 >>>> 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 Raj Joshi On Fri, Jul 22, 2016 at 11:21 AM, Ben Greear <greearb@candelatech.com> 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 <greearb@candelatech.com> >> wrote: >>> >>> On 07/21/2016 07:29 AM, Krishna Chaitanya wrote: >>>> >>>> >>>> On Thu, Jul 21, 2016 at 7:45 PM, Raj Joshi <rajjoshi@comp.nus.edu.sg> >>>> 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 >>>> 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 Raj Joshi On Fri, Jul 22, 2016 at 10:21 AM, Ben Greear <greearb@candelatech.com> 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 <greearb@candelatech.com> >> wrote: >>> >>> On 07/21/2016 07:29 AM, Krishna Chaitanya wrote: >>>> >>>> >>>> On Thu, Jul 21, 2016 at 7:45 PM, Raj Joshi <rajjoshi@comp.nus.edu.sg> >>>> 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 >>>> 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] 6+ messages in thread
end of thread, other threads:[~2016-07-27 13:25 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-07-21 14:15 Completely disabling RTS/CTS Raj Joshi 2016-07-21 14:29 ` Krishna Chaitanya 2016-07-21 16:44 ` Ben Greear 2016-07-22 2:54 ` Raj Joshi 2016-07-22 3:21 ` Ben Greear 2016-07-27 13:23 ` Raj Joshi
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).