On 27 Aug 2004 07:55:49 -0700,
(E-Mail Removed) (Harryman69)
wrote:
>I've got a problem with poor performance on a wireless network that
>I've installed and need some advice.
>
>Situation:
>
>Connected 9 Oil & Gas facilities via wireless bridges.(total of 9 hops
>to the end). Each hop has its own point-to-point link(throughputs
>about 500kbps with distances of about 20 miles each)
20 miles is a long path. There are timing issues past about 10 miles.
http://peertech.org/LongShotWiFiTiming
Since you didn't disclose the hardware, I can't determine if the
vendor has done anything useful to stretch the path.
In addition, you have a rather large interference potential. If the
20 mile path crosses over populated areas full of Wi-Fi pollution,
you're gonna get some serious packet loss.
There's a direct relationship between "reliability" and fade margin.
Getting a *LEGAL* 802.11b system to work at 20 miles usually ends up
with a rather lousy or insufficient fade margin. Therefore, you're
gonna get packet loss. Oh, let's do the numbers. For point to point,
the maximum legal power into a +24dBi dish is +24dBm (trust me).
Using the calculator at:
http://www.ydi.com/calculation/som.php
I get about 25dB fade margin (using zero loss for coax cables).
When going through 9 hops, packet loss is nearly fatal. For example,
if you get 10% packet loss (not unusual at this distance), 9 hops will
yield:
0.9 * 0.9 * 0.9 * 0.9 * 0.9 * 0.9 * 0.9 * 0.9 * 0.9 = 0.39
or 61% packet loss. Such a system would be useless because it would
spend most of its airtime resending lost packets.
Hopefully, with back to back radios, you've installed each pair of
radios on a different non-overlapping channel. If this is a store and
forward arrangement using a single radio at each point, give up now.
>Problem:
>Even though each of the individual links have a decent connection
>speed,
Another problem. You can't do that with streaming data. If you feed
a wireless bridge at a higher speed than it can empty its FIFO buffer,
the buffer will eventually overflow and drop packets. The lost
packets will need to be resent causeing an even larger backup of data
waiting to be sent, which causes more packets to be dropped, ad
nausium. Most wireless bridges have adequate local buffering to deal
with surges in traffic, but if the speed difference and the traffic
pattern is sufficiently large, this isn't gonna work. It's best to
drop packets on the sending end so that they can be easily requeued
without going over a wireless link. That means everything has to go
the same speed.
>the further away from the main office (facility #9) the
>throughput back to the main office drops. Facility #9 can't hardly
>even use the system to browse the internet b/c of slowness. Ping times
>round trip from Facility 9 to Main office are about 110msec, while the
>ping times at Facility 1 are around 15ms...and they have a very decent
>connection speed.
Sure. I can fix the connection speed to whatever I find convenient.
The radio may be going up and down, resending packets, and complaining
bitterly at the MAC level, but your connection speed will look
wonderful. Look for packet loss at the TCP level and if possible, at
the radio level. If you have SNMP monitoring in your unspecified
hardware, use it. (email for details and hints).
>Solutions:??
>Install a router at each facility and put each one on a separate
>subnet. The facilities do not need to have direct connection to each
>other, just back to the Frame Relay at the main office.
No way. Your redecorating the house while the foundation is rotting
out. Do some error rate monitoring and the problem should be obvious.
You might be lucky and find just one link is constipated, while the
others are doing fine.
>Does this make sense?
>any help would be greatly appreciated.
Yeah, help is possible. One question: Was this mess of 20 mile links
engineered, modeled, and properly calculated?
>thanks
>Mike
--
Jeff Liebermann
(E-Mail Removed)
150 Felker St #D
http://www.LearnByDestroying.com
Santa Cruz CA 95060 AE6KS 831-336-2558