Robert: I thank your comments... We are WISP from just two years... we use AP Lucent Orinoco.. In the begining we use Karlnet software but now we are in mode 802.11b. That change make us see the way to limit the bandwidth... We are using channel 1 with an omni for an PMtP and channel 6 and 11 with two PtP. And we are in a small city. Fist we make it with CBQ and after that we change the way to manage CBQ and we did it with CBQ.INIT, that is more easy to manage. I am subscribe to isp-wireless.com and I have discussing this problem several times. In moments that the delay of the pings are high, the pings to other clients are normal... besides the pings between wireless client are ALWAYS good and normal.. the only delay is SOMETIMES from the linux to the some clients... The Signal and Noise are very good (between 15 and 25 of SNR in all clients).. it is not so, I would have problem with all clients and I could tell you that I have never not delay with client limit to 128Kbps, and I have sometimes delay with the one who has less bandwidth. I think that is not a mistake in the configuration of CBQ becouse we are using the INI Files where I put only some values and all the rules are charge in Memory when I execute CBQ.INIT START. The AP Lucent Orinoco is configure in 2Mg, I will configure at 1Mg to minimalize the hidden node effect. I think is a problem of CBQ at that lower bandwith.. someone told me to use HTB or TBF.. Can they be better than CBQ..? We have besides a CISCO 3620 just configures to try and test limit bandwith over PPPoE.. Somebody tell that it is not the best solution... we will try... Thanks for any comment Bye ------------------------------------ Roberto Ravetti Intercom I.S.P Gerente de Servicios mailto: rravetti@itc.com.ar Te: (54) 3571 427 777 Rio Tercero - Cordoba - Argentina ------------------------------------ ----- Original Message ----- From: "ISC Robert Kryczalo" <robert.kryczalo@iscnet.pl> To: "Intercom - Roberto Ravetti" <rravetti@itc.com.ar>; <lartc@mailman.ds9a.nl> Sent: Friday, January 24, 2003 6:08 AM Subject: RE: [LARTC] Bandwidth Restrictions in Linux > Hello > > We are ISP and we give Internet Wireless Outdoor Service . The > > Base Station > > works in 802.11b and it is connected with a Linux Mandrake Server > > that make > > NAT. > 802.11b devices are by design experiencing "hidden node" effect. > > > > Besides the linux Server limit the bandwidth of each Wireless Client, per > > IP, using an aplication called Traffic Control with CBQ rules. > > The bandwidth > > that we are limit is at 32Kb, 48Kb, 64Kb, 72Kb, 96Kb and 128Kb. > > We have only > > 26 clients, son we are limiting only 26 Ip numbers at those bandwith. > If the wireless clients can' "hear" (by radio transmission) then it is > quite possible that they want to transmit at the same time resulting in a > radio collision at AP. It is a common effect when large distances and large > number of 802.11b nodes with directional antenas are involved. > > > > For example: > > The following is a ping to a client that has limited to 72Kbps.. in this > > moments he is not making any traffic in the internet, the normals > > delay time > > of ping would be around 6 ms... but in stead of look that > > response time.... > > The pings varies from 4ms up to 2 seconds... and I promisse you that he is > > not trafficking anything.. > > > > 64 bytes from 192.168.8.18: icmp_seq=0 ttl=128 time=1.479 sec > > 64 bytes from 192.168.8.18: icmp_seq=1 ttl=128 time=1.179 sec > > 64 bytes from 192.168.8.18: icmp_seq=2 ttl=128 time=1.329 sec > > 64 bytes from 192.168.8.18: icmp_seq=4 ttl=128 time=4.078 msec > > 64 bytes from 192.168.8.18: icmp_seq=6 ttl=128 time=12.622 msec > > 64 bytes from 192.168.8.18: icmp_seq=7 ttl=128 time=10.002 msec > > 64 bytes from 192.168.8.18: icmp_seq=8 ttl=128 time=610.729 msec > > 64 bytes from 192.168.8.18: icmp_seq=9 ttl=128 time=769.707 msec > > 64 bytes from 192.168.8.18: icmp_seq=10 ttl=128 time=788.533 msec > > 64 bytes from 192.168.8.18: icmp_seq=11 ttl=128 time=992.062 msec > > 64 bytes from 192.168.8.18: icmp_seq=12 ttl=128 time=999.109 msec > > 64 bytes from 192.168.8.18: icmp_seq=13 ttl=128 time=1.184 sec > > 64 bytes from 192.168.8.18: icmp_seq=14 ttl=128 time=1.009 sec > > 64 bytes from 192.168.8.18: icmp_seq=15 ttl=128 time=1.359 sec > > Great chance that it is "hidden node effect" or some mistake in cbq > configuration... try not to shape your clients and check if problem arises > (check utilization of interface connecting linux router with AP, too) ... > check qdisc and classes stats (tc -s -s -d may be of some help) > It is also possible that something close to your AP is transmiting at same > frequencies, look for some 2.4GHz devices (wireless cameras, other wireless > data transmission systems). Try to change channels ..... use at last 20MHz > separation between your AP (so use only channels 1,7,13). Those pings may > indicate interference.... Try to change polarization at AP and wireless > clients... check your cables and antenas... watch AP's stats, check signal > level at client antennas with something decent like Lucen Orinoco and > NetStumbler. You can find more details on other wireless mailing lists . > > The workarounds are.... > > Limit upload speeds to minimum (it can minimalize hidden node effect) > Use some decent 2.4GHz system ... like TDMA systems using karlnet's software > (Avaya COR and RORs, AirBus etc.) . they are not vulnerable to this effect. > > > > > > So I modify the INI files of the CBQ, and I give her 128Kbps and the pings > > now are normal.... 6ms, 4ms, 10ms... The following is the file I modify... > Hm, hidden node effect takes place when wireless utilization is high.... but > if you are sure that pings are normal for a long period of time with those > settings then there are probably some timing issues with CBQ working at low > speeds or you classify packets to wrong classes. As far as I remember CBQ > during my tests got stuck sometimes while trying to throttle traffic.Try to > send more details and perform more tests. > > Robert Kryczalo > > >
