Not sure if this is the answer, but here is something that I came across
with some StarOS/WRAP board links.
My busiest backhaul runs on a WRAP board. This WRAP board also has a
second card in it that serves as a 5Ghz access point in our downtown
area and feeds my office location. The main backhaul averages 2 to
6megs worth of traffic all of the time. The 5Ghz AP only does about 256
to 512K traffic, on average.
I have been using this setup for about a year with no problems, but in
the last ten days we started to see 2 to 5% packet loss on both
connections, with the downtown AP seeing the most problems. CPU load
was up in the 80 to 100% range, which seemed a little strange, since we
weren't anywhere near the full-speed throughput of the WRAP board.
Changing channels did not seem to have an effect.
After investigating with Lonnie, we found that there were a ton of
errors coming up on the Atheros interfaces. This can be an indication
of noise or of too much rate shifting. The Atheros card doesn't have a
good noise indicator, but if the card takes a long time to associate and
has a ton of errors on the interface - there is probably noise present.
With all of the errors, the cards were having to re-transmit, using up
additional CPU cycles. This reduced the overall throughput of the
radio down to about 10meg or so of throughput between the two cards.
When the CPU load went above 80percent, it started to drop packets.
I tried several different things, but what seemed to make the most
difference was to lock the rates on the cards (both were set to Auto) -
the AP card is set to 12meg, and the BH card is set to 24meg - and to
limit the amount of traffic coming down the backhaul with a cbq rule.
With these changes in place, throughput went up considerably and the
packet loss completely disappeared.
This is with StarOS, but you may get similar results with Mikrotik and
Atheros cards.
Matt Larsen
[EMAIL PROTECTED]
David E. Smith wrote:
Okay, I'm a bit puzzled here, and since there are a few folks out
there playing with these, maybe you'll have some advice.
I just put up a pair of RouterBoard 532s for a heavily-trafficked
backhaul link. It's about as simple a setup as you can get - just
Ethernet up to one Atheros, running as an AP, across a 1/2 mile link
to a client, back down the Ethernet. Simple enough, eh? Since it's
just one radio hop, I haven't set up WDS or anything fancy, just a few
simple routing statements to direct traffic from one end to the other.
Using the RouterOS built-in tests, this link claims to be capable of
almost 40Mbps one-way. I know the tests are somewhat idealized, and
probably a bit optimistic, but I'm having trouble getting speeds even
a third of that.
I don't believe it's an RF issue, because it's a short link with good
antennas. Signal strength is around -58, noise is in the mid-90s.
Also, when there's no other traffic on the link, I can get the same
"test" performance there that I was getting on my workbench, where the
built-in bandwidth tests report 35+ Mbps.
It's just that the darn boards seem to choke in the face of real-world
traffic. (My real traffic load is around 10Mbps aggregate, balanced
about 80-20 between upload and download.)
I've tried hopping around to different frequencies, which I didn't
expect to help. I've tried both enabling and disabling their
proprietary NStreme protocol, and enabling/disabling radio
compression. I haven't yet experimented with M3P (the "packet packer
protocol" option), but I'm a bit skeptical on it as well.
The (informal) testing I've done thus far shows the link not really
handling traffic beyond about 15Mbps or so. (The "informal" testing
was done with a few Web-based speed tests. More formal testing, with
tools like nuttcp or qcheck, will be coming soon, but I'm really
skeptical at this point.)
Any suggestions on how to further tune the performance on these boards
would be welcome.
Thanks!
David Smith
MVN.net
--
WISPA Wireless List: wireless@wispa.org
Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless
Archives: http://lists.wispa.org/pipermail/wireless/
