Community discussions

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

Nstreme Packet size vs Jitter/Latency

Wed Apr 04, 2007 4:28 pm

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.

Erik
 
User avatar
BrianHiggins
Long time Member
Long time Member
Posts: 598
Joined: Mon Jan 16, 2006 6:07 am
Location: Norwalk, CT
Contact:

Wed Apr 04, 2007 6:01 pm

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.
 
believewireless
Member Candidate
Member Candidate
Posts: 231
Joined: Wed Jul 06, 2005 6:30 pm

Wed Apr 04, 2007 6:16 pm

We set the framer policy to none and it didn't help.
 
ejansson
Member
Member
Topic Author
Posts: 301
Joined: Fri Oct 21, 2005 4:09 pm
Location: Manitoba, Canada

Wed Apr 04, 2007 7:21 pm

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).


Erik
 
User avatar
warwick09
Member Candidate
Member Candidate
Posts: 190
Joined: Mon Aug 07, 2006 1:34 pm
Location: The Bahamas / Florida

Wed Apr 04, 2007 11:28 pm

Regarding the aforementioned post... it would be great if the polling system cound be utilized without "aid/use" of the nstreme function/protocol.


Guess we will have to waif for such a feature, but ah well ... software is still great.
[/quote]
 
ejansson
Member
Member
Topic Author
Posts: 301
Joined: Fri Oct 21, 2005 4:09 pm
Location: Manitoba, Canada

Thu Apr 05, 2007 12:04 am

That is exactly what I was getting at. Nstreme or not a good polling algorithm is desperately needed. Hey Normis any input?


Erik
 
User avatar
warwick09
Member Candidate
Member Candidate
Posts: 190
Joined: Mon Aug 07, 2006 1:34 pm
Location: The Bahamas / Florida

Sat Apr 07, 2007 8:26 pm

---- Buzz! ---- any info Normis ?


.... Would be appreciated. 8)
 
User avatar
warwick09
Member Candidate
Member Candidate
Posts: 190
Joined: Mon Aug 07, 2006 1:34 pm
Location: The Bahamas / Florida

Thu Apr 12, 2007 10:08 am

..Guess this feature would have to be voted for.


Plz Vote!!!!!!!!!!!!!!!!!!!!!! Polling without nstream would be great/excellent.


( not to blemish nstream tho 8)
 
BurstNET

Thu Apr 12, 2007 3:18 pm

Fixing Nstreme really should be the #1 priority for nearly everyone.

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

Thu Apr 12, 2007 9:11 pm

I didn't see it in the Wiki list so I added it. Please vote and then email to 10 friends !! :wink:

Erik
 
User avatar
marksx
Member Candidate
Member Candidate
Posts: 109
Joined: Sat Jun 26, 2004 9:56 pm
Location: POLAND

Thu Apr 12, 2007 10:51 pm

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...)
Polling without nstream would be great/excellent.
I don't think so
Mikrotik Certifird Teacher - High Performance Wireless Networks Administrator
Contact: marek (at) prowireless.pl
 
User avatar
Equis
Forum Veteran
Forum Veteran
Posts: 888
Joined: Mon Jun 06, 2005 6:48 am

Fri Apr 13, 2007 1:42 am

I found Nstream works great if..

You have a very low noise enviroment
You have a -65 or better

It disconnects way more than a non nstreame link.

I have it on a coupel of my links becuase its faster and better under load, however the fact it is not as solid is a problem for me.

I voted in the wiki for it to have R&D time...
 
User avatar
marksx
Member Candidate
Member Candidate
Posts: 109
Joined: Sat Jun 26, 2004 9:56 pm
Location: POLAND

Fri Apr 13, 2007 2:44 am

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.
Mikrotik Certifird Teacher - High Performance Wireless Networks Administrator
Contact: marek (at) prowireless.pl
 
ejansson
Member
Member
Topic Author
Posts: 301
Joined: Fri Oct 21, 2005 4:09 pm
Location: Manitoba, Canada

Fri Apr 13, 2007 4:26 am

Marksx

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.


Erik
 
User avatar
Equis
Forum Veteran
Forum Veteran
Posts: 888
Joined: Mon Jun 06, 2005 6:48 am

Fri Apr 13, 2007 5:58 am

Hello marksx

What is Model of your miniPCI?

Thanks
 
phendry
Member Candidate
Member Candidate
Posts: 258
Joined: Fri May 28, 2004 4:42 pm

Tue May 01, 2007 2:18 pm

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...)
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.

Did anyone try with smaller packets?
 
ejansson
Member
Member
Topic Author
Posts: 301
Joined: Fri Oct 21, 2005 4:09 pm
Location: Manitoba, Canada

Tue May 01, 2007 5:50 pm

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?

Erik
 
phendry
Member Candidate
Member Candidate
Posts: 258
Joined: Fri May 28, 2004 4:42 pm

Tue May 01, 2007 8:35 pm

What does the 532 run at with 30 or so Nstreme customers? Any one running it on a 1ghz+ PC platform?
I've seen a few posts from people using X86 Athlon based boards which show the same problem so don't think it's a CPU issue.
 
karyal
Member Candidate
Member Candidate
Posts: 168
Joined: Sat Nov 12, 2005 12:09 pm

Wed May 02, 2007 1:40 am

What does the 532 run at with 30 or so Nstreme customers? Any one running it on a 1ghz+ PC platform?
I've seen a few posts from people using X86 Athlon based boards which show the same problem so don't think it's a CPU issue.
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
 
phendry
Member Candidate
Member Candidate
Posts: 258
Joined: Fri May 28, 2004 4:42 pm

Wed May 02, 2007 2:58 am

On an RB 532 the best i could get (TCP, real world, single nstream, single antenna, single radio, 20Mhz channel)
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!
 
karyal
Member Candidate
Member Candidate
Posts: 168
Joined: Sat Nov 12, 2005 12:09 pm

Wed May 02, 2007 3:08 am

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!
Yes, i understand your point, but unfortunately i can't help , except confirm that i've found much better results without nstream :D
Bye,
Ricky

Who is online

Users browsing this forum: MSN [Bot] and 30 guests