I have recently completed a round of tests to find out if the CSMA Disable function in v3.0b5 actually helps with throughput when multiple transmitters are active at the same time.

My purpose is not to solve the 'noisy-enviroment' issue but to solve problems associated with radios that can 'hear' eachother causing them to backoff. In these circumstances becuase of the backoff issue thoughput drops alot despite the excellent link conditions.

Setup:

AP -> RB532 running v3.0b5 with EMP-8602 radio and 5.5 dBi omni
CPE -> RB112 running v3.0b5 with EMP-8602 radio and 5.5 dBi omni

Center Frequency: 2412 MHz
Band: 2.4ghz-b/g
Data-Rate(s): Auto
All tx-power rates: 1
The seperation was approx 12ft
Signal viewed from AP (tx/rx): -44/-42

To simulate a nearby wifi device I setup a Airlink 802.11b/g router with a computer on the ethernet, and a laptop connected to the wireless. The wireless on the router of also set to the frequency of 2412 MHz. The laptop was set to receive a continuous data stream that was limited at 5 Mbps.

A 2nd laptop was connected to the RB532 via ethernet, and was setup to use Mikrotik's bandwidth tester. This laptop was configured to send data to the RB112, thus all traffic was generated by the laptop.

Test Case 1: Nstreme ON, No Polling


This test case showed absolutely no difference in the thoughput with CSMA Disabled turned on. As a result I checked the CPE device to verify it was correctly getting the CSMA Disable flag. I found that if polling is off, then the CSMA disable flag doesn't pass to the CPE. As a result I reran the same tests with polling on.

Test Case 2: Nstreme ON, Polling ON


This test cearly shows something wrong the the CSMA disable feature. I reran these tests over and over, and over. I tried 5Mhz channels, 10 Mhz channels, I tried using all mikrotik devices (replacing the Airlink router with anouther routerboard). I tried numerous other tests but in every case I ended up with the same results. Turning on the CSMA Disable feature almost always ended up with worse performance, and not once did I see an improvement.

As a side note, when running the 2nd transmitter (ie the Airlink), I was able to achieve 5 Mbps consistently throughout the testing, while the RouterOS link was flucuating heavily as shown in the above graphs.

My current thoughts on this issue are mixed. I completely understand the CSMA backoff feature in not a magic fix-it button for poor wireless links, or extremely noisy enviroments. However, in a case like this where I am using a standard wifi router, disabling the CSMA function should have made the RouterOS link go back to the full available bandwidth (as shown with just one transmitter in the graphs), and the Airlink should have backed-off and that speed should've dropped.

Another test setup I completed was to test the effect of CSMA Disable on two 2.4Ghz radios in a RB532 mounted in a PacWireless DCE case. Again this would be for situations where each radio is feeding grid antennas that point in different directions. Again in the scenario the CSMA backoff is not required as the receiving ends are very far apart. Again my tests showed that CSMA disable had no good effects and seemed to cause even greater flucuations in the max/min thoughput.

In this state I applaud Mikrotik for striving to give their customers what we asked for, but it just isn't working as it should. I am going to continue testing with other settings such as manual data-rates, etc.
I encourage those that are looking forward to this feature to complete some simple tests and post them here, as the more 'hard data' we collect for Mikrotik the faster the issues will be worked out.

Try running your tests without NStreme and see how things work. We had a real world envirnoment with 32 CPE and ping times were horrible with NStreme enabled. Turning it off gave us consistent ping times in the range to 2-5ms. With NStreme on were we seeing 20-160ms!

I like the idea of NStreme, polling and the ability to disable CSMA but it appears to actually cause more problems in a PtMP environment.

However, we do see improvement on PtP links with NStreme and polling. I'm wondering if Mikrotik isn't testing with loaded APs and just a single CPE.

This post is solely to do with the Disable CSMA option in RouterOS v3, you cannot activate the disable CSMA option unless you use Nstreme. This is why all the tests were completed with Nstreme on.

Try running your tests without NStreme and see how things work. We had a real world envirnoment with 32 CPE and ping times were horrible with NStreme enabled. Turning it off gave us consistent ping times in the range to 2-5ms. With NStreme on were we seeing 20-160ms!

I like the idea of NStreme, polling and the ability to disable CSMA but it appears to actually cause more problems in a PtMP environment.

However, we do see improvement on PtP links with NStreme and polling. I'm wondering if Mikrotik isn't testing with loaded APs and just a single CPE.

actually nstreme helps us with better ping time.
without nstreme is like 20-150ms, with nstreme about 10-20ms

We've not had time to clear the lab and try the CSMA-disable yet in the new Beta, so can't contribute in terms of experience.
But a general note, Nstreme does "packet reprocessing", putting data into "frames". In a high-noise environment, loss of a "frame" can affect more than one packet, which might be contributory to the observations here.
Certainly that's consistent with the "variable ping times" BelieveWireless was seeing (nstreme on:off).

Have you tried smaller framer limit in Nstreme?
No proof but a guess that might affect results - smaller framer limit should mean loss of a given frame losing fewer packets - at the expense of airside efficiency - IMHO.
Hope to be able to put some equipment together in the lab for similar tests soon.

Regards

CableFree Solutions

a question about frame size:
if i change the fram size on ap, do I have to change it also on the cpe, or the nstream protocol is controlled only bu the ap?

Regards

We'll play with the frames and see what we find. It's possible that's the cause of the problem and why PtP links fair better.

Does the frame size and policy need to match on the AP and CPE?

The CPE automatically adapts to the frame size of the AP, you don't need to set it on the CPE.

--Tom

It's not the framer policy. We tried none as well as the other options. Tried sizes 1500, 2000 and 3500 (or something like that). Nothing helped the ping times. Turning off NStreme fixes it immediately.

Were you in any way close to CPU max ?
Nstreme uses up a lot of CPU% on slower boards.
If the CPU is anywhere near max, you would see some variation for sure.

Regards

CableFree Solutions

i think there is something related to wds and nstream, in fact on the same tower, we have a ping issue on a havily loaded AP and no issue on an AP with only 4 customers. I tried changin freq. and other with no help.

So I hope that the upcoming v3 will help a lot using pseudobridge and letting the bridge traffic on the ap bypassing the ip firwall.
Our cpu is about 60% (532 at 330mhz) with both havily loaded and low laoded AP.

regards

8602s are very bad with noise btw... ive found this and others have repoted it on the forums as well

i have several that will loose links in the lab for 1-3 minutes on all channels if various cordless phones ring... the same tests on CM9, R52 and SR2's would only affect a ping or two, if that, between points at 1 sec intervals.


Im sure your tests are valid as the 8602 is constant across all..but i would like to see the results of any single of the tests run with another card in the same enviroment.

Great post and well thought out test but have you had a chance to retry with an alternative card (like R52's)? I'm guessing that as the R52 is a Mikrotik card then it's probably what Mikrotik use in the lab when they tested this feature and as jo2jo said, many have reported issues with the 8602's that you tried.

I would like to know if disabling CSMA has to be don eon AP only or I have to configure also clients?

Regards
Rosario

An interesting test, to say the least. The important part is that it *does* work - but we must keep in mind that 3.0 is still in a fairly early beta, and they will still be working on this for some time to come.

I hope that the development staff will get this working to a better degree, as it will become a more critical feature over time as the 2.4Ghz bands get more and more crowded.

Another nice thing would be to know that you are testing with 15-30 CPE on an AP to simulate real world usage. It doesn't do us WISP providers any good if it works fine with 1 or 2 stations, but poorly with 30+.