Community discussions

MikroTik App
 
User avatar
nickb
Member
Member
Topic Author
Posts: 407
Joined: Thu Jan 26, 2006 6:24 pm
Location: Southeast Kansas
Contact:

Nstream & Maximum clients per AP

Fri Dec 01, 2006 5:52 am

Reading over the manual, it seems that my initial impresions about nstream are correct, but I have not actually put it to use in any sort of point-to-multipoint configuration.

I am looking at the possibility of developing a network that would need to have *lots* of clients on each AP interface, and I hope that using nstream with polling (possibly without framer) to enhance the number of clients that can be serviced on a particular radio.

If I understand how nstream works, what happens is that instead of fighting for radio time, the AP will coordinate the clients.

So using nstream polling, how many clients could be serviced with reasonable reliability with ~1mbps queues? By that I mean, the clients would log in with PPPoE and be assigned a simple queue limiting them to something like 500kbps to 1500kbps depending on service class.

In our current deployments, we don't use any sort of polling or control and typically see an upper limit of about 40 clients per radio before it seems like people are fighting for radio time. I hope to double or triple that with nstream+polling, given that we don't intend to provide >2mbps service levels.

So, is this sane? Is it even remotely possible than an RB564 could handle the task, or would a PC based unit be absolutely required? Unfortunately, I do not have the resources to test this out. My hope is that someone out there has this sort of configuration, and could provide some kind of real world experiance for how many clients can be serviced off of a cell using this design.
 
User avatar
sergejs
MikroTik Support
MikroTik Support
Posts: 6624
Joined: Thu Mar 31, 2005 3:33 pm
Location: Riga, Latvia
Contact:

Fri Dec 01, 2006 1:24 pm

Note, that using Nstreme requires MikroTik RouterOS on both end, if client does not support Nstreme, user will not connect.
 
User avatar
nickb
Member
Member
Topic Author
Posts: 407
Joined: Thu Jan 26, 2006 6:24 pm
Location: Southeast Kansas
Contact:

Sun Dec 03, 2006 12:58 am

Yes, I'm well aware of that. My intent is to use RB112 based CPE with R52 radios. :)
 
User avatar
nickb
Member
Member
Topic Author
Posts: 407
Joined: Thu Jan 26, 2006 6:24 pm
Location: Southeast Kansas
Contact:

Sun Dec 03, 2006 10:46 pm

I presume from the silence that no one uses nstream in this manner?

How then, could one test this without spending buckets of money?
 
ejansson
Member
Member
Posts: 301
Joined: Fri Oct 21, 2005 4:09 pm
Location: Manitoba, Canada

Mon Dec 04, 2006 1:12 am

We hope to do the same thing too but I have not gotten many responses to some of my questions either regarding Nstreme M2MP in terms of clients. What I have figured out is a p4(m) based system will be required for the processing particular if you plan any kind of filtering or qos type activities as we do. I did find a post from some time ago (which I can't find now) where the guy said he was running 100+ clients on a Mini ITX P4M platform. But since I can not find the post any more I have been unable to track him down to find out what kind of service levels he is supplying and how well things have worked. We have done alot of digging and come up with a hardware platform up it is not up and running yet in the wild.

Erik
 
uldis
MikroTik Support
MikroTik Support
Posts: 3439
Joined: Mon May 31, 2004 2:55 pm

Mon Dec 04, 2006 2:59 pm

There is not big difference between the AP with few clients and AP with more clients. All that matters is how many mbps (pps) it can pass through.
In your case if you want to limit the speeds for the wireless clients I recommend you to use Wireless trasmit/receive limits that are configurable in the Access list of the AP, because then the clients will not flood up the network with lot of traffic which then will be dropped on the AP by the simple queues. In case of the Wireless transmit/receive limit the client will not send faster than the AP told him to (this saves you air time compared to the regular simple queues that are on the AP).
 
galaxynet
Long time Member
Long time Member
Posts: 648
Joined: Fri Dec 17, 2004 2:52 pm
Contact:

Mon Dec 04, 2006 3:49 pm

I'd have to agree w/uldis on this one. I use Nstreme w/multiple clients but I also go one step further and use queuing on the client only end. So what I have is tx/rx limiting at the AP in the Wireless Access list and on the client MT I use the simple queue for limiting bandwidth.

I have found that the more data you want to push (vice the number of clients) the higher the processing power (CPU speed) you'll need. Up to about 20 - 25Mbps you can use a RB 5XX and have good results, above that you'll need something with more horsepower...

Thom
 
User avatar
nickb
Member
Member
Topic Author
Posts: 407
Joined: Thu Jan 26, 2006 6:24 pm
Location: Southeast Kansas
Contact:

Mon Dec 04, 2006 8:49 pm

I have found that the more data you want to push (vice the number of clients) the higher the processing power (CPU speed) you'll need. Up to about 20 - 25Mbps you can use a RB 5XX and have good results, above that you'll need something with more horsepower...
Very true, but I think the question I'm trying to solve is how much more CPU does an nstream client require, than a non nstream client?
 
galaxynet
Long time Member
Long time Member
Posts: 648
Joined: Fri Dec 17, 2004 2:52 pm
Contact:

Mon Dec 04, 2006 9:47 pm

Very true, but I think the question I'm trying to solve is how much more CPU does an nstream client require, than a non nstream client?
Not very much. One case I am using a 1.4Ghz CPU, it pushes an average 30Mbps and cpu usage is under 30%. Near max throughput (bursts of 50 - 60Mbps) the cpu goes to about 50%. From my experience it looks like once you get a CPU that goes above 1Ghz, cpu utilization levels off.

The above cpu does not have a lot of clients, but they do push a lot of data.... I do have another location that has a lot of clients but the average data throughput in under 5Mbps... CPU utilization is under 25%.

Hope that helps...

Thom
 
User avatar
nickb
Member
Member
Topic Author
Posts: 407
Joined: Thu Jan 26, 2006 6:24 pm
Location: Southeast Kansas
Contact:

Mon Dec 04, 2006 11:14 pm

The only time I've tried to use nstream in production, it was a point-to-point link, and I had the framer turned on. Each end was an RB532 and most of the time the CPU usage was 30-40% for a few hundred kilobits!

I think what this is coming down to is, to use nstream in PTMP, more CPU than an RB532 is required!
 
ejansson
Member
Member
Posts: 301
Joined: Fri Oct 21, 2005 4:09 pm
Location: Manitoba, Canada

Mon Dec 04, 2006 11:25 pm

How many is lots? Right now I'm planing a 1.4GHz or higher p4m, I hope to be able to service 100+ customers mostly res and telecomuters speed will vary from 1.5mb down to 3mb down (peak). Assuming average client usage and a bit of filtering and routing going on is this reasonable set up for Nstreme.... it seem from what you are indicating it should be.

Erik
 
User avatar
nickb
Member
Member
Topic Author
Posts: 407
Joined: Thu Jan 26, 2006 6:24 pm
Location: Southeast Kansas
Contact:

Mon Dec 04, 2006 11:33 pm

How many is lots? Right now I'm planing a 1.4GHz or higher p4m, I hope to be able to service 100+ customers mostly res and telecomuters speed will vary from 1.5mb down to 3mb down (peak). Assuming average client usage and a bit of filtering and routing going on is this reasonable set up for Nstreme.... it seem from what you are indicating it should be.
Yes, but I'm sure you are planning on using multiple sector antennas. I'm talking about per interface, not for the whole AP.

Sure, you might be able to service 100 customers on one AP at those traffic levels - but from what I can tell you're going to need to use 3 or 4 interfaces to do it (if not more).
 
ejansson
Member
Member
Posts: 301
Joined: Fri Oct 21, 2005 4:09 pm
Location: Manitoba, Canada

Tue Dec 05, 2006 5:28 am

As 802.11a/b/g is limited to about 40 clients in the best case. I was figuring that between using routing (estimate 10-15% over bridged 802) and nstreme to eliminate hidden node issues and increase bandwidth efficiency I was hoping to get 100 or so on a 90deg sector using 1 card on a p4 platform. From what I have put together from this forum this set up should yield the ability to service more clients as my bandwidth is higher and more efficient.
On Wave rider (2mb at the ethernet level) we could put on roughly 40 residential clients (allowing 2mb up or down), at peak times the bandwidth would get spread out over the clients and people would average about 1mb +- .

Am I not thinking about this right? WR has a algorithm designed to graceful degrade performance across a block or class of users. My under standing was that the bottle neck was in processor speed (particularly with Nstreme) not with the radio cards its self. If my through put on an MT is in the 10mb range(routed, nstreme polling) I am assuming that providing there is not CPU bottle neck that I should have no issues pushing 2mb+ out to 100 clients based on my WR experience and customer usage.... I would be guessing the over all experience should be much better.

I could be all wrong on this and may be the systems can not be compared in this way. I have found very few posts regarding people using nstreme polling and from my point of view I don't know why so few people seem to not use it. Could it be that many of the people on the forums are thinking a much smaller scale?
 
User avatar
nickb
Member
Member
Topic Author
Posts: 407
Joined: Thu Jan 26, 2006 6:24 pm
Location: Southeast Kansas
Contact:

Tue Dec 05, 2006 5:35 am

As 802.11a/b/g is limited to about 40 clients in the best case. I was figuring that between using routing (estimate 10-15% over bridged 802) and nstreme to eliminate hidden node issues and increase bandwidth efficiency I was hoping to get 100 or so on a 90deg sector using 1 card on a p4 platform.
I would love for that to be the case, but from what I've been able to tell a) nobody has tried it b) nobody seems to think it will work.

I do feel that routing works better than bridging (WDS) to a significant degree. And yes, nstream would eliminate the hidden station issues, but I still feel like 100 per radio may be asking a little much. I was hoping that 50 or 60 might be doable, but from what everyone says in every thread I've read on here, 30-40 is generally maximum. Even then, you're relying on those users not using much pps, the first time one of them fires up bittorrent the quality of service is going to go to hell in a handbasket!
could be all wrong on this and may be the systems can not be compared in this way. I have found very few posts regarding people using nstreme polling and from my point of view I don't know why so few people seem to not use it. Could it be that many of the people on the forums are thinking a much smaller scale?
I don't really know, it seems like such a great technology! I would love to just trial it, but that would cost tens of thousands of dollars, as none of our exising CPE supports nstream :(

I think many networks have to rule out nstream immidiately because they have legacy CPE that does not run MT.
 
ejansson
Member
Member
Posts: 301
Joined: Fri Oct 21, 2005 4:09 pm
Location: Manitoba, Canada

Tue Dec 05, 2006 5:54 am

Could be the reason. I've only been working with MT for a year and it has always had Nstreme. Not sure how long ago it came out but I guess thinking about it legacy 2.4b/g would hold you back from moving to nstreme.

I didn't think I was quite that much of a trend setter, but maybe I am. If we complete our funding drive. we will be building in the spring combining 900mhz and some 5ghz distribution with some 2.4ghz hotspot stuff.

I'll also be trying a 2.4/5.8 frequency diversity link on a 30km shot over rocks forest and lakes, that have huge fade issues. But at any given time one of the 2 frequencies should work. I'll have to play around and test what the best failover mechanism is, bonding, stp, routing, or maybe some sort of scripting.
 
User avatar
nickb
Member
Member
Topic Author
Posts: 407
Joined: Thu Jan 26, 2006 6:24 pm
Location: Southeast Kansas
Contact:

Tue Dec 05, 2006 7:52 pm

Could be the reason. I've only been working with MT for a year and it has always had Nstreme. Not sure how long ago it came out but I guess thinking about it legacy 2.4b/g would hold you back from moving to nstreme.
Legacy 802.11b is currently the case with our company, but I am researching going a different route - hence this post.

Unfortunatly the limits of 802.11b/g (I don't think that this is an MT issue, but rather an issue with the spec, and the hardware itself), are prohibitive to costs. By only being able to support 30-40 clients per sector, we run in to problems with density and cost effectiveness.
I'll also be trying a 2.4/5.8 frequency diversity link on a 30km shot over rocks forest and lakes, that have huge fade issues. But at any given time one of the 2 frequencies should work. I'll have to play around and test what the best failover mechanism is, bonding, stp, routing, or maybe some sort of scripting.
That sounds interesting, when you try it, please post details!
 
miahac
Long time Member
Long time Member
Posts: 515
Joined: Wed Dec 14, 2005 5:04 pm
Location: Wichita, KS

Fri Dec 15, 2006 9:45 pm

Nick. Unfortunatly, use more radios/frequencies on your tower or use more towers. If you have some grain elevators, you can put up 8 AP's on 2.4 if you mount below the top and use alternating polarization.
 
jober
Long time Member
Long time Member
Posts: 692
Joined: Fri May 28, 2004 12:16 pm
Location: Louisiana,USA

Fri Dec 15, 2006 11:38 pm

I think most people use MT for their APs and then CB3s or some other cheep CPEs.
My New Orleans network is all MT. I use Rb532s with SR5s for the Station and SR2s for AP repeater(Small POPs). On the APs I only use PC hardware such as the VIA533Mhz boards. Also I have to use dishes for the MtMP systems because theres just to much noise in the area.
I have started using nstreme on one AP and so far it's working fine. Theres not a lot of customers on that AP but I'm sure there will be soon.
After I get the other APs running Nstreme with polling I let you know how it runs.
I also have a network in Covington that runs with all RB532s, AP and CPE. I have AP of those APs running nstreme with polling too. Only 3 people on that one.
I did see faster speeds with nstreme.
 
BurstNET

Sat Dec 16, 2006 4:14 am

We are seeing about a 25% thoughtput improvement in running Nstreme rather that without. However, the latency is just sporadic. Without Nstreme we can have 0-2 ms ping times, and then with Nstreme i is like 3-4ms then 19ms, then 6 ms, then 3ms, then 26ms, etc....totally spasdic...

I don't mind it being a few ms higher to use Nstreme, it's worth the tradeoff for the extra thoughtput, but the sporadic latency up to 20-30ms higher is quite annoying. I'm not sure what effect it will have on VOIP yet...

SMA
 
jober
Long time Member
Long time Member
Posts: 692
Joined: Fri May 28, 2004 12:16 pm
Location: Louisiana,USA

Sat Dec 16, 2006 7:13 am

Time to compair setups. Maybe there's something that we can find that works best.

1.What are you using for CPEs and APs?
2.Are you using polling?
3.What is the framer policy?
4.Are you routing or bridging?
5.Radios CPE/AP?
6.How many client connected?
7.ping times, min. / avg. / max


Answers for my Covington Network.
1. RB532 / RB532
2. Yes
3. Dynamic
4. Routing with ospf
5. SR5 / SR5
6. 2 which is why my pings are not that bad just yet.
7. 4 / 5 / 17 pinged for 5 minutes
 
BurstNET

Sun Dec 17, 2006 6:09 pm

1. RB112 + SR2 or SR5 (10mhz)
2. Yes
3. Best-Fit 3200 (Tried others, this seemed best w/most thoughtput)
4. Fully Routed
5. RB112 + SR2 or SR5 (10mhz)
6. 2-3 for testing purposes
7. SR5 5GHZ: 0/2/8 w/o Nstreme & 3/8/36 --------- SR2 2.4GHZ: 3/6/12 w/o Nstreme & 4/16/64


SMA
 
ejansson
Member
Member
Posts: 301
Joined: Fri Oct 21, 2005 4:09 pm
Location: Manitoba, Canada

Sun Dec 17, 2006 9:25 pm

Our plan is (partly bench tested)

1) CPE RB112(SR9, SR5, maybe RB52's) AP Tested with RB532, field ITX with 2GHz P4M.

4) Net work will be routed, 1 or 2 sub nets per AP(1 interface) with filtering rules at cpe and AP.

Most customers will be getting 1.5mbps/256k down/up with a smaller number getting 3mb up and down and a couple of larger accounts. 5ghz will be used for LOS and 900 for NLOS customers. These are peak numbers no CIR or min speeds guaranteed

May be MT can comment. Unless there is a bottle neck in the radio cards or a software issue, taking away the CPU bottle neck and the other 802 issues should produce much better results. Anyone heard of MT's Nstreme upgrades for Version 3?
 
User avatar
tjohnson
Member Candidate
Member Candidate
Posts: 127
Joined: Thu Aug 12, 2004 7:01 am

Re: Nstream & Maximum clients per AP

Fri Feb 29, 2008 6:53 am

I have been running ROS for almost 5 years now... started with point to point links for our backhaul links and just recently (two weeks ago) have started installing point to multipoint for our subscribers. We are running RB532 for the AP with SR5 cards, running v3.x of ROS. We are using Nstreme (with no framer), polling and disable CSMA. I currently have an AP with two live clients, so just last night I tested different settings.

Turning off Nstreme made it when testing both clients at the same time, their speeds would change from one getting 1Mbps and the other getting 8Mbps to whatever. Turning on Nstreme fixed this problem.

Turning off polling had a similar effect.

I got about 1Mbps better performance with "disable CSMA" turned on (along with Nstreme and polling).

The routerboards CPU readings are very misleading. Even a board doing nothing will show 30-40% usage... yet I have an RB532 in a point to point link that does 15Mbps of bandwidth and CPU is only at 80%.

I would use the RB333 for the AP (same price as RB532, but 100% more horsepower). You should be able to get 100 users on that hardware if you use Nstreme and polling.
Travis
 
CarulloS
Member
Member
Posts: 406
Joined: Thu Feb 02, 2006 5:52 am

Re: Nstream & Maximum clients per AP

Sat Mar 01, 2008 6:10 am

Travis, have you had or heard of anyone having heat problems with RB333. John V mentioned it to me in our last conversation. I have been unable to verify this with anyone.

Scott
 
User avatar
tjohnson
Member Candidate
Member Candidate
Posts: 127
Joined: Thu Aug 12, 2004 7:01 am

Re: Nstream & Maximum clients per AP

Sat Mar 15, 2008 4:33 am

I'm in Idaho... it's just barely breaking 40F during the warmest days right now... so heat isn't an issue for us yet... wait until July/August when we usually break 100F (hit 110F last year).

Travis
Travis
 
npbrasil
Frequent Visitor
Frequent Visitor
Posts: 83
Joined: Wed Jun 02, 2004 8:50 am

Re: Nstream & Maximum clients per AP

Sat Mar 15, 2008 5:13 am

110F? Sure? Oh my God, Al Gore is right!! I'm in the hottest region from Brazil and here the maximum was 95F in the last year and i thought that here was hot. An inconvenient truth... is the end of the world... About the RB333, i don't have any problem and don't use any active cooler in the box.
 
User avatar
tjohnson
Member Candidate
Member Candidate
Posts: 127
Joined: Thu Aug 12, 2004 7:01 am

Re: Nstream & Maximum clients per AP

Sat Mar 15, 2008 6:27 am

Yes, we are probably in one of the most extreme temperature regions on the planet. We saw -35F this winter (without the wind chill) and last summer we hit 110F.

Nothing like getting to deal with problems year round... from snow/ice on towers with 50mph winds to 110F and equipment failing (along with the power grid). :(

Travis
Travis
 
User avatar
tgrand
Long time Member
Long time Member
Posts: 671
Joined: Mon Aug 21, 2006 2:57 am
Location: Winnipeg, Manitoba, Canada

Re: Nstream & Maximum clients per AP

Sat Mar 15, 2008 4:15 pm

nstreme from my experience has minimal processor requirements over standard wireless.
If anything, it improves overall performance because radios are not broadcasting simultaneously, requiring rebroadcasts.

tjohnson, sounds like you come from a place not unlike, where ejansson and myself come from.
Sunny Manitoba, Canada.
Sunny Yes... That amounts to very cold winters, and hot summers.
 
hytanium
Member Candidate
Member Candidate
Posts: 201
Joined: Thu Jan 18, 2007 9:10 pm

Re: Nstream & Maximum clients per AP

Sat Apr 12, 2008 6:47 pm

I find that about 30 clients per radio is pretty much the max. So for the RB333 around 90 customers is realistic. I curently have an AP with 2 sr5 and one sr9. Sr9 has 33 clients on SR5 has 24 clients and Other has about 10. SR5's have Nstreme and polling enabled, sr9 has no nstreme.

I find that you can't disable and reenable the wireless interfaces at once... it will cause the RB to become unstable. I disable all clients and interfaces, enable just the interfaces and bring clients up in groups. Anyone else see this on a loaded AP?
 
User avatar
nickb
Member
Member
Topic Author
Posts: 407
Joined: Thu Jan 26, 2006 6:24 pm
Location: Southeast Kansas
Contact:

Re: Nstream & Maximum clients per AP

Tue Jan 25, 2011 1:23 am

So it's been almost five years since I originally posted this thread, so I thought it appropriate to follow up with some observations.

In several scenarios, I've deployed SR2/XR2 transceivers with horizontally polarized antennas, using RB433 or RB600/800 boards for the AP, and RB411+R52H for clients.

RF settings are 10Mhz channel, ANI on, Long Preamble, and HW-Retries = 4

I have found good results as long as the client signal is better than -80dBm - less than that and it doesn't seem to work very well, even with 12-14dB SNR. Noise floor is usually around -98 to -102, and though 802.11 activity is very heavy, non-802.11 interference is uncommon.

So far, I've gotten as many as 50 clients on a 10MHz channel using nstreme with good results. Quality of service is reasonable, and nobody is complaining. With good signal, btest results as high as 8 to 9Mbps can be seen. We limit clients to 1Mbps or 2Mbps depending on what they pay for.

As RF resources have become more and more scarce (in terms of co-channel interference from other 802.11 systems), I've found that going to a 10Mhz channel really helps a lot - allowing you to "slot in" to an empty space in the band a little better. You've also got a better chance for CSMA to be clear, even with overlapping transmitters, due to the smaller channel bandwidth.

One thing has been clear though - disabling CSMA has NEVER helped in any way. My observations have lead me to the conclusion that disabling CSMA will only be effective/useful in environments with little to no co-channel 802.11 interference.

Who is online

Users browsing this forum: DSK and 21 guests