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't "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
