Go Back   Wireless and Wifi Forums > News > Newsgroups > alt.internet.wireless
Register FAQ Members List Calendar Search Today's Posts Mark Forums Read

 
Reply
 
LinkBack Thread Tools Display Modes
  #1 (permalink)  
Old 05-24-2007, 09:30 PM
lrtherond@gmail.com
Guest
 
Posts: n/a
Default 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 With Quote
  #2 (permalink)  
Old 05-24-2007, 10:55 PM
Jeff Liebermann
Guest
 
Posts: n/a
Default Re: How to tell if excessive collisions occur?

lrtherond@gmail.com hath wroth:

>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.


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:
<http://www.dd-wrt.com/wiki/index.php?title=Wl_command>
There's no collision data there, but lots of other goodies.


--
Jeff Liebermann jeffl@comix.santa-cruz.ca.us
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

Reply With Quote
  #3 (permalink)  
Old 05-24-2007, 11:08 PM
lrtherond@gmail.com
Guest
 
Posts: n/a
Default Re: How to tell if excessive collisions occur?

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!





On May 24, 2:55 pm, Jeff Liebermann <j...@comix.santa-cruz.ca.us>
wrote:
> lrther...@gmail.com hath wroth:
>
> >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.

>
> 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:
> <http://www.dd-wrt.com/wiki/index.php?title=Wl_command>
> There's no collision data there, but lots of other goodies.
>
> --
> Jeff Liebermann j...@comix.santa-cruz.ca.us
> 150 Felker St #D http://www.LearnByDestroying.com
> Santa Cruz CA 95060http://802.11junk.com
> Skype: JeffLiebermann AE6KS 831-336-2558




Reply With Quote
  #4 (permalink)  
Old 05-25-2007, 12:38 AM
lrtherond@gmail.com
Guest
 
Posts: n/a
Default Re: How to tell if excessive collisions occur?

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.

>From host AP to client AP:


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

>From client AP to host AP:


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


On May 24, 2:55 pm, Jeff Liebermann <j...@comix.santa-cruz.ca.us>
wrote:
> lrther...@gmail.com hath wroth:
>
> >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.

>
> 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:
> <http://www.dd-wrt.com/wiki/index.php?title=Wl_command>
> There's no collision data there, but lots of other goodies.
>
> --
> Jeff Liebermann j...@comix.santa-cruz.ca.us
> 150 Felker St #D http://www.LearnByDestroying.com
> Santa Cruz CA 95060http://802.11junk.com
> Skype: JeffLiebermann AE6KS 831-336-2558




Reply With Quote
  #5 (permalink)  
Old 05-25-2007, 01:46 AM
Jeff Liebermann
Guest
 
Posts: n/a
Default Re: How to tell if excessive collisions occur?

lrtherond@gmail.com hath wroth:

>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.


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

>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.


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:
<http://www.ruckuswireless.com/technology/beamflex.php>
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:
<http://www.newscientist.com/article.ns?id=dn6240>

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).

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


Warning... reading 802.11 standards will turn your brain to mush.
<http://standards.ieee.org/getieee802/802.11.html>
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:
<http://www.smallnetbuilder.com/content/view/85/106/>
See the tiny "Browse All Wireless" box menu on the left side.

Also, lots of interesting stuff at Wi-Fi Planet:
<http://www.wi-fiplanet.com/tutorials/>
The problem here is that the writing and information quality are
highly variable.

Also, try the FAQ at:
<http://wireless.wikia.com/wiki/Wi-Fi>

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


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.

--
Jeff Liebermann jeffl@comix.santa-cruz.ca.us
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

Reply With Quote
Reply


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are Off
[IMG] code is Off
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Epson Stylus Photo 830 Printer - Excessive Head Cleaning Si alt.comp.hardware 5 10-22-2007 10:22 PM
Verizon excessive bandwidth charges BW alt.cellular.verizon 4 04-30-2007 04:36 AM
excessive data transfer charge? shegeek72 alt.comp.hardware 14 11-17-2006 11:52 AM


All times are GMT. The time now is 07:18 PM.


Powered by vBulletin® Version 3.7.2
Copyright ©2000 - 2009, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO 3.2.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45