We have optimized the Nstreme code, that performs much better for point to multipoint environment. It is necessary to use new Nstreme package on Access Point router, client routers can use old version, but we recommend to install new package for clients too.
Packages for download:
mipsbe package;
mipsle package;
ppc package;
x86 package.
For more information and any problems with test package, please contact MikroTik support (support@mikrotik.com).
Hi sergejs
Can you explain what has changed in Nstreme ?
Should I install this upgrade in a point-to-point scenario?
We have improved the polling mechanism for nstreme.
Please let us know if that solves the problem with the lot of wireless nstreme clients (more than 30).
About point-to-point, you can also install it on the point-to-point links, but the most benefits are for point-to-multipoint.
I have put this package on ~20 various AP’s and it has tremendously improved AP’s and customer performace on mipsbe and mipsle chipsets only. On PowerPC units with Nstreme on it has absolutely destroyed the throughput, latency and jitter.
Has anyone else seen this?
Steve
Pocketinet Communications
Please make the support output file from your PowerPC AP when you see worse throughput with the new test package. Send it to support@mikrotik.com
we have updated these test packages, please download them again. There was a bug (kernel panic) when creating support output file with regular wireless mode (not nstreme).
Any clues on what has changed? Fragmentation? Any config changes we need to plan on to optimize this, or is it all automagic?
thanks!
Randy
Also, you “recommend” upgrading the clients, but it was not necessary. Is there a benefit to upgrading the clients? Some more info about the changes would be very helpful.
When trying this on an RB532 we get the printout at the end of the message. If we can log in fast enough and disable the test package, everything is fine. This happens on two different mipsle boards.
MikroTik RouterOS 3.15 (c) 1999-2008 http://www.mikrotik.com/
dec/31/2001 20:00:05 system,error,critical System rebooted because of kernel
fai
l
ure
dec/31/2001 20:00:05 system,error,critical router was rebooted without proper
sh
u
tdown (cause 1)
dec/31/2001 20:00:08 system,error,critical System rebooted because of kernel
fai
l
ure
dec/31/2001 20:00:08 system,error,critical router was rebooted without proper
sh
u
I have installed on several RB532 boards with no problems.
Polling algorithm has been adjusted to be more suitable for large numbers of clients and for most common traffic patterns (bursty traffic with rather low average rate). As polling is controlled entirely by AP and protocols are backwards compatible, only AP is required to be upgraded.
There are two reasons why it is recommended to upgrade clients as well - first, there are some improvements for clients to increase efficency (but that should not produce notable improvement, therefore it is not required), second, all development happens with new test package on both AP and clients, therefore only this combination can be considered best optimized. Although reports on test results when using older clients are welcome as of now, you can expect that support will ask you to upgrade some time later, when that will matter.
As of now, test package does not require any configuration changes/adjustments - consider it all “automagic”. New wireless configuration settings that have been added to wireless-test are not pertinent in this case as they do not affect nstreme operations.
Fragmentation of packets has been available for nstreme before (controlled with framer-* settings). These improvements do not change or affect that.
There are some other improvements in development that should further help jitter issues over PtMP nstreme links, so you can expect new test packages soon. Feedback in form of supout files and detailed problem descriptions are welcome.
we tested the new package on two misple 532 and it is fine.
One AP have 44 clients and another 30.
In both cases the new package performed better them the regualr one. The latency when down from 40-60ms in the first cast o 6-10ms.
BUT
but the jitter is still here, in fact it does several ping to 6-10ms and then goes to 120ms for some seconds then it is back to normale, or on packet at 6ms and the following at 120ms…
So i think the poll mechanisme has provided a very good performance but MT should still work on jitter.
Then letting us to use queue in the way to reporduce WMM should close the gap to a professional system.
Regards
Ros
We have updated the wireless-test package. Please download them again, upgrade your routers and report back how it is working.
Tested release of today 24/10
very very promising.
Tested only on mipsle.
Higher CPU usage and this is a nice thing for wireless customers…
very few spike in latency, and bettere average performance on latency.
Good work.
Ros
When was the rebuild of the wireless-test package? i downloaded theses in 10/20/2008…
they were updateted yesterday.
We tested them on three wireless router and only on one we had a little isse about changing on the fly the Hardware Retries, it crashed the router.
Disabling the interface changing the parameter and then re enabling the wireless worked around the problem.
The performance of last build is fantastic.
GREAT WORK MT.
Regards
Ros
I’m testing this now on a ppc board with 25 clients. It is working quite well.
Previous version did not work well at all on the ppc boards.
Thanks for the great work.
Steve
Pocketinet
did it create an autosupout.rif file? if yes then please email it to support@mikrotik.com
Put simply, AMAZING IMPROVMENTS!!
we’ve tested on 3 of our heaviest loaded / worst performing PtMP APs, 2 of them are using SR9 radio’s and the other has a XR5. the SR9 APs (one 532 and one 333) have shown improvments from average latency of 100-140ms (jitter ranging from 20ms to 300ms) down to now 15-20ms average latency and jitter ranging from 7 to 40ms
Additionally radio uptimes on the SR9 links seem to be noticably better with much less bouncing (momentary disconnect / near instant reconnect) of the connections.
the 5.8ghz AP showd even less jitter, and average latency of about 8ms to most clients! (improved from 30 to 40ms previously)
will be testing on a few more APs over the next few days assuming these 3 don’t show any problems.
all around this seems to be a wonderfull update, and I strongly encourage people to test this out in the field and report back their experiences.