How to tell if excessive collisions occur?

I have 2 WRT54GL APs set-up in WDS configuration.

I would like to know if they are experiencing collisions while communicating. How do I do it?

I'm running dd-wrt on them both.

Reply to
lrtherond
Loading thread data ...

snipped-for-privacy@gmail.com hath wroth:

There are several ways none of which seem to be working well today.

One way is to telnet into one router and run: cd /proc/net cat wireless Hmmm... no results. That should work, but I'm getting nothing here.

Ah, foundit. The collisions are under: cd /proc/net cat dev You'll have to figure out a way to convert the output into something readable in row and column format.

This sorta cleans it up: cat /proc/net/dev | egrep "Receive | face | br0" which yields: | Inter-| Receive | Transmit | face | bytes packets errs drop fifo frame compressed multicast| bytes packets errs drop fifo colls carrier compressed | br0: 300837571 2160839 0 0 0 0 0 0 1501570628

2610321 0 0 0 0 0 0 Hmmm.... Not very useful. It shows zero collisions. Something is wrong, but I don't know exactly what. This type of statistics gathering relys heavily on extracting numbers from the counters on the Broadcom chips and that doesn't seem to be happening. I'll look into it and possibly submit a bug report.

Another way is to use ping. It won't tell you how many collisions, but it will give you a clear indication that there are collisions. Telnet to one router and ping the other. You want to do it via telnet to get better resolution.

/ # ping 192.168.1.50 PING 192.168.1.50 (192.168.1.50): 56 data bytes

64 bytes from 192.168.1.50: icmp_seq=0 ttl=127 time=1044.7 ms 64 bytes from 192.168.1.50: icmp_seq=0 ttl=127 time=1045.1 ms (DUP!) 64 bytes from 192.168.1.50: icmp_seq=2 ttl=127 time=4.4 ms 64 bytes from 192.168.1.50: icmp_seq=3 ttl=127 time=13.7 ms 64 bytes from 192.168.1.50: icmp_seq=4 ttl=127 time=7.0 ms 64 bytes from 192.168.1.50: icmp_seq=5 ttl=127 time=6.9 ms 64 bytes from 192.168.1.50: icmp_seq=6 ttl=127 time=3.3 ms 64 bytes from 192.168.1.50: icmp_seq=7 ttl=127 time=5.5 ms 64 bytes from 192.168.1.50: icmp_seq=8 ttl=127 time=4.6 ms 64 bytes from 192.168.1.50: icmp_seq=9 ttl=127 time=10.8 ms 64 bytes from 192.168.1.50: icmp_seq=10 ttl=127 time=5.7 ms 64 bytes from 192.168.1.50: icmp_seq=11 ttl=127 time=5.1 ms 64 bytes from 192.168.1.50: icmp_seq=12 ttl=127 time=6.4 ms

--- 192.168.1.50 ping statistics ---

9 packets transmitted, 8 packets received, 1 duplicates, 11% packet loss round-trip min/avg/max = 4.4/237.7/1045.1 ms

The ping time without collisions should be about 3-5 msec. If there were no collisions or interefernce, all the numbers would be identical. Obviously, they're not. The larger delays are caused by a collision or retransmission.

I just checked SNMP and there's nothing available for the MAC layer. It's all IP layer.

Also, look at the "wl" command:

There's no collision data there, but lots of other goodies.

Reply to
Jeff Liebermann

Jeff, thank you very much.

I have been reading this newsgroup for several hours and I saw that you consistently provide your help to those who need it. Your knowledge and willingness to help others are admirable and commendable.

I will follow your advice and report my findings.

I am trying to decide if I should allow CTS/RTS to kick in, but I find it hard to make this decision without knowing whether interferences/ hidden nodes are causing an excessive amount of collisions.

I am clearly new to 802.11 standards and I am reading everything I can in order to get a clue.

My other recent post in this group will tell you more about the environment that raised all those questions.

Thanks again!

packets errs drop fifo colls carrier compressed

1501570628 2610321 0 0 0 0 0 0
Reply to
lrtherond

For these tests, I shut down all wireless clients.

Obviously, when I telneted into the client AP from a workstation wired to the host AP, all telnet traffic was going over the air and hence, ping results from the client AP to the host AP must have been influenced by this extra traffic.

In all cases, I noticed chronic/periodic bursts of latency reaching between 30 ms and 50 ms. Average RTTs are somewhat decent, I guess.

64-byte packets:

--- 192.168.1.2 ping statistics ---

30 packets transmitted, 29 packets received, 3% packet loss round-trip min/avg/max = 1.5/6.3/58.8 ms

1472-byte packets:

--- 192.168.1.2 ping statistics ---

30 packets transmitted, 30 packets received, 0% packet loss round-trip min/avg/max = 2.7/5.9/25.4 ms

64-byte packets:

--- 192.168.1.1 ping statistics ---

30 packets transmitted, 30 packets received, 0% packet loss round-trip min/avg/max = 1.7/4.3/32.7 ms

1472-byte packets:

--- 192.168.1.1 ping statistics ---

30 packets transmitted, 30 packets received, 0% packet loss round-trip min/avg/max = 2.8/5.7/31.1 ms

packets errs drop fifo colls carrier compressed

1501570628 2610321 0 0 0 0 0 0
Reply to
lrtherond

snipped-for-privacy@gmail.com hath wroth:

Thanks. I realize that I spend too much time answering questions. I'll make an effort not to do it as often.

Interference and hidden nodes are handled differently. CTS/RTS flow control is very useful for hidden nodes. Your access point should orchestrate the transmission times of the various clients including those that can't hear each other. It works best with at least 8 or more clients and does next to nothing for a smaller number of clients. It will slow things down considerably, but does help reduce collisions. The problem is that a few vendors just don't seem to correctly honor flow contol packets or DTIM (Delivery Traffic Indication Message) broadcasts. The result is that they tend to monopolize the channel (airtime).

Interference is handled in several ways. One of the older schemes is to the reduce the packet size so that your packets have a greater chance of making it through the interference intact. This works very well for periodic interference like microwave ovens and impulse noise. Just shrink the packet until it fits in between the noise hits. That's done with the "fragmentation threshold". The catch is that more smaller packets mean more overhead and therefore slower thruput.

Beam steering and beam forming antennas (a form of MIMO) are other popular methods of reducing the effects of interference. Just punch a hole in the antenna pattern in the direction of the interference source. Read all about it at:

The catch is that you can't substitute external antennas.

Frankly, I don't think any of these are going to do very much for your massive RF polluted environment. The best you can do is install highly directional antennas on both the access points and clients in an attempt to not hear the nearby garbage. That's very difficult to do if the interference is moving or difficult to locate. Perhaps some RF shielded wall paper:

More seriously, I've had good results by simply making an effort to keep the wireless antennas away from outside windows and therefore away from interference. If the AP's and clients can directly see the sources of interference, the chances of them having an effect are reduced (but not eliminated).

Warning... reading 802.11 standards will turn your brain to mush.

Don't say I didn't warn you.

Actually, the reviews and tutorials on Tom's Hardware (Small Net Builder) are quite good and instructive:

See the tiny "Browse All Wireless" box menu on the left side.

Also, lots of interesting stuff at Wi-Fi Planet:

The problem here is that the writing and information quality are highly variable.

Also, try the FAQ at:

Nope. I don't want to go hopping all over the place answering question fragments and trying to assemble a picture of what you're doing. Please spend the time to get organized. Disclose what you're trying to accomplish and EXACTLY what you have to work with in the way of hardware and software. Add anything that you've done and what happened. Put it in one question, and you'll get decent answers. If there are any unrelated questions, keep them separate.

Reply to
Jeff Liebermann

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.