I’ve been thinking about some of the Nstreme P2MP issues, particularly regarding jitter and increased latency. My thinking goes that these problems may mostly do to the 3200 default packet size. As the radio has to wait and build the packets prior to sending them. Has any one tried using a 1400 packet size or even smaller? I realize this may reduce the overall through put but in most cases having a good M2MP protocol with lower jitter/latency, no hidden node issues and increase in client numbers would out weigh the increased through put gained by the increased packet size/packaging.
Unfortunately I am unable to test this out. So I am wondering if anyone has already thought of this and tried it or if not there is someone who has the ability to test it on their network.
I think I can do some testing on a node of our network… this is an issue that we have been fighting for some time. I’ll report back when I’m able to get some testing done.
I’m guessing that the framer police being none may still be using a 3200 packet size (mt can you comment) and there for using it with a smaller packet might still help. If under no policy the packets are sent as received then then there may be no benefit.
If Moto/trango etc and make a good quick polling solution I’m sure MT can do as good or better. May be it needs to be separated from Nstreme? Either way we have the hardware power (at least on a x86 side) to accomplish this it is just the software is lacking. We want to take it to the next level and we need strong solid polling and the associated jitter and latency improvement I know are there. With this there should be no reason an ap with 100 plus users can work fine and deliver several megs. Heck our 2mb Wave rider can deliver over a meg (on average) with 30 plus clients (average usage patterns).
I have running about 1500-2000 nstreme links and i think that everything is working fine.
I don’t think that there’s any problem with this.
Probably you have bad signal or problem with negiotioation rate.
If you’re expecting 1ms ping on multipoint solution, try VectaStar 3500 it cost 100 times more than MT (about 25k$ for one transmitter), but you’ll get these 1ms pings…
look these are pings from my PC to gateway which i get internet from:
C:\Documents and Settings\Marek>ping 192.168.3.254
Badanie 192.168.3.254 z użyciem 32 bajtów danych:
Odpowiedź z 192.168.3.254: bajtów=32 czas=5ms TTL=62
Odpowiedź z 192.168.3.254: bajtów=32 czas=4ms TTL=62
Odpowiedź z 192.168.3.254: bajtów=32 czas=5ms TTL=62
Odpowiedź z 192.168.3.254: bajtów=32 czas=4ms TTL=62
Of course it’s with nstreme with polling, the link is from Rb 532 to Rb 133C, on higher load (about 10Megabits) these are going up to 20ms
Link is on 5-6km distance with NLOS (…long story…)
I have many links working with nstreme around -76dBm @ 24Mbps data rate, where noise is rahter high, ant everything is working fine.
The secret is to set up solid data rate, one or two values below normal negotioation speed, and everything is working perfect
Of course the mPCI is important too, i’m using almost all the time one model of mPCI which i’ve chosen as best with MT and never had problems with nstreme.
How many clients do you have on the ap and what kind of data rates are being provided. We are planing a full mt network with mostly 133c for clients and 532 or even Pentium based aps.
I hope to use polling Nstreme on our networks to avoid the hidden node issues, but the feed back seems to be you can not get any more clients on the the ap with the polling and your latency and jitter is worse is, so there didn’t seem to be a good reason to bother.
Are you using R52’s only and how many others are connected to the AP you are associated to? Main problem with NStreme/Jitter seems to be when there are +30 associations and that’s with the rate set with 2 options. CCQ on all links shows 70-100.
It seem pretty much everyone can agree that the issue is mostly when you get 30 or more customers. The question is then, is this a CPU power problem? we all know Nstreme take a lot of power. What does the 532 run at with 30 or so Nstreme customers? Any one running it on a 1ghz+ PC platform? … if the results are the same then my guess would be that the timing window for the polls needs to be adjusted. Wave Rider had an algarithim in their poling that would reduce the the poles to stations that were not transmitting much traffic. The poll interval would go up to a few seconds if the cpe was in active. This works well as the busy cpe’s then get more polls.
Hey MT, does the poling on Nstreme have such a function or is it simply equal time per customer?
I cannot comment on P-T-MP, but on P-T-P link the cpu definitely matters (for both throughtput and latency).
On an RB 532 the best i could get (TCP, real world, single nstream, single antenna, single radio, 20Mhz channel) has been a 20/25 mbit HDX, with high latency (over 30/40 once passing 10Mbps, over 100ms when passing 20Mbps).
With a hi-performance cpu with the same setup it is possible to get to get around 40Mbit HDX, with little latency increase (under 10ms) and no jitter (if you can reach 100% ccq and rate fixed at 54Mbps).
My guess is the problem is a mix of both (i.e. you do need a fast cpu for nstream, but probably in P-T-MP benefits are much lower than in P-M-P, if not worse).
BTW i never got any nice performance in nstream P-T-MP (while i do have several sectors working nicely with 50 users and more, plain 802.11a)
Bye,
Ricky
There is no doubting NStreme on PTP links. We have several 7-8km links with RB532’s and single R52’s hard set to 48mbps with 20MHz channels and no compression and we get ~32mbps HDX. The debate has always been about PTM which is what polling is supposed to assist with. When we hear that someone with a +1GHz X86 AP running NStreme is having difficulties connecting more than 30 clients but someone else with an RB532 as AP without NStreme has +50 clients associated with no problems it does make you wounder why!
