Hi Normis,ste, did you read above success stories?
yes, MikroTik does have outdor Nstreme setups. Even our internet uplink for the office is running over Nstreme wireless link, so if there would be issues, everyone here would notice
It does not tell me:the two above setups with 40 clients are not good enough examples ?
/interface wireless nstreme> pr
0 name="wlan1" enable-nstreme=yes enable-polling=yes disable-csma=no
framer-policy=dynamic-size framer-limit=2000
With wireless-test, nstreme isolates the bad client with high signals.. (our clients disconnect @ -84). That protects the other "good" clients.It does not tell me:
- what happens when I've clients with a -88 signal in between
- what happens when 3 unlimited users are torrenting
So it does not tell me if nstreme ptmp would work for me.
Stefan
Why is your 133c doing NAT?Our clients have mostly RB411s, there's some 133c out there still, but we are replacing them since they arent working good with crowded radios. They work fine until the user starts downloading from emule/torrent. The 133c wont handle both Natting and polling with small packets.. The ROS Version vary from 3.2 to 3.30. Only few of them have wireless-test package enabled.
We've difficulties to bring all of our clients to good signals. As we respect ETSI regulations this is difficult to do in all cases. There are a lot of customers accepting low bandwidth in Regions where they get max 64kbps otherwise.Our clients have mostly RB411s, there's some 133c out there still, but we are replacing them since they arent working good with crowded radios. They work fine until the user starts downloading from emule/torrent. The 133c wont handle both Natting and polling with small packets.. The ROS Version vary from 3.2 to 3.30. Only few of them have wireless-test package enabled.This is my nstreme configuration. The framer-limit is quite useless since i noticed the frame is always 1532 (pppoe encapsulation).. With exact-size you might be able to get more throughput but the latency might be higher.Code: Select all/interface wireless nstreme> pr 0 name="wlan1" enable-nstreme=yes enable-polling=yes disable-csma=no framer-policy=dynamic-size framer-limit=2000
With wireless-test, nstreme isolates the bad client with high signals.. (our clients disconnect @ -84). That protects the other "good" clients.It does not tell me:
- what happens when I've clients with a -88 signal in between
- what happens when 3 unlimited users are torrenting
So it does not tell me if nstreme ptmp would work for me.
Stefan
We havent unlimited users, and we shape peer-to-peer traffic to keep the quality of the links fair enough.
This of course turns out to be bound to mikrotik, and we cannot buy for example any ubiquiti clients. But until now we are fine with Mikrotik, even if sometimes the new releases are fucked up
This depends on the implementation of polling, traffic pattern and signal strengths.We have not directly compared our set up to using RTS/CTS but a polling system should out perform it. While RTS/CTS helps a lot compared to a system that does not use it. It is still a "collision" based and would work best with smaller more compact (area wise) configuration.
I agree, I too would like to see GPS derived client management. If there is any way that I can assist with this, I would like to volunteer.One thing we would like to see and is on the top of the MT wish list (wiki) is gps syncing. While it is not a fix all it seems to be on the surface it would help a lot at densely packed sites and keep cost down as few filters would be needed, in wide open areas where were an omni can be seen from another tower more then 50km away.........HINT...HINT...NORMIS!
I think you've made good decision. We test and use wireless-test package on one site with 10-15 clients per sector. But: 133c rb's are slow for polling and nstreme. Clients must have good signals, if they don't, cpe's are disconnecting. You have to use RB433AH or better hw on AP. Latency is not so good for me. It is from 5-50ms.Seems Nstreme needs all participants to have a fast cpu and the benefit
seems not as big as expected. As I've never seen any statement from MT
regarding a running example I'm wondering MT even has a outdoor test
setup for there developer(s). And without I dont believe they can implement it
efficient.
We've decided to implement RTS/CTS instead as:
- we've still a lot of RB133c out there
- it's interoperabel with other equipment and 802.11n
- you've to implement nstreme it on the whole segment in one sweep as MT has no Nstreme autodetection
Why would you ever disable CSMA in PtMP environment? A backhaul with a clear channel and good SNR might benefit from disabling CSMA, but in any other condition it would seem to be counterproductive, and exacerbate problems, especially with APs that have clients with significantly different signal strengths.In most cases we use the default packet size of 3200 with best fit, with CSMA disabled(box checked). Hardware retries are set to 6. Adaptive Noise Immunity is turned on. We find we have to do some fine tuning on some sites to do to local conditions. If the AP has issues (many client disconnects) we will increase the Hrdwr retries to 8 and drop the the max packet size to 1500, this helps in preventing corruption of larger packets.. you also loose a bit of through put. CSMA in early 3.x seem to make things worse particularly if the RF was not great.
We too would love to see some more development with GPS sync for stability!! ( Hint Hint )Ah, yes. If GPS sync was implemented across the board as suggested (like many other types of carrier grade eqpt), it would go a long way for stability. This would be especially true for cell-sites that have many radios transmitting in the same band, e.g. 12 APs and 6 backhauls in the same band on the same roof--takes a big roof of course...
Thats my story, and Im stickin to it.