That's probably the very best anyone has got from that platform.
It can be really great as a CPE but P2P links are limited by the CPU.
The basic rules are:
- raw 802.11 (nstreme off) less CPU utilisation, but bad at max capacity and range due to ACK timing and small packet performance
- Nstreme on much higher CPU utilisation, and very good at capacity and range due to solving ACK issue and packet aggregation into frames.
- if you want a high capacity, long range link, you need CPU horsepower.
IMHO there should be a WIKI on which RB's or x86 platforms are suitable for what. Our co. went through that learning curve 2+ years ago, and it's a shame we don't share the consensus so new users can be pointed in the right direction.
Buying a board/solution designed for CPE and expecting 40-80Mbps throughput could be a disappointment to say the least.
How about a user+MT contributed Wiki? I suggest start this now as a barebones, people add and when there's consensus from everyone someone kindly posts it as a Wiki?
Note all bandwidths quoted are Bridged wireless<>ethernet throughput half duplex .
RB112 or equivalent 175MHz MIPS CPU - 17Mbps Nstreme, 30Mbps non-Nstreme
-Ideal for a CPE or a low-speed P2P link
RB230 or equivalent 266MHz x86 CPU - 35Mbps Nstreme, ?45Mbps non-Nstreme
- Ideal for a faster P2P link or smaller base station/AP
RB532 - 333MHz MIPS CPU - ?35Mbps Nstreme, ?40Mbps non-Nstreme
-Ideal for faster P2P link or a smaller base station/AP
RB532A - 400MHz MIPS CPU ?anyone tested that?
-Faster version of above: ideal for faster P2P links or medium base station/AP
Custom x86 1GHz+ CPU - 80Mbps Nstreme, ?65Mbps non-Nstreme
-Suited to high speed backhaul or sectored P2MP base station
-Over 200Mbps P2MP nstreme possible on properly configured hardware with multiple radio cards
(need various people's input and debate on the above numbers - there have been widely varying figures reported)
Need to specify Nstreme test scenario settings for consistency:
How about Polling on, best-fit, buffer size 4000?
And some notes
- Non-nstreme = 802.11, suffers with ACK timing/distance and small packets
- Connection-tracking turned off in IP-Firewall (not needed for backhaul)
- bridged ethernet<>radio throughput is quoted: L3 routed connections are generally faster compared to L2 bridged, as L2 "extra packets" are not passed.
- B/W's quoted using MT UDP bandwidth test **through** the routers not run "from the box" which consumes CPU power
Well, this would be useful with input from others -
If there's input & agreement on this could be fleshed out to be a useful Wiki.