I have copule of links with nstreme (wds). After upgrade from 3.30 to 4.1 they doesnt work properly. They disconect,connect,disconect....... After downgrade to 3.30 everything work propely. Please help me.

Send supout.rif to support before and after let them look at the data..

Scott

check the hw-retries count, maybe it is too low. As in v4.x and v3.x wireless-test package uses the hw-retries count also when you have enabled the nstreme.

I am also experiencing problem with NStream in 4.1.

I have change the hw-retries, with no effect. The link works fine until you put lots of traffic through it. The CCQ starts dropping as the traffic gets more and eventually the connection gets lost.

This happens with a RB433 and RB411 each with an R52N card and running 4.1. The link works without any problems when you turn off Nstreme. This link worked fine in 4.1rc, and only gave issues after upgrading to 4.1

Any advise?

I too have had some recent issues with some links but I cannot say where the problem orginates from - whether its interference or ROS 4.1 upgrade. I have not downgraded and really don't want to. Just wanted to mention that I have seen changed on many of my links in the past week in different areas that would perhaps support the idea of a problem in 4.1...

We use Nstream / polling / cmsa disable and no framer on all our links

Scott

The same erratic behavior here.
Luckily, I have a visual demonstration of the problem.
I am tracking every parameter of the wireless links (client side) with MRTG (dBm, rx-rate, tx-rate, traffic, unicast packets)

There is this 5.4Ghz omni antenna acting as an AP-bridge (RB600A, Nstreme enabled, upgraded to ROS 4.1 a few days ago). The clients are 433AH RBs or 333 RBs and they are still on ROS 3.30. From the moment I upgraded the AP to 4.1 the rx-rate analysis graph shows significant changes.
The clients are still on ROS 3.30 and there are no changes on the tx-rate graphs...

This is what I noticed:

The rx-rate was 54Mbps, ALL the time, with the AP running ROS 3.30 but with 4.1 it fluctuates a lot and a great deal... Take a look:



... on the other hand, the dBm analysis shows no significant change in the same time period...:



The same scenario happens when I use the wireless-test package in the 3.2x or 3.3x RouterOSes (again, I am talking about changing the wireless package at the AP side, NOT the client side)

Regards.

Same problem here, I even tested a downgrade.

Scenario:
RB600 <> RB411 17,5km wireless link, using nstreme best fit, disable csma.

with ROS 3.30 is throughput stable at 20mbit/s
with ROS 4.2 is unstable between 13-18mbit/s

same frequencies same everything.

Did anyone find solution?

We also found NStreme under 4.2 very unstable and simply downgraded to 3.3 and it fixed it.

Well they just came out with upgrade today and it doesn't mention anything about nstream. As far as I know a problem has not been acknowledged even though many users have reported the same findings... Hopefully some day the results will be better.

Scott

Ive been having some issues too.

Links that would run for 150++ days with nstreme on with v3.x now only will run for 6-7 days on 4.x before disassociation
or get error like not polled for too long.

Ive re-enabled CSMA to see if that helps, and changed my framer policy to best fit from exact size.


These are PtP links and I cant disable polling or I only get a fraction of speed across the link, no need for polling on a ptp link but nstreme doesnt seem to work with it disabled.

EDIT: I had to disable nstreme on all my ptp links because of unstability. running any sort of both-way bw test caused link to go very slow throughput or crap out altogether, wthout nstreme at least the link is strong minus some bandwidth.

Can someone make me happy and confirm 4.3 fixed this issue ?
For me the incompatibility is making the 4.x fw unusable until it will get fixed.
Hope MK will fix it soon.
Wish all the best

Jan

We have encountered the same problem

we have some link in nstreme and we use ubiquity and mikrotik minipci card
and rb600 and rb433ah

with 3.x version all is working correctly
with 4.x nstrem is not working correctly (ccq downgrade when we do some traffic)

the problem i very very very big for us because whe have to downgrade many of hour basestation to 3.x OS
but in some routerboard we have link in 802.11n and link in 802.a+ nstreme technology
and, if we want continue to use N technology, we need to not use nstreme (that give us when working, a very good rate)


Mikrotik, please help us .. the problem is real, tested and it is big for us

Same problem, links would fall on the CCQ to near 0% or completely disconnect and reconnect.

Its fine with 3.30.

Its about time for a MT rep to chime in again on this as we have heard nothing for some time.

You guys send some emails with info to support to might help get some quicker attention as well.

Scott

Its about time for a MT rep to chime in again on this as we have heard nothing for some time.

You guys send some emails with info to support to might help get some quicker attention as well.

Scott

I submitted a ticket a few days ago on this thread and have had no answer of any sort. I specifically asked them to chime in.

I thought it just me with this issue - now I feel better.

v4.x is completely unusable for me - then someone said enstreme was outdated in v4.x - what??

I went back to v3.28 before I got stable connections back!!!

I really would like to have the features of v4.3 - vaporware???

A lot of people have problems with nstream and 4.x not just the small number of people on this thread. The list is much larger... Mikrotik's consultants know about it too and they work with lots of people consulting with MT.

Scott

I have the same problem

I had two RB 133C3 and one RB 333 with nstream on.

Upgraded to v4 and the link was jumping up and down, unable to use the link.

Trying to create a supout.rif on 133C and after that it was dead so i installed a new 433
and now i can use the link between 433 and 333 wich v4 installed but the 133C link i down.

Downgraded my 333 (this link talks to the other two) to 3.30 and both links are up again. With
4.3 on 433 and 3.30 on 133C

Also tested without nstream and all versions are working, so the problem is 133C and nstream and v4

This SUX

Sten
SM7LQP

I can safely say that you are probably the only person on this thread using a 133c with 4.x and nstream on a ptp link. Problem still exists for the rest of us.

Scott

Ya, I am still stuck on 3.30 on my backhauls and my ticket went ignored.

I get a hard time from MT for trying to get a solution on here, I open a ticket like they ask, and then they ignore it.

That is the problem with open source community supported software. Oh wait, this is closed commercial software that I paid thousands of dollars for . . . .

what is your ticket number? We don't ignore tickets, they all get answered.

what is your ticket number? We don't ignore tickets, they all get answered.

Wondering if there was a resolution to this, was it a verion issue or config? I did not notice and nstreme fixes in the release notes post 4.1.

Reagrds, Andrew

There is no resolution yet.

and you didn't post the ticket number which you claim is unsolved ...

Does that mean the nstreme users should stick with 3.X until some resolution is publihsed in release notes?

I have not logged a ticket on this as the thread was resolved - I don't have hard and fast data just observations that match with some screen shots of -60's reporting 6 and 12 bmps speeds.

Any thoughs appreciated.

Regards, Andrew

we don't have any outstanding reports in the support dept. as you can see, I asked for the number of the unresolved ticket, and didn't get a reply

we don't have any outstanding reports in the support dept. as you can see, I asked for the number of the unresolved ticket, and didn't get a reply

Thanks Normis, I did notice the lack of follow-up form the previous requests. I will look to log a issue with support regarding this. My quetion was in relation to 'Know Issues'. I believe some vendors 'resolve' support tickets by creating a 'know issue' which will/might be fixed later.

Not knowing Mikrotiks policy I was simply looking for confimation of anyone else seeing the same symptoms that I have or specific details regarding nstreme.

If others are using nstreme 4.4 sucessfully my issue my well be different. Any details on experience of nstreme in v4.4 would be appreciated.

Regards, Andrew

Hello,

I too have a problem with v4 of RouterOS, using nstreme. Distance is 2km, bridge and station wds, auto ack. The signal is good ( about -55 ) in 5GHz-turbo on both ends, but in a bandwidth test or any traffic, the link either disappears completely or the link has very bad throughoutput ( 1-2 Mbps ). CCQ drops to about 13-14%. Different channels, same result.
Simply downgrading to v3 made the link work perfectly ( ~70Mbps on turbo and ~42Mbps non-turbo).
Any news on this?

Thanks.

Many people have problems with 4.x and nstreme, the solution is very sample : DOWNGRADE to 3.30 and NOT USE 4.x because nstreme is corrupted and is useless to ALL USERS that uses nstreme...

BR

please provide us access to such link where in v3.30 it was working perfect (max data throughput) but in v4.x it doesn't work. I would help us to find the problem if there is such, maybe it is just the configuration problem.

I can provide acces to the link that doesn't work in v4 but works in v3. Contact me on my email address or give a google/skype/yahoo id.

I can provide it too... contact me via MSN ( see my profile for my MSN )...

BR

I can provide access to such link. My email andevariel@gmail.com, ICQ 207-100-964. Remote access already configured. Thank you in advice.

We too are tinkering with the Nstreme setting in a point to multi point setup and having some unexpected results. We would have down graded to 3.30 but that usually changes many configuration settings in the device.

Our observation is that when an A.P. with 30-35 clients are associated and Nstreme is enabled with polling from the A.P. that the CCQ stays high and so does the latency; throughput is low even though everyone has a great signal and is with 3 kM of the A.P. Not sure why this is happening; but turn off polling and latency becomes much more normal.

Adam

Has anyone had any joy with 4.5? I know from many other much larger wisp forums that most who run PTM mimo links with N-Streme are running early beta releases of v4 as this is the only way to get support for the cards and relatively stable performance. Although we haven't yet tested v4.5 in this kind of setup, we have seen similar poor results with all other "stable" releases of v4.x.

I have not tried 4.5 but in the absense any other soultion I have downgraded to 3.3 and throughput and speed stability have returned.

I did not see anything in the release notes about for 4.5 about nstreme so I am not hopeful.

Support suggested changing the framer policy with 4.4 but I could not see any differences with alternate settings and subsequently downgraded.

Andrew

Has anyone had any great success using Nstreme in point to multipoint with the later editions? Several of our tower sites are chock full of the classic hidden node situation so we were looking to the polling component to ease the congestion.

Adam

I have not tried 4.5 but in the absense any other soultion I have downgraded to 3.3 and throughput and speed stability have returned.

I did not see anything in the release notes about for 4.5 about nstreme so I am not hopeful.

Support suggested changing the framer policy with 4.4 but I could not see any differences with alternate settings and subsequently downgraded.

Andrew

didn't you see the topic about resetting wireless interface and changing the hw-retries setting, that seems to have fixed most of peoples nstreme issues?

didn't you see the topic about resetting wireless interface and changing the hw-retries setting, that seems to have fixed most of peoples nstreme issues?

To be honest I have not been reading any other topics as this one already related to my issue and there does not appear to be a clear resolution listed within this topic.

From a quick scan tudor, mandrade, Skaught, sbr all appear to have unresolved issues (as far as I can see from this topic) and support (#2010011266000137) recommended chaning the framer policy and changing the hw-retires but it did not have any effect.

By 'resetting' do you meaning removing the nstreme configuration and starting again? - and what is the recomended setting for hw-retries?

I will go and have a look for the other topic. I still have some 4.4 systems on the bench and should be able to test in the next day or two.

Regard, Andrew

nope, mandrade also got his problem fixed. see RouterOS v4.5 topic. also this is the reset script:

http://forum.mikrotik.com/viewtopic.php ... 23#p187823

Thank you Normis, I will try this this afternoon and see what happens.

Adam

I re-enabled nstreme on 2 of my 7 links previously that I had to disable nstreme on for instability.

one is 22km, and I set the HW retries to 10, from 7, and this link is stable under heavy load, just like it was in 3.30 non-wireless-test.

Other is about 5km, and is also performing well in very noisy conditions.

I didnt use the reset-configuration script.

So maybe the HW retries is the answer to nstreme links being stable

I will let these run for a few days, and re-enable one or 2 of my busiest links which were absolutely terrible with nstreme turned on, all remaining links are about 7km

I never updated routerOS, Im at 4.1 or 4.2 on everything.

EDIT: Upgraded one link to 4.5, same stability and performance, see below.

I found that fantastic performance is gained from bandwidth tests (TCP) if you do a send test and a receive test separately, but a BW test with both direction, performance and CCQ are all over the map from good to poor.

EDIT 2: With a BW test set to "both" and TCP count greater than 4 or so, then performance is up and down, but with a TCP stream set to 1, performance is rock solid.

I experienced wireless problems without Nstreme being on in 4.5. Really screwed up a day, and pissed quite a few customers off. Didn't realize that the problems I had with a new link established some time ago were related to 4.x, then ran it yesterday on one of our main bhs assuming that any bugs were going to be minor. What a mistake! Don't use 4.x with wireless unless you like to convince your customers you don't know what you are doing....

As others mentioned, link became unstable, dropped every few minutes, and this is a link that has sig. in the 50 db range. It's long, (17mi) with 32 db antennas. Back to 3.x, stable as a rock. BTW, I downgraded the new link that was built from 4.x from inception (I thought I had some sort of strange hw problem!), and that link went from unstable to stable. (I've created at supout in case MT needs it.) I'm in the process of removing 4.x from all of my network...

Most of the time MT is really great...and it's that reputation for excellence that got me in trouble here. Now I will verify, then trust! There are big problems with 4.x wireless!

I experienced wireless problems without Nstreme being on in 4.5. Really screwed up a day, and pissed quite a few customers off. Didn't realize that the problems I had with a new link established some time ago were related to 4.x, then ran it yesterday on one of our main bhs assuming that any bugs were going to be minor. What a mistake! Don't use 4.x with wireless unless you like to convince your customers you don't know what you are doing....

As others mentioned, link became unstable, dropped every few minutes, and this is a link that has sig. in the 50 db range. It's long, (17mi) with 32 db antennas. Back to 3.x, stable as a rock. BTW, I downgraded the new link that was built from 4.x from inception (I thought I had some sort of strange hw problem!), and that link went from unstable to stable. (I've created at supout in case MT needs it.) I'm in the process of removing 4.x from all of my network...

What where your hw-retries set to before you downgraded?

The same erratic behavior here.
Luckily, I have a visual demonstration of the problem.
I am tracking every parameter of the wireless links (client side) with MRTG (dBm, rx-rate, tx-rate, traffic, unicast packets)

There is this 5.4Ghz omni antenna acting as an AP-bridge (RB600A, Nstreme enabled, upgraded to ROS 4.1 a few days ago). The clients are 433AH RBs or 333 RBs and they are still on ROS 3.30. From the moment I upgraded the AP to 4.1 the rx-rate analysis graph shows significant changes.
The clients are still on ROS 3.30 and there are no changes on the tx-rate graphs...

This is what I noticed:

The rx-rate was 54Mbps, ALL the time, with the AP running ROS 3.30 but with 4.1 it fluctuates a lot and a great deal... Take a look:



... on the other hand, the dBm analysis shows no significant change in the same time period...:



The same scenario happens when I use the wireless-test package in the 3.2x or 3.3x RouterOSes (again, I am talking about changing the wireless package at the AP side, NOT the client side)

Regards.

How can I get the graphics to show the Dbm signal strenght like these pictures?

How can I get the graphics to show the Dbm signal strenght like these pictures show it in this post?

HW retries unknown, I was in such a panic to get the link fixed. Next time I want to waste a few hours (wee hours), I'll give it another try.

Yes, in case of some link trouble, do "/interfade wireless reset-configuration", re-apply the most basic settings and increase the HWretries setting to 7 or more.