In next Beta you will be able to turn on/off the wireless carrier detection (CSMA), which will apparently solve the subj. problem that was much discussed earlier. This will be ONLY for NSTREME and of course, test at your own risk.
Good Jobs, and My thanks 
By the way, which side that csma/ca could be turn off, ?
AP-Side or Client Side or both ?
Plz respond…
Thank’s in Advance…
High Regards,
Andrei
Sounds good - I have my first suspected canopy-type invasion on a large mesh network which suddenly died…
I tried changing channels, and all was ok for about 15min until the offender changed channels too!
Not detected on ‘scan’ but regular 15-30kbps traffic on 2 freqs detected with ‘snoop’, with at least one on immediate neighbour channel.
Result: stone dead section of the network, with the occasional ping getting through…
Please work on it!
Thank You!
edit Did you use my sugestion and name it NStreamX?
if CSMA/CA is disable, what kind of modulation it use to solve the issue of idden node?
is this feature possible to insert for non Nstreme protocol?
Thanks a lot
There is no hidden node problem in polling-based protocols. Only one station is allowed to talk at one given time, by being polled for pending data. CSMA-CA is totally redundant in such case and should’ve been disabled in the first place already, as only rogue stations will talk unasked, and lending them a hand is only asking for local abusers to take advantage of this. Too bad it will be available in MT3, but better late than never!
So where are we in 2007 with RC5?
Its on the ntreame page.
Can we get this as an option without NStreme?
no, without nstream polling, csma is absolutly required in order for the wireless link to function… the reason for removing csma was because polling removed the necessity for that protocol to exist. When running 2 different contention meathods (polling and csma both qualify independantly as contention protocols) you end up wasteing airtime not transmitting, even if you would otherwise usually get a good signal across.
disableing csma increases the number of errors over the wireless link because it transmits even if there is an interferring signal present, but due to the significantly higher number of transmissions (that csma would have otherwise held back from) your throughput increases and latency decreases (in theory, in practice latency improvments are not noticable), despite raising the error rates. I have done testing showing increases of 200-300k across a 2.4 link in a very noisy enviroment simply by disableing csma, also the connection is more stable with less bursting of speed.
OK, we did some testing this afternoon in a very hostile RF environment.
There is a huge difference between 2.9.46 and 3.0RC6 when it comes to driving a Ubiquiti SR9.
5MHz channels, 270’ on the tower, Trango (ours) on the tower, lots of Trango (ours) and Canopy (theirs) close by.
Used a pair of grids facing each other with a 133 as the AP and a 133c at the client. Links fluctuating a bit around -78 through a fair bunch of trees. Only a 3km shot, but a lousy path, lots of trees, very little ground clearance as there is a hill partially obstructing the fresnel. Definitely NOT line of sight!
2.9.46 was pretty much a train wreck as you would normally expect with the crappy signal level. 200k-2Mbit with wild fluctuations and lots of pauses in the connection. Just about what we have come to know and love with this combination in this environment. You could sell it if you had a really understanding customer with no other choices, but only if they guaranteed you they would never try to use voip over the connection.
On the other hand, 3.0RC6 was a steady 3.3-3.7Mbits in both directions. Fastest I have ever seen a 5MHz channel run at 900, and just about rock steady. Ping times were very stable even running on top of a bandwidth test. And those numbers were testing directly between the AP/Client MTs, not through them as best practices dictate.
We did quite a bit of evaluation, swapping back and forth between firmware versions and trying different combinations of firmware and combinations of settings.
The really big improvement was having 3.0RC6 as the access point. Probably 80-90% of the total improvement was seen just by doing that.
Adding in 3.0RC6 as the client added a few percentage points, as did turning on CSMA-disable and Adaptive Noise Immunity. But the big difference was changing the AP firmware.
WOW!!!
Obviously this is early days and these are very preliminary results, but I have renewed hope in the eternal struggle against the evil demons of Canopy. 
George
Can you give us a look at the config for either endpoint you applied? I have a couple of similar 5ghz links that I’m working on which would benifit from this.
Regards,
Omega
George,
Is it safe to assume you are using nstream? If not, from what I have read earlier in this same post, using the csma disable would not really be active because it is only usable with nstream… Is this the case or does the csma disable actually work without nstream?
Thanks for the clarification…
Scott
Using Nstreme Scott.
I am not generally an Nstreme fan because of eneven latency, but it seems a lot better now. These are preliminary results though so its too soon to tell for sure.
Looks like we do have a memory leak though.
George
/interface wireless
set 0 ack-timeout=dynamic adaptive-noise-immunity=yes allow-sharedkey=no \
antenna-gain=0 antenna-mode=ant-a area="" arp=enabled band=2ghz-5mhz \
basic-rates-a/g=6Mbps basic-rates-b=1Mbps burst-time=disabled comment="" \
compression=no country=no_country_set default-ap-tx-limit=0 \
default-authentication=yes default-client-tx-limit=0 \
default-forwarding=yes dfs-mode=none disable-running-check=no disabled=no \
disconnect-timeout=3s frame-lifetime=0 frequency=907 \
frequency-mode=regulatory-domain hide-ssid=no hw-retries=15 \
mac-address=00:15:6D:93:25:39 max-station-count=2007 mode=ap-bridge \
mtu=1500 name="wlan900" noise-floor-threshold=default \
on-fail-retry-time=100ms periodic-calibration=default \
periodic-calibration-interval=60 preamble-mode=both \
proprietary-extensions=post-2.9.25 radio-name="xxxxxxxxxxx\
Lake Test" rate-set=configured scan-list=default security-profile=default \
ssid="LLBL" station-bridge-clone-mac=00:00:00:00:00:00 \
supported-rates-a/g=6Mbps,9Mbps,12Mbps,18Mbps,24Mbps \
supported-rates-b=1Mbps,2Mbps,5.5Mbps,11Mbps tx-power-mode=default \
update-stats-interval=disabled wds-cost-range=50-150 \
wds-default-bridge=none wds-default-cost=100 wds-ignore-ssid=no \
wds-mode=disabled wmm-support=disabled
/interface wireless
set 0 ack-timeout=dynamic adaptive-noise-immunity=yes allow-sharedkey=no \
antenna-gain=0 antenna-mode=ant-a area="" arp=enabled band=2ghz-5mhz \
basic-rates-a/g=6Mbps basic-rates-b=1Mbps burst-time=disabled comment="" \
compression=no country=no_country_set default-ap-tx-limit=0 \
default-authentication=yes default-client-tx-limit=0 \
default-forwarding=yes dfs-mode=none disable-running-check=no disabled=no \
disconnect-timeout=3s frame-lifetime=0 frequency=917 \
frequency-mode=manual-txpower hide-ssid=no hw-retries=15 \
mac-address=00:15:6D:93:25:4C max-station-count=2007 mode=station mtu=1500 \
name="wlan900" noise-floor-threshold=default on-fail-retry-time=100ms \
periodic-calibration=default periodic-calibration-interval=60 \
preamble-mode=both proprietary-extensions=post-2.9.25 radio-name="xxxxxxxxxxxxxxxx" rate-set=configured scan-list=default \
security-profile=default ssid="LLBL" \
station-bridge-clone-mac=00:00:00:00:00:00 \
supported-rates-a/g=6Mbps,9Mbps,12Mbps,18Mbps,24Mbps \
supported-rates-b=1Mbps,2Mbps,5.5Mbps,11Mbps tx-power-mode=default \
update-stats-interval=disabled wds-cost-range=50-150 \
wds-default-bridge=none wds-default-cost=100 wds-ignore-ssid=no \
wds-mode=disabled wmm-support=disabled
George
I use SR9’s and Canopy. I have never seen the interference issues between them you describe. I believe you are having problems with FHSS gear such as Alvarion from what you are describing.
I believe you are having problems with FHSS gear such as Alvarion from what you are describing.
That’s pretty a pretty funny comment. “I believe” too, but this isn’t a faith-based technology.
I have the ESN, colour codes etc for all 11 of the Canopy access points that cause us trouble.
There are no Alvarion hoppers within 80 miles.
Have a nice day.
George
George,
No need to flame my post. I was directing it at GWISA not you.
If you have 11 Canopy 900 AP’s near by good luck. You’d have been better off switching to Canopy yourself and syncing with your competition than working against them.
In the wireless world Canopy always wins.
Quoting an earlier post in the thread removes the opportunity for confusion.
I’m not nearly that defeatist. Canopy is far from perfect and isn’t fond of noise right on top of an AP either. I also don’t believe in rewarding government-subsidized incompetence.
By the looks of it so far, with 3.0 we have an interesting new “opportunity”. I want to see how it works with the XR-9s and GZ-901s too!
George
I just upgraded one of my SR9 AP’s and the CPE on my home link today. I’m impressed. With 2.9.46 on an Internet speedtest I was seeing around 500k-600k down and 100k up. 2.5 miles nothing of trees.
My most recent test is at 1.8megs down and 400k up and running stable.
That is with 5mhz channel and -82 signal