the importance of cpu power in 802.11n PtP links

Sorry if I have missed all the threads stressing the importance of cpu speeds in maximizing tcp throughput in 802.11n PtP links, but I wanted to give an example of my experience so far.

For a 26mi PtP 802.11n link (single chain), I was originally using matching RB411AH boards with SR17-15 cards. My one way TCP speeds would max out around 50-60mbps depending on which way I was going. I could get a stable 30mbps TCP symetrically. I noticed that my CPU resources were at 100% when doing these tests.

So I switched out one of my RB411AHs with a Dell Optiplex 780 and Core2 duo 2.6Ghz processor…

On a “send” test (from the perspective of the Optiplex) this upgrade resulted in a boost of between 10 and 20megs of TCP [75-80meg TCP total throughput] (over the 2xRB411AH setup) going from the x86 Optiplex system to the RB411AH. The CPU resources during this test max out at about 50% on the Optiplex and about 95% on the RB411AH.

On a “receive” test (from the perspective of the Optiplex) this upgrade resulted in no noticable boost in speed (over the 2xRB411AH setup.) The CPU resources during this test max out at about 10% on the Optiplex and a solid 100% on the RB411AH.

So, based on this testing, I can draw the following tentative conclusions about CPU resources in relation to 802.11n PtP links.

  1. “Send” tests tax the sending system’s cpu more than the receiving system.
  2. At the point you have solid CCQ and signal strength w/ decent fade margin, CPU resources are most likely going to be the biggest bottleneck in achiving max throughput on your links.

I do not have an RB800 to test, but it seems to me any talk about high speed single-chain (MCS 5 or higher) and dual-chain PtP links has to come to terms with the issue of CPU resources being the biggest bottlenecking factor to high TCP transfers. Obviously, it is not practical to install desktop PCs 300ft up on towers in most scenarios so depending on the raw horse power of the RB800 we may be looking at a situation where mikrotik simply does not currently produce powerful enough RBs to get max performance (based on my definition of performance) from 802.11n links.

I thought that this might be helpful for people who are getting into 802.11n. Last year, I started from square one with Mikrotik. I originally bought a bunch of RB230 and RB333 thinking that they would suffice for my needs. A year later and dozens more purchases (RB532A, RB600, RB433AH, RB411AH, etc and to say nothing of all the different mpci cards) I have finally come much closer to understanding the big picture of things. Hopefully this information will help others avoid some the false assumptions and trial-and-error purchases I made to get to where I am now.

I’m planning to get a second optiplex for the other end of this link and do more testing to see what a pure high-speed x86-based link will produce.

(In case anyone is wondering: No, I did not install the Optiplex on a tower to do my testing. I am lucky to have a professional waveguide based infrastucture with which to experiment on long distance PtP links. I do almost all my work inside and on the ground.)

My 26mi test link is configured this way:

RB411AH: Bridge mode
Optiplex: Client mode (no WDS, EOIP, or VPLS)

Freq: 5825 MHz
Mode: 802.11n only
HW retries: 15
Nstreme on/CSMA off/Polling on/Best Fit framing/3200 framer limit
Default TX levels
MCS2/3/4/5/6/7 rates only
single chain/all AMPDU/extension on (above)
ANI: on (client & AP)
Security: WPA PSK AES (dynamic keys)


x86 System Specs:

Dell Optiplex 780 (desktop form factor)
2.6Ghz Pentirum Dual Core
1GB DDR3 RAM
SATA 2 CF adapter (128mb CF card)
PCI to mPCI adapter
Integrated gigabit controller (req’d ROS 5.0 for correct drivers)

You do not test 11n. You test bandwith test.
In order to test 11n you should plug a testing system
on ethernet ports of the RB411AHs.

Perhaps this is true. Bandwidth test could be skewing the resource usage. I have read elsewhere that 802.11n needs multiple streams rather than synthetic bandwidth tests to reach best performance.

lol, it’s not a case of it “could” be skewing it, trust me it is… It takes a lot less CPU time to forward packets on RouterOS than it does to generate them with Bandwidth Test.

In my testing on RB600’s there was usually a 10-20mbit difference between btest from the RouterBoard, and doing a jperf/iperf test between devices plugged into each RouterBoard.

yup. ok.

My RBs are in sequence:

A - B - C - D - E - F - G (and so on)

If I run a test from A to G and check resources on B, C, D their resources are only 25%.