Thank you for the best explanation of RTS/CTS I've yet seen!
Kind regards,
Sevak
On Thu, 2003-07-31 at 14:16, [EMAIL PROTECTED] wrote:
Once you understand the function of RTS/CTS, it simply doesn't make sense to set it at the AP. The idea behind RTS is to overcome the effects of hidden node. Without RTS, when a client has a packet to send, it first "senses the air" to see if any other client is transmitting. If another client is transmitting, it holds off on sending the packet until the air is clear. This mechanism works great in an environment where all the clients can hear each other (such as an indoor WLAN). However, in an outdoor environment, not all clients can hear one another. So, let's say that you have two clients that are a mile away from each other. Neither one can hear the other. Let's say that both are uploading large files at the same time. Each one is doing the "sense the air, then transmit" thing. However, they can't hear each other, so they don't know that the other one is transmitting. This means that some of the time, they're probably both transmitting simultaneously, which results in a collision. Whenever there's a collision, both clients have to retransmit. This is why hidden node is such a problem when you start getting a lot of clients. None of them knows when the others are talking, so you end up with collisions all over the place. A lot of collisions results in a lot of retransmissions, which results in drastically reduced throughput. When you set RTS at the client, it causes the client to first send an RTS (Request To Send) packet to the AP, for any packets that are larger than the value you set it to. In other words, if you set RTS to 512, then any packets larger than 512 bytes will be preceeded by an RTS packet. Anything smaller than 512 bytes will go out with the normal "sense the air, then send" method. The RTS packet basically tells the AP that the client has a large packet that needs to be sent, and that it needs clear air to do so. The AP then issues a CTS (Clear To Send) packet. All the clients hear the CTS, and stop transmitting for a certain amount of time. The client that issued the RTS hears the CTS and starts transmitting, since the air is supposedly now clear. So, it avoids any collisions. As for what you should set RTS to, I recommend setting it low. We set our clients to 256. The thing to keep in mind is that any packet smaller than the RTS value will still get sent without an RTS first. Therefore, there's still a chance for a collision. If you set RTS to 1024, that's still a pretty large packet (the standard ethernet MTU is only 500 bytes or so more, at 1500). On a busy network with a lot of people transmitting, there's still a good chance that a packet that large will collide. There is less chance of a collision with smaller packets. RTS does introduce some overhead, which will somewhat reduce the total throughput on a lightly loaded network. However, it will allow you to scale to more subscribers without taking a serious hit due to collisions. We're currently running about 100 users per AP with RTS/CTS set to 256. Most of those clients are bandwidth-throttled to 128k or 256k. We're not seeing any slowdowns or throughput problems that we're aware of. The reason that you don't set RTS at the AP is that it doesn't have a hidden node problem. It can hear all the clients. If it needs to transmit, it can use the normal "sense the air, then send" method. Be aware that RTS/CTS only comes into play when a client is transmitting. It does nothing for receive traffic. Craig Quoting phantam <[EMAIL PROTECTED]>: > Ok so frag on ap could help? But rts doesn't how come what happens if u > change the rts on the ap? > > Chris > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Thursday, July 31, 2003 1:20 PM > To: [EMAIL PROTECTED] > > Just be aware that RTS needs to be set on the client devices. Don't set it > on > the AP. Leave the AP at 2346 (RTS disabled). > > Craig > > > Quoting Kevin Summers <[EMAIL PROTECTED]>: > > > > > In a crowded environment RTS being lowered can help because > > it allows a client radio to send a Request To Send to the AP > > and the AP tells everyone else to shut up while the client > > sends off it's packets. Something like 1024 would be a good > > test setting to start with just to see if it would help. > > > > The Frag Threshold tells the AP to break up the packets when > > the exceed the specified size. That causes more (but smaller) > > packets to be sent through the air, allowing for more clients > > to get data through. > > > > Typically you want to only adjust one at a time to see which > > one is going to be that little bit of "Magic" for your particular > > situation. > > > > Kevin Summers > > KISTech Internet Services Inc. > > www.kistech.com > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Behalf Of Eric Helm > > Sent: Thursday, July 31, 2003 9:29 AM > > To: [EMAIL PROTECTED] > > Subject: Re: [smartBridges] Smartbridge APPO max client associations? > > > > > > RTS and Frag are both set at 2346... not sure what this does or means? > any > > explanation and example of what changing these values does would be > great. > > > > Thanks, > > Eric > > ----- Original Message ----- > > From: phantam > > To: '[EMAIL PROTECTED]' > > Sent: Thursday, July 31, 2003 11:21 AM > > Subject: RE: [smartBridges] Smartbridge APPO max client associations? > > > > > > 35 should work matters if the RTS and frag are all tweaked or are they > all > > talking at the same time? The clients that is. I have about 28 on my > pop's > > and we had swore at one point not to go above 25 on our site hence we're > > upgrading personally we don't use splitters its another point of failure > > but > > it should work with the amp none the less. It really depends on use the > > 11mb > > RF is aggregate and shared so if everyones on or all the radios are > talking > > or evne the majority there going to go nuts. > > Chris > > -----Original Message----- > > From: Eric Helm [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, July 31, 2003 12:04 PM > > To: [EMAIL PROTECTED] > > What is the max client associations on an APPO without comprimising the > > performance of the throughput? > > I have 1 APPO that has 35 clients on it, and 1 APPO that has only 5 > > clients... the lesser of the two can get 2 Mbps throuput, which is what > we > > are feeding it from the backhaul, however on the APPO with 35 clients, > the > > max throughput I can get is about 700 to 800 Kbps. The setup is as > > follows: > > 1 APPO --> .5 Watt Amp --> Splitter --> 2 - 120 degree sector antennas. > > 1 APPO --> 1 - 120 degree sector antenna > > The APPO experiencing throughput problems it the one that has the > splitter > > on it.. could this be causing the problem? We just purchased the WISP > that > > setup the APPOs and I am not opposed to adding a 3rd APPO if that would > be > > a > > viable solution, but I am concerned if 35 clients is going to hinder the > > performance that much. > > Thanks, > > Eric > > > > > > The PART-15.ORG smartBridges Discussion List > > To Join: mailto:[EMAIL PROTECTED] (in the body type subscribe > > smartBridges <yournickname> > > To Remove: mailto:[EMAIL PROTECTED] (in the body type unsubscribe > > smartBridges) > > Archives: http://archives.part-15.org > > > > The PART-15.ORG smartBridges Discussion List > > To Join: mailto:[EMAIL PROTECTED] (in the body type subscribe > smartBridges > > <yournickname> > > To Remove: mailto:[EMAIL PROTECTED] (in the body type unsubscribe > > smartBridges) > > Archives: http://archives.part-15.org > > > > > > > The PART-15.ORG smartBridges Discussion List > To Join: mailto:[EMAIL PROTECTED] (in the body type subscribe > smartBridges <yournickname> > To Remove: mailto:[EMAIL PROTECTED] (in the body type unsubscribe > smartBridges) > Archives: http://archives.part-15.org > The PART-15.ORG smartBridges Discussion List To Join: mailto:[EMAIL PROTECTED] (in the body type subscribe smartBridges <yournickname> To Remove: mailto:[EMAIL PROTECTED] (in the body type unsubscribe smartBridges) Archives: http://archives.part-15.org
