[Madwifi-devel] ACK/CTS timeout, Slottime on long distance links From: Hasan Rashid - 2009-08-25 18:15:47 Attachments: Message as HTML ```Hi All, I have a few questions about ACK/CTS timeout. In a point-to-point or point-to-multipoint setup should all the stations be set to the same ack/cts timeout as set on the AP for the farthest station? Or since collisions are inevitable, therefore, each station should have the timeout set according to their individual distance to the AP? For long distance 5GHz links, should the slottime be adjusted according to the ack timeout or should it be left at the default 9us? I have seen that by increasing the slottime the number of excessive hardware retries almost stops, and stabilizes the throughput. I am using the following equation drawn from the athctrl utility: slottime = 9 + distance (m)/300(m/s) (-+1) Acktimeout = 2*slottime + 3 I am trying to understand the relationship between ACK timeout and slottime with regards to distance. I have also noticed that sometimes in a congested 5/2.4 GHz omni increasing the ack timeout helps improve the quality of service since the radios are now talking comparatively slower. I made that observation strictly from an ack timeout adjustment perspective. Any input is appreciated, TIA! Hasan R. ```
 [Madwifi-devel] ACK/CTS timeout, Slottime on long distance links From: Hasan Rashid - 2009-08-25 18:15:47 Attachments: Message as HTML ```Hi All, I have a few questions about ACK/CTS timeout. In a point-to-point or point-to-multipoint setup should all the stations be set to the same ack/cts timeout as set on the AP for the farthest station? Or since collisions are inevitable, therefore, each station should have the timeout set according to their individual distance to the AP? For long distance 5GHz links, should the slottime be adjusted according to the ack timeout or should it be left at the default 9us? I have seen that by increasing the slottime the number of excessive hardware retries almost stops, and stabilizes the throughput. I am using the following equation drawn from the athctrl utility: slottime = 9 + distance (m)/300(m/s) (-+1) Acktimeout = 2*slottime + 3 I am trying to understand the relationship between ACK timeout and slottime with regards to distance. I have also noticed that sometimes in a congested 5/2.4 GHz omni increasing the ack timeout helps improve the quality of service since the radios are now talking comparatively slower. I made that observation strictly from an ack timeout adjustment perspective. Any input is appreciated, TIA! Hasan R. ```
 Re: [Madwifi-devel] ACK/CTS timeout, Slottime on long distance links From: Derek Smithies - 2009-08-25 21:47:30 ```Hi, all nodes should use the same values. ack/cts/slot times are all measured in microseconds. The speed of light is 3x10^8 meters/second. In units of microseconds, the speed of light is 300 meters/microsecond. Admittedly, the speed of light is not accurately 300 meters/microsecond, some have used a slightly different value. However, 300 is "close enough". Thus, you have the origin of the 300 number in the slottime calculation >                slottime = 9 + distance (m)/300(m/s)  (-+1) it is rounded, and has 9 added to it. The value of 9 might represent the sifs time - don't know. I wonder if it should be 10. Now > >                Acktimeout = 2*slottime + 3 is the time (in microseconds) for the roundtrip. All nodes should use the same values. This makes network performance more reliable. Don't bother with rts and cts packets. using rts and cts lowers throughput. Derek. On Tue, 25 Aug 2009, Hasan Rashid wrote: > > Hi All, > >   > > I have a few questions about ACK/CTS timeout. In a point-to-point or > point-to-multipoint setup should all the stations be set to the same > ack/cts timeout as set on the AP for the farthest station? Or since > collisions are inevitable, therefore, each station should have the > timeout set according to their individual distance to the AP? For long > distance 5GHz links, should the slottime be adjusted according to the > ack timeout or should it be left at the default 9us? I have seen that by > increasing the slottime the number of excessive hardware retries almost > stops, and stabilizes the throughput. > >   > > I am using the following equation drawn from the athctrl utility: > >                slottime = 9 + distance (m)/300(m/s)  (-+1) > >                Acktimeout = 2*slottime + 3 > >   > > I am trying to understand the relationship between ACK timeout and > slottime with regards to distance. I have also noticed that sometimes in > a congested 5/2.4 GHz omni increasing the ack timeout helps improve the > quality of service since the radios are now talking comparatively > slower. I made that observation strictly from an ack timeout adjustment > perspective. Any input is appreciated, TIA! > >   > > Hasan R. > >   > > > -- Derek Smithies Ph.D. IndraNet Technologies Ltd. ph +64 3 365 6485 Web: http://www.indranet-technologies.com/ "The only thing IE should be used for is to download Fire Fox"```
 Re: [Madwifi-devel] ACK/CTS timeout, Slottime on long distance links From: Hasan Rashid - 2009-08-25 22:47:11 ```Derek, Here is my question, what is the indication in Madwifi of an insufficient acktimeout value. I mean if I set the acktimeout to 160 instead of 192 what in the driver would reflect its immediate impact? The only indicator that makes sense to me is ast_tx_xretries in struct ath_stats. Also, are you suggesting that if my links extend beyond a certain distance, I should adjust the slottime as well, or should I do it for anything beyond 300 meters? I have a 22 mile point-to-point link that I have been playing with, and adjusting the slottime definitely made things stable. I am leaving the RTS, CTS to default (which is disabled), and thanks for confirming that. So, Let's say I have a few clients connected within a 3-5 mile radius and then I connect a client 10 miles from the AP. If I adjust the acktimeout on the AP and all the nodes to accommodate this new client, wouldn't it slightly lower the bandwidth for the customers that are closer, granted the network would be stable? Thanks for your insight, I really appreciate your time. Hasan R. -----Original Message----- From: Derek Smithies [mailto:derek@...] Sent: Tuesday, August 25, 2009 2:47 PM To: Hasan Rashid Cc: madwifi-devel@... Subject: Re: [Madwifi-devel] ACK/CTS timeout, Slottime on long distance links Hi, all nodes should use the same values. ack/cts/slot times are all measured in microseconds. The speed of light is 3x10^8 meters/second. In units of microseconds, the speed of light is 300 meters/microsecond. Admittedly, the speed of light is not accurately 300 meters/microsecond, some have used a slightly different value. However, 300 is "close enough". Thus, you have the origin of the 300 number in the slottime calculation >                slottime = 9 + distance (m)/300(m/s)  (-+1) it is rounded, and has 9 added to it. The value of 9 might represent the sifs time - don't know. I wonder if it should be 10. Now > >                Acktimeout = 2*slottime + 3 is the time (in microseconds) for the roundtrip. All nodes should use the same values. This makes network performance more reliable. Don't bother with rts and cts packets. using rts and cts lowers throughput. Derek. On Tue, 25 Aug 2009, Hasan Rashid wrote: > > Hi All, > >   > > I have a few questions about ACK/CTS timeout. In a point-to-point or > point-to-multipoint setup should all the stations be set to the same > ack/cts timeout as set on the AP for the farthest station? Or since > collisions are inevitable, therefore, each station should have the > timeout set according to their individual distance to the AP? For long > distance 5GHz links, should the slottime be adjusted according to the > ack timeout or should it be left at the default 9us? I have seen that by > increasing the slottime the number of excessive hardware retries almost > stops, and stabilizes the throughput. > >   > > I am using the following equation drawn from the athctrl utility: > >                slottime = 9 + distance (m)/300(m/s)  (-+1) > >                Acktimeout = 2*slottime + 3 > >   > > I am trying to understand the relationship between ACK timeout and > slottime with regards to distance. I have also noticed that sometimes in > a congested 5/2.4 GHz omni increasing the ack timeout helps improve the > quality of service since the radios are now talking comparatively > slower. I made that observation strictly from an ack timeout adjustment > perspective. Any input is appreciated, TIA! > >   > > Hasan R. > >   > > > -- Derek Smithies Ph.D. IndraNet Technologies Ltd. ph +64 3 365 6485 Web: http://www.indranet-technologies.com/ "The only thing IE should be used for is to download Fire Fox" ```
 Re: [Madwifi-devel] ACK/CTS timeout, Slottime on long distance links From: Derek Smithies - 2009-08-25 23:35:41 ```Hi, Insufficient acktimeout, bad slottime have one immediate consequence: when the range goes beyond the value set by the calculations, you get lots and lots of dropped packets. *SET both slottime and acktimeout. use the calculation reported in the previous email. use the minstrel rate algorithm - don't bother with anything else. Watch the stats for a particular remote box If the stats for probability on all the rates is in the 80% or better, you have a reasonable chance that the timeouts are good. When the stats for all rates drops to < 10-20% level, you know your timeouts are bad. (or there is a radio transmission issue - noise, antenna, diversity etc). if your stats for some rates is around 50%, and otther rates is close to zero, you can guess that diversity is set wrong. > Also, are you suggesting that if my links extend beyond a certain distance, > I should adjust the slottime as well, or should I do it for anything beyond > 300 meters? I am not suggesting. I am stating that you will adjust both slottime and acktimeout. I am stating that you have the formula to calculate the correct value of slottime and acktimeout. For anything over 300m, you are going to have adjust both slottime and acktimeout. ============================================== > So, Let's say I have a few clients connected within a 3-5 mile radius and > then I connect a client 10 miles from the AP. If I adjust the acktimeout on > the AP and all the nodes to accommodate this new client, wouldn't it > slightly lower the bandwidth for the customers that are closer, it will slightly lower the bandwidth. The throughput will go improve. There will be no dropped TCP packets. Since TCP packets are not dropped, the congestion avoidance code in TCP will not lower the rate packets are put to the madwifi device. put everyone in this network that is spread over many miles onto the same values for ack and slottime. Derek. On Tue, 25 Aug 2009, Hasan Rashid wrote: > Derek, > > Here is my question, what is the indication in Madwifi of an insufficient > acktimeout value. I mean if I set the acktimeout to 160 instead of 192 what > in the driver would reflect its immediate impact? The only indicator that > makes sense to me is ast_tx_xretries in struct ath_stats. > > Also, are you suggesting that if my links extend beyond a certain distance, > I should adjust the slottime as well, or should I do it for anything beyond > 300 meters? I have a 22 mile point-to-point link that I have been playing > with, and adjusting the slottime definitely made things stable. > > I am leaving the RTS, CTS to default (which is disabled), and thanks for > confirming that. > > So, Let's say I have a few clients connected within a 3-5 mile radius and > then I connect a client 10 miles from the AP. If I adjust the acktimeout on > the AP and all the nodes to accommodate this new client, wouldn't it > slightly lower the bandwidth for the customers that are closer, granted the > network would be stable? > > Thanks for your insight, I really appreciate your time. > > Hasan R. > > -----Original Message----- > From: Derek Smithies [mailto:derek@...] > Sent: Tuesday, August 25, 2009 2:47 PM > To: Hasan Rashid > Cc: madwifi-devel@... > Subject: Re: [Madwifi-devel] ACK/CTS timeout, Slottime on long distance > links > > Hi, > all nodes should use the same values. > > ack/cts/slot times are all measured in microseconds. > > The speed of light is 3x10^8 meters/second. > > In units of microseconds, the speed of light is > 300 meters/microsecond. > > Admittedly, the speed of light is not accurately 300 meters/microsecond, > some have used a slightly different value. However, 300 is "close enough". > > Thus, you have the origin of the 300 number in the slottime calculation > >>                slottime = 9 + distance (m)/300(m/s)  (-+1) > > it is rounded, and has 9 added to it. > > The value of 9 might represent the sifs time - don't know. I wonder if > it should be 10. > > Now >> >>                Acktimeout = 2*slottime + 3 > is the time (in microseconds) for the roundtrip. > > All nodes should use the same values. This makes network performance more > reliable. > Don't bother with rts and cts packets. using rts and cts lowers > throughput. > > Derek. > > > On Tue, 25 Aug 2009, Hasan Rashid wrote: > >> >> Hi All, >> >>   >> >> I have a few questions about ACK/CTS timeout. In a point-to-point or >> point-to-multipoint setup should all the stations be set to the same >> ack/cts timeout as set on the AP for the farthest station? Or since >> collisions are inevitable, therefore, each station should have the >> timeout set according to their individual distance to the AP? For long >> distance 5GHz links, should the slottime be adjusted according to the >> ack timeout or should it be left at the default 9us? I have seen that by >> increasing the slottime the number of excessive hardware retries almost >> stops, and stabilizes the throughput. >> >>   >> >> I am using the following equation drawn from the athctrl utility: >> >>                slottime = 9 + distance (m)/300(m/s)  (-+1) >> >>                Acktimeout = 2*slottime + 3 >> >>   >> >> I am trying to understand the relationship between ACK timeout and >> slottime with regards to distance. I have also noticed that sometimes in >> a congested 5/2.4 GHz omni increasing the ack timeout helps improve the >> quality of service since the radios are now talking comparatively >> slower. I made that observation strictly from an ack timeout adjustment >> perspective. Any input is appreciated, TIA! >> >>   >> >> Hasan R. >> >>   >> >> >> > > -- Derek Smithies Ph.D. IndraNet Technologies Ltd. ph +64 3 365 6485 Web: http://www.indranet-technologies.com/ "The only thing IE should be used for is to download Fire Fox"```
 Re: [Madwifi-devel] ACK/CTS timeout, Slottime on long distance links From: Hasan Rashid - 2009-08-26 00:40:24 ```Thank you very much for the detailed response, this clarifies and confirms many things to me. Hasan R. -----Original Message----- From: Derek Smithies [mailto:derek@...] Sent: Tuesday, August 25, 2009 4:35 PM To: Hasan Rashid Cc: madwifi-devel@... Subject: RE: [Madwifi-devel] ACK/CTS timeout, Slottime on long distance links Hi, Insufficient acktimeout, bad slottime have one immediate consequence: when the range goes beyond the value set by the calculations, you get lots and lots of dropped packets. *SET both slottime and acktimeout. use the calculation reported in the previous email. use the minstrel rate algorithm - don't bother with anything else. Watch the stats for a particular remote box If the stats for probability on all the rates is in the 80% or better, you have a reasonable chance that the timeouts are good. When the stats for all rates drops to < 10-20% level, you know your timeouts are bad. (or there is a radio transmission issue - noise, antenna, diversity etc). if your stats for some rates is around 50%, and otther rates is close to zero, you can guess that diversity is set wrong. > Also, are you suggesting that if my links extend beyond a certain distance, > I should adjust the slottime as well, or should I do it for anything beyond > 300 meters? I am not suggesting. I am stating that you will adjust both slottime and acktimeout. I am stating that you have the formula to calculate the correct value of slottime and acktimeout. For anything over 300m, you are going to have adjust both slottime and acktimeout. ============================================== > So, Let's say I have a few clients connected within a 3-5 mile radius and > then I connect a client 10 miles from the AP. If I adjust the acktimeout on > the AP and all the nodes to accommodate this new client, wouldn't it > slightly lower the bandwidth for the customers that are closer, it will slightly lower the bandwidth. The throughput will go improve. There will be no dropped TCP packets. Since TCP packets are not dropped, the congestion avoidance code in TCP will not lower the rate packets are put to the madwifi device. put everyone in this network that is spread over many miles onto the same values for ack and slottime. Derek. On Tue, 25 Aug 2009, Hasan Rashid wrote: > Derek, > > Here is my question, what is the indication in Madwifi of an insufficient > acktimeout value. I mean if I set the acktimeout to 160 instead of 192 what > in the driver would reflect its immediate impact? The only indicator that > makes sense to me is ast_tx_xretries in struct ath_stats. > > Also, are you suggesting that if my links extend beyond a certain distance, > I should adjust the slottime as well, or should I do it for anything beyond > 300 meters? I have a 22 mile point-to-point link that I have been playing > with, and adjusting the slottime definitely made things stable. > > I am leaving the RTS, CTS to default (which is disabled), and thanks for > confirming that. > > So, Let's say I have a few clients connected within a 3-5 mile radius and > then I connect a client 10 miles from the AP. If I adjust the acktimeout on > the AP and all the nodes to accommodate this new client, wouldn't it > slightly lower the bandwidth for the customers that are closer, granted the > network would be stable? > > Thanks for your insight, I really appreciate your time. > > Hasan R. > > -----Original Message----- > From: Derek Smithies [mailto:derek@...] > Sent: Tuesday, August 25, 2009 2:47 PM > To: Hasan Rashid > Cc: madwifi-devel@... > Subject: Re: [Madwifi-devel] ACK/CTS timeout, Slottime on long distance > links > > Hi, > all nodes should use the same values. > > ack/cts/slot times are all measured in microseconds. > > The speed of light is 3x10^8 meters/second. > > In units of microseconds, the speed of light is > 300 meters/microsecond. > > Admittedly, the speed of light is not accurately 300 meters/microsecond, > some have used a slightly different value. However, 300 is "close enough". > > Thus, you have the origin of the 300 number in the slottime calculation > >>                slottime = 9 + distance (m)/300(m/s)  (-+1) > > it is rounded, and has 9 added to it. > > The value of 9 might represent the sifs time - don't know. I wonder if > it should be 10. > > Now >> >>                Acktimeout = 2*slottime + 3 > is the time (in microseconds) for the roundtrip. > > All nodes should use the same values. This makes network performance more > reliable. > Don't bother with rts and cts packets. using rts and cts lowers > throughput. > > Derek. > > > On Tue, 25 Aug 2009, Hasan Rashid wrote: > >> >> Hi All, >> >>   >> >> I have a few questions about ACK/CTS timeout. In a point-to-point or >> point-to-multipoint setup should all the stations be set to the same >> ack/cts timeout as set on the AP for the farthest station? Or since >> collisions are inevitable, therefore, each station should have the >> timeout set according to their individual distance to the AP? For long >> distance 5GHz links, should the slottime be adjusted according to the >> ack timeout or should it be left at the default 9us? I have seen that by >> increasing the slottime the number of excessive hardware retries almost >> stops, and stabilizes the throughput. >> >>   >> >> I am using the following equation drawn from the athctrl utility: >> >>                slottime = 9 + distance (m)/300(m/s)  (-+1) >> >>                Acktimeout = 2*slottime + 3 >> >>   >> >> I am trying to understand the relationship between ACK timeout and >> slottime with regards to distance. I have also noticed that sometimes in >> a congested 5/2.4 GHz omni increasing the ack timeout helps improve the >> quality of service since the radios are now talking comparatively >> slower. I made that observation strictly from an ack timeout adjustment >> perspective. Any input is appreciated, TIA! >> >>   >> >> Hasan R. >> >>   >> >> >> > > -- Derek Smithies Ph.D. IndraNet Technologies Ltd. ph +64 3 365 6485 Web: http://www.indranet-technologies.com/ "The only thing IE should be used for is to download Fire Fox" ```