Completely disabling RTS/CTS

Completely disabling RTS/CTS

[Raj Joshi]

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

Re: Completely disabling RTS/CTS

[Krishna Chaitanya]

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

Re: Completely disabling RTS/CTS

[Ben Greear]

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

Re: Completely disabling RTS/CTS

[Raj Joshi]

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

Re: Completely disabling RTS/CTS

[Ben Greear]

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

Re: Completely disabling RTS/CTS

[Raj Joshi]

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