Community discussions

 
ekkas
Long time Member
Long time Member
Posts: 562
Joined: Mon Sep 26, 2005 1:01 pm
Location: South Africa

Re: Confused about rts/cts

Fri Jan 22, 2010 1:19 pm

Sorry to revive this 'beaten to death' subject... ;-)
So I get it, only enable rts/cts on clients.
But what value for HW protection threshold is optimum? 2346(default on UBNT devices)? But with MTU at 1500, would any packet ever reach that size? (Permission to flame me for ignorance is granted) The 'default' when enabling it is 0, does that mean it is always enabled, or never? Assuming all AP & clients are on ROS 4.5
While I've got you here now, can someone explain where frame-lifetime would be of any use or need tweaking?

Ekkas
 
dada
Member Candidate
Member Candidate
Posts: 245
Joined: Tue Feb 21, 2006 1:44 pm

Re: Confused about rts/cts

Fri Jan 22, 2010 1:52 pm

Sorry to revive this 'beaten to death' subject... ;-)
So I get it, only enable rts/cts on clients.
But what value for HW protection threshold is optimum? 2346(default on UBNT devices)? But with MTU at 1500, would any packet ever reach that size? (Permission to flame me for ignorance is granted) The 'default' when enabling it is 0, does that mean it is always enabled, or never? Assuming all AP & clients are on ROS 4.5
While I've got you here now, can someone explain where frame-lifetime would be of any use or need tweaking?

Ekkas
The HW protection threshold defines a packet size which is allowed to sent without asking for the permission to sent. It means packets shorter than the limit are sent immediately by the client station. Larger ones has to use RTS and wait for CTS. So if you use 2346byte limit it is the same as dissabling the RTS/CTS on the client. In our network we use 512 bytes as the limit.

The 0 in threshold shoul mean any packet has to use RTS/CTS before it is being sent. At least there is nothing about special other meaning of zero threshold in:
http://wiki.mikrotik.com/wiki/Wireless

IMHO it is not wise to want to use RTS/CTS for very small packets...
 
CMack
just joined
Posts: 2
Joined: Wed Aug 25, 2010 3:00 am

Re: Confused about rts/cts

Tue Sep 07, 2010 6:33 pm

So...leave the AP RTS/CTS alone. This is how our AP is set at present. If I click on the Hardware Frag Threshold drop down it shows 256 (default) but I have not applied that, just left it like you see here.
Is this correct? Everything else looks fine?
Thanks
You do not have the required permissions to view the files attached to this post.
 
dada
Member Candidate
Member Candidate
Posts: 245
Joined: Tue Feb 21, 2006 1:44 pm

Re: Confused about rts/cts

Tue Sep 07, 2010 6:55 pm

So...leave the AP RTS/CTS alone. This is how our AP is set at present. If I click on the Hardware Frag Threshold drop down it shows 256 (default) but I have not applied that, just left it like you see here.
Is this correct? Everything else looks fine?
Thanks
The HW. Fragmentation Threshold has nothing to do with RTS/CTS. It should affect the maximum wireless frame size (http://wiki.mikrotik.com/wiki/Manual:Interface/Wireless). If you enable it (it means define a value between 256-3000) the MT will divide large frames into sequence of smaller ones (max size defined by hw. frag threshold). If you have this option disabled IMHO the size of the frames is in most cases defined by wireless interface MTU (1500 bytes by default) - the IP system will not generate larger packets or will fragment larger ones.
 
User avatar
TomjNorthIdaho
Forum Veteran
Forum Veteran
Posts: 981
Joined: Mon Oct 04, 2010 11:25 pm
Location: North Idaho
Contact:

Re: Confused about rts/cts

Fri Oct 08, 2010 3:20 am

I just have to put in my two cents here.........

I am a WISP with long range clients. I have several Mikrotik APs with around 100 (+/- 80 clients) where all of the clients are hidden from each other. AKA - no client can hear another client talking to the AP.

What I have found works best for APs in my network is the following:

All client APs are set to use RTS/CTS with a hardware-protection-threshold set at 32
- note 100% of nearly 1,000 clients system wide all use RTS/CTS and the RTS threshold is set at 32. Any client wanting to send anything bigger than 32 must use RTS first and wait for a CTS from the AP.

My APs do have hardware-protection-mode set to NONE.
note - do not even try using "cts to self" or "rts cts" on an AP like my load/distance because it will kill the throughput for everybody.

edit - add another note--- APs set to not use RTS/CTS will still respond to clients asking for a RTS by sending the requesting client a CTS. When a CTS is sent to a client, all clients on the AP stop transmitting which gives the client a clear and clean channel to send data to the AP (the client does not get stepped on). Without this RTS/CTS setup in place - there can be a ton of clients all transmitting at the same time and then nothing makes it to the AP from clients or from clients to the AP.

RTS/CTS does slow down the network - but - if you have a serious hidden node problem (where clients on your AP can not hear other clients on your AP) and you have more than 20ish clients, then give this a try.

I have played around with RTS/CTS settings for more than 5 years on large WISP networks and this is the only thing I have found that really works.
FYI - I have about 100 APs which range from customer connection counts from 30 to 150+ clients each

Tom Jones - a WISP up here in North Idaho
 
ste
Forum Guru
Forum Guru
Posts: 1797
Joined: Sun Feb 13, 2005 11:21 pm

Re: Confused about rts/cts

Fri Oct 08, 2010 12:14 pm

I just have to put in my two cents here.........

I am a WISP with long range clients. I have several Mikrotik APs with around 100 (+/- 80 clients) where all of the clients are hidden from each other. AKA - no client can hear another client talking to the AP.

What I have found works best for APs in my network is the following:

All client APs are set to use RTS/CTS with a hardware-protection-threshold set at 32
- note 100% of nearly 1,000 clients system wide all use RTS/CTS and the RTS threshold is set at 32. Any client wanting to send anything bigger than 32 must use RTS first and wait for a CTS from the AP.

My APs do have hardware-protection-mode set to NONE.
note - do not even try using "cts to self" or "rts cts" on an AP like my load/distance because it will kill the throughput for everybody.

edit - add another note--- APs set to not use RTS/CTS will still respond to clients asking for a RTS by sending the requesting client a CTS. When a CTS is sent to a client, all clients on the AP stop transmitting which gives the client a clear and clean channel to send data to the AP (the client does not get stepped on). Without this RTS/CTS setup in place - there can be a ton of clients all transmitting at the same time and then nothing makes it to the AP from clients or from clients to the AP.

RTS/CTS does slow down the network - but - if you have a serious hidden node problem (where clients on your AP can not hear other clients on your AP) and you have more than 20ish clients, then give this a try.

I have played around with RTS/CTS settings for more than 5 years on large WISP networks and this is the only thing I have found that really works.
FYI - I have about 100 APs which range from customer connection counts from 30 to 150+ clients each

Tom Jones - a WISP up here in North Idaho
I didnt make good experience using RTS/CTS. Used it on ROS4.5 and things are
getting worse. One client managed to reduce the performance of the whole
network to a minimum. Disabling RTS/CTS on this client made things better.
May be an implementation problem or an older atheros card who did not behave
well.
 
User avatar
TomjNorthIdaho
Forum Veteran
Forum Veteran
Posts: 981
Joined: Mon Oct 04, 2010 11:25 pm
Location: North Idaho
Contact:

Re: Confused about rts/cts

Fri Oct 08, 2010 6:34 pm

re:I didnt make good experience using RTS/CTS. Used it on ROS4.5 and things are
getting worse. One client managed to reduce the performance of the whole
network to a minimum. Disabling RTS/CTS on this client made things better.
May be an implementation problem or an older atheros card who did not behave
well.


Questions:
#1 Was the AP congested
#2 Were there 20+ish clients
#3 Was RTS/CTS turned off in the AP
#4 Were all clients set to use RTS/CTS with a small frame size to trigger a RTS request from each client
#5 Was the RTS/CTS threshold set to a low number on all clients (I use 32)

If #1 is no and#2 is less than 20 - then using RTS/CTS could actually slow down the network because the additional client timing delays to send RTS to the AP and receive back a CTS from the AP could actually take longer than just letting RED take care of the congestion. However - if you have more than 20ish clients then client RTS/CTS may actually be faster than RED

If #3 is if no/off - An AP should never be set for RTS/CTS. It just takes up a bunch of air time for the AP to send a RTS and wait for a CTS back from a client - never use RTS/CTS on an AP.
If the AP is set for CTS-to-Self - this will also slow down the network. With this setting in an AP, the AP is forced to send out a CTS at the highest rate that all clients can listen to. If you have a B connection to your AP, then the AP is forced to send a CTS at 1 or 2 or 5.5 or 11 meg rates. So if you have an AP with a client at a 54 meg connection and a B client with a 1 meg connection, your AP is forced to send a CTS at 1 meg rate for every client it talks to. This slows down the throughput for the entire network.

#4 - If using RTS/CTS in your client radios - all clients must use RTS/CTS. If you have a mix of some clients using RTS/CTS and some clients not using RTS/CTS then you are giving a poteintial unfair advantage for clients not using RTS/CTS to talk to the AP.
Example - An AP has 100 clients. 99 of the clients are set to use RTS/CTS and one client does not have RTS/CTS enabled. If this one non RTS/CTS client is trying to upload a large amount of data, then it will be stepping on the 99 other clients which must ask RTS and wait for CTS from the AP. When a client steps on another client then both clients loose there data they are sending/receiving and it takes some retries and more air time to correct the problem. If this happens in a congested network then you only add more congestion to the allready congested network.

#5 - small client RTS/CTS threshold settings are important. If a clinet has a large RTS/CTS threshold then the clients may have the ability to start talking to the AP without first sending a RTS and waiting for a CTS from the AP. So, in a congested network which uses RTS/CTS, a single client with a large RTS/CTS threshold can again cause collisions and add more congestion to an already congested network.

NOTE - in my opinion - RTS/CTS should only be used on larger networks with congestion and hidden nodes. Also if you use RTS/CTS it needs to be every client and not just some clients.
 
n21roadie
Forum Guru
Forum Guru
Posts: 1887
Joined: Fri Aug 07, 2009 10:36 pm
Location: Limerick,Ireland

Re: Confused about rts/cts

Sat Oct 09, 2010 7:28 pm

Well done TomjNorthIdaho your post is very informative
N21roadie,
Network 100% MT for Now?
 
ste
Forum Guru
Forum Guru
Posts: 1797
Joined: Sun Feb 13, 2005 11:21 pm

Re: Confused about rts/cts

Sat Oct 09, 2010 9:33 pm

re:I didnt make good experience using RTS/CTS. Used it on ROS4.5 and things are
getting worse. One client managed to reduce the performance of the whole
network to a minimum. Disabling RTS/CTS on this client made things better.
May be an implementation problem or an older atheros card who did not behave
well.


Questions:
#1 Was the AP congested
#2 Were there 20+ish clients
#3 Was RTS/CTS turned off in the AP
#4 Were all clients set to use RTS/CTS with a small frame size to trigger a RTS request from each client
#5 Was the RTS/CTS threshold set to a low number on all clients (I use 32)

If #1 is no and#2 is less than 20 - then using RTS/CTS could actually slow down the network because the additional client timing delays to send RTS to the AP and receive back a CTS from the AP could actually take longer than just letting RED take care of the congestion. However - if you have more than 20ish clients then client RTS/CTS may actually be faster than RED

If #3 is if no/off - An AP should never be set for RTS/CTS. It just takes up a bunch of air time for the AP to send a RTS and wait for a CTS back from a client - never use RTS/CTS on an AP.
If the AP is set for CTS-to-Self - this will also slow down the network. With this setting in an AP, the AP is forced to send out a CTS at the highest rate that all clients can listen to. If you have a B connection to your AP, then the AP is forced to send a CTS at 1 or 2 or 5.5 or 11 meg rates. So if you have an AP with a client at a 54 meg connection and a B client with a 1 meg connection, your AP is forced to send a CTS at 1 meg rate for every client it talks to. This slows down the throughput for the entire network.

#4 - If using RTS/CTS in your client radios - all clients must use RTS/CTS. If you have a mix of some clients using RTS/CTS and some clients not using RTS/CTS then you are giving a poteintial unfair advantage for clients not using RTS/CTS to talk to the AP.
Example - An AP has 100 clients. 99 of the clients are set to use RTS/CTS and one client does not have RTS/CTS enabled. If this one non RTS/CTS client is trying to upload a large amount of data, then it will be stepping on the 99 other clients which must ask RTS and wait for CTS from the AP. When a client steps on another client then both clients loose there data they are sending/receiving and it takes some retries and more air time to correct the problem. If this happens in a congested network then you only add more congestion to the allready congested network.

#5 - small client RTS/CTS threshold settings are important. If a clinet has a large RTS/CTS threshold then the clients may have the ability to start talking to the AP without first sending a RTS and waiting for a CTS from the AP. So, in a congested network which uses RTS/CTS, a single client with a large RTS/CTS threshold can again cause collisions and add more congestion to an already congested network.

NOTE - in my opinion - RTS/CTS should only be used on larger networks with congestion and hidden nodes. Also if you use RTS/CTS it needs to be every client and not just some clients.
The ap was congested. All Clients had Big latency.
Disabling the offending client solved problem. Disabling rts/cts on this
Cpe solved problem. All cpes had rts/cts enabled. Ap had rts/cts disabled.

Your complete right with your setup. But I saw it failing. My theory is that there
was a problem with ros 4.5 or the older atheros card. I could not verify this as
i cant see what they are exactly doing on air.
 
tamilmaran
Frequent Visitor
Frequent Visitor
Posts: 75
Joined: Mon Sep 05, 2011 9:36 pm

Re: Confused about rts/cts

Tue Oct 25, 2011 2:45 pm

im caught in the hidden node problem,having 20+clients in coverage of 1.5 km
using tplink 501g as cpe, got collision by some clients.
sing 433 ah 5.6 router os in bts
By last post in the forum,
i came to know.
1.To enable rts/cts nothing to change ap end settings.
2.Enable rts setting on all Client CPE's
but, i want know how do select the value of rts/cts mentioned in cpe.
may i use same value on all cpe's means which value is preferrable..?
if different values between cpe's means how do i select it ..?
help me solve the hidden node issue
If u like my post , then Hit the Karma! Thanks.
-
Thamizh Maran
RF Engineer
ZERONE Tech
India
 
ste
Forum Guru
Forum Guru
Posts: 1797
Joined: Sun Feb 13, 2005 11:21 pm

Re: Confused about rts/cts

Tue Oct 25, 2011 2:50 pm

im caught in the hidden node problem,having 20+clients in coverage of 1.5 km
using tplink 501g as cpe, got collision by some clients.
sing 433 ah 5.6 router os in bts
By last post in the forum,
i came to know.
1.To enable rts/cts nothing to change ap end settings.
2.Enable rts setting on all Client CPE's
but, i want know how do select the value of rts/cts mentioned in cpe.
may i use same value on all cpe's means which value is preferrable..?
if different values between cpe's means how do i select it ..?
help me solve the hidden node issue
You considered using nstreme or nv2?
 
tamilmaran
Frequent Visitor
Frequent Visitor
Posts: 75
Joined: Mon Sep 05, 2011 9:36 pm

Re: Confused about rts/cts

Thu Oct 27, 2011 7:21 pm

im caught in the hidden node problem,having 20+clients in coverage of 1.5 km
using tplink 501g as cpe, got collision by some clients.
sing 433 ah 5.6 router os in bts
By last post in the forum,
i came to know.
1.To enable rts/cts nothing to change ap end settings.
2.Enable rts setting on all Client CPE's
but, i want know how do select the value of rts/cts mentioned in cpe.
may i use same value on all cpe's means which value is preferrable..?
if different values between cpe's means how do i select it ..?
help me solve the hidden node issue
You considered using nstreme or nv2?
no nstream or nv2
i used basic 802.11 b/g/n protocol
If u like my post , then Hit the Karma! Thanks.
-
Thamizh Maran
RF Engineer
ZERONE Tech
India
 
User avatar
mramos
Member Candidate
Member Candidate
Posts: 230
Joined: Sun Nov 23, 2008 1:05 am
Location: S. B do Campo - SP - Brazil

Re: Confused about rts/cts

Sat Oct 29, 2011 2:35 am

Hi ...

I guess 32 is used 'cause it is the smalest TCP-IP packet we have so this force CPEs to wait for AP CTS.

I'm a bit confused anyway, because I thought RTS/CTS belongs to 802.11B or 802.11B/G.

So ... what about 802.11A or if 802.11G only is selected - and - if we do not use "default" data rates but configured ones?

Setting RTS/CTS on CPEs which are A modes (or locked to G mode) have the expected effect?

Regards;
Marcus Ramos
Electronics Technician
(Microwave HW, RF, antennas, propagation)
S.Paulo - Brazil
 
User avatar
NathanA
Forum Veteran
Forum Veteran
Posts: 793
Joined: Tue Aug 03, 2004 9:01 am

Re: Confused about rts/cts

Fri Mar 03, 2017 4:19 pm

Sorry to necro this thread, but I have looked everywhere else for an answer, have come up with zip, and given that this thread has the most relevant discussion of this subject vs. any other past thread, it seems appropriate to put it here.

The collective wisdom out there seems to agree that RTS threshold is only set on the client, and that APs by spec and by design just respond to every one of those with CTS. You don't "enable" RTS/CTS on an AP because all APs have CTS support enabled...it's required. Thus, the hw-protection-mode and hw-protection-threshold options are not applicable to mode "ap bridge", just to "station".

Okay, if that's truly the case, then why did CAPsMAN introduce those options in v2? CAPsMAN is only applicable to APs...you can't configure a CAP to be a "station". So why are those options there if they have no applicability to APs?

Can someone please clarify this for me?

Thanks,

-- Nathan
 
User avatar
bajodel
Long time Member
Long time Member
Posts: 545
Joined: Sun Nov 24, 2013 8:30 am
Location: Italy

Re: Confused about rts/cts

Mon Mar 06, 2017 7:56 pm

Nathan, I guess that as these settings exist on standalone ap (even if we actually don't use/need them) they had been ported to (ap mode) capsman (?)

Who is online

Users browsing this forum: No registered users and 15 guests