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.
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.
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).
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…
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?
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%.
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!
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.
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).
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?
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.
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.
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!
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.
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.
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…
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.
RB532 / RB532
Yes
Dynamic
Routing with ospf
SR5 / SR5
2 which is why my pings are not that bad just yet.
