Lots of possible causes (self-interference, interference from other networks, too high an oversubscription/traffic level, etc.) but I'd suggest pulling the AP packet-retransmit percentage statistics and manually creating a bar graph with APs across the bottom and retrans percent on the vertical (Y) axis. Any APs that are running above about 10% or 15% are having RF problems. If all the problem APs are below 10% then it is likely that the latency problem is Ethernet-traffic-level related and not an RF/interference problem.

If it turns out to be a non-RF problem, is your network switched (with no MAC-layer filtering or protection from abnormally high traffic levels) or routed? Also, is per-client bandwidth-management in place and working?

David E. Smith wrote:

Okay, Scriv and I are stumped on this one.

Over the last couple of weeks, we've started seeing some very odd
oddness on a few of our 2.4GHz POPs. Not all, just some. Here's what
appears to be happening:

A couple times a day, usually during business hours, something somewhere
generates a massive amount of noise. Connections which report an RF
noise of -90 start showing noise levels of -60 (or worse in some cases),
as reported by our StarOS access point. If it really is RF noise, it's
very broad, as it's simultaneously hitting five or six POPs, some
several miles away, but all at the same time.

The towers are all running StarOS on Mikrotik RouterBoard hardware, with
a mix of Orinoco and Prism cards, some with amps, some not. Some have
sectored antennas (180 degrees), some have omnis. Between them, the
towers cover just about the entire 2.4 spectrum (obviously, one channel
per access point, but we're using at least channels 1, 4, 6, 8, and 11).

Those towers are basically identical to several other towers that aren't

The other really really weird part is the crazy latency. Pings to the
APs themselves are reliable, and our backhaul links (5.3 and 5.8 GHz)
don't seem to be affected. And pings to our end-customers don't seem to
get lost, they just take their sweet time getting there. While "the
event" is happening, I've seen pings that take in excess of twenty
seconds to complete their round trip.

64 bytes from icmp_seq=7 ttl=62 time=27239 ms

(I think that's my record. In that particular test, there were no
packets lost, they just took a very long time to get there.)

I've checked or replaced just about everything I can think of in our
network that might cause something like this, and frankly, I'm stumped.
I don't think it's a network problem (traffic bursts or similar) because
of the weird bursts of RF noise. But that'd have to be one helluva burst
of noise to do what it's doing - affecting every channel across ten
miles at once.

I can go into more detail on any part of the network if you like, though
I think all the likely-relevant details are covered here.


David Smith

Jack Unger ([EMAIL PROTECTED]) - President, Ask-Wi.Com, Inc.
Serving the License-Free Wireless Industry Since 1993
Author of the WISP Handbook - "Deploying License-Free Wireless WANs"
True Vendor-Neutral WISP Consulting-Training-Troubleshooting
Our next WISP Workshop is June 21-22 in Atlanta, GA.
Phone (VoIP Over Broadband Wireless) 818-227-4220  www.ask-wi.com

WISPA Wireless List: wireless@wispa.org


Archives: http://lists.wispa.org/pipermail/wireless/

Reply via email to