Thanks for the responses guys, care to comment on this capture then?...

I assume the picture is taken from AP side of the link. There is 6.5mbps mentioned in registration table as TX modulation. It could be that the link is in locked modulation state but to be sure you need to check the other side of the link and inspect the measured SNR. If there is only one or 2 modulations which have fresh data and the other modulation's data are 'old' (and they stay old even if there are data transfered through the link) the link has really probably locked modulation. The CCQ on station will probagly be 100 procent in the case too.
Of course on locked state there should not be usually (probably in rare cases the link can lock on the highest modulation too) the highest modulation in the fresh ones - if you have exceptionally good link (no interference) it can run on highest modulation all the time (except packets sents purposedly in lowest modulations - broadcasts etc)

This was one of the original SXTs that I changed because it wasn't passing data. It's shown running 5.23 and as you can see according to the wireless signal level it appears to be fine, if only a bit slower than normal, the link had been up for just over an hour, the last measured rate shows 6Mbps at the top of the list like my other picture, but you can see from the wireless link speed it's locked to 6.5Mbps. It was normally 243~270Mbps for almost a year before it "failed".

Even on a link in good state you will always see the 6.5mbps modulation as the fresh one - again it is a default modulation used to distribute packets which should be delivered to multiple recipients at the same time (broadcasts, multicast etc). Because the default (or basic) modulation is the only one which all connected stations must be able to use.
So having 6.5mbsp as a fresh modulation is not the proof of problem.

I am not saying you have no problem with the link - I am just saying that it looks like you have no nv2 modulation locked problem like we were observing. If the problem occurs again try to create snapshot of meassured modulation on CLIENT side (station)

I'm not about to get into an argument on my findings, but when the 6Mbps is ALWAYS at the top of the client last measured rate list, I know there's a problem, I then run tests across the wireless link and prove it because the traceroute time from both sides will be 1ms or 2ms one way and sometimes 100s from the other, it sometimes even times out.

on a good working link you should see the basic (6.5mbps) modulation and the highest one(s) on the top of the list of measured modulations (sorted by time) = most of packets received on highest modulation and the broadcasts and service frames received on the basic modulation.

Judging by the last measured rates alone would suggest the link is fine as you've pointed out in my previous picture, however, looking at the wireless link speed of 6.5Mbps and the CCQ you can see there's a problem. In my experience of this, it is my understanding and observation that there is no direct correlation between (1):CCQ, (2):wireless link speed and (3):last measured rate time.

I have monitored the CCQ to be ~ 80-100% and the wireless link to be 243Mbps/270Mbps yet last measured is 6Mbps and other times it can be 4/80% CCQ, wireless link 6.5 ~ 162Mbps/243Mbps with last measured as in my previous shot above showing 6Mbps, HT40-6, HT40-5, ... in that order yet still struggling to pass data across the link.

It seems to me there IS a correlation between the CCQ and wireless speed, but not between wireless speed and last measured. However there is always a correlation between poor throughput and last measured. If it is always or nearly always 6Mbps as the last measured rate, then throughput is bad.

I know there's a problem on my network because I use it, I am a client of it and when it drops out, I search for where and it always turns out to be on one of these links where last measured is 6Mbps, even when there's others measured higher below it at the same time, if 6Mbps is ALWAYS last measured, then there's a problem. The links that are solid with no problems NEVER or rarely show 6Mbps as last measured, it's always, or nearly always the 2nd or 3rd in the list, like the first picture I posted above.

When I search for a problem that's how I find it, I look at the client last measured and if it shows 6 most or all of the time, I then run a traceroute over it which shows the poor speed. The attached picture below shows 94/94% CCQ, 270Mbps/270Mbps link speed last measured at 6Mbps and the average traceroute speed at 70ms, this is between the 2 SXT's directly wirelessly connected to each other under 6.9. After contacting support, I was given and tried it with 6.8rc1 but it failed straight away and never got better. I gave support access to them, sent them screen shots and supouts but they visited it only once and told me to upload 6.9, after which I've been ignored!!! This shot is taken AFTER I tried with 6.8rc1 and then upgraded to 6.9 but it still has the EXACT same problem.

if this snapshot was taken from client side it does have measured RX levels which looks like there is a modulation lock. But I would expect the 100% CCQ in RX (maybe even on lowest modulation the link is not fully reliable).
There is 13 minutes gap between 6.5mbps modulation and the others. Which should mean all the data in last 13 minutes were received on 6.5mbps modulations. So either you have only broadcast/multicast packet going through the line or there is modulation locked.
There is 6.9 on the radio - what version of ROS do you have on the other side (it should be the AP od th elink probably)? I guess/hope you have there something older than 6.8rc1. If not than the NV2 locked problem was not really solved yet. You have to have both sides of the link od 6.8rc1+ ROS ...

I've since loaded 6.10 on this link where I noted the RX/TX chain problem and set it up so the problem end is the AP which seems to have solved it for now. It's been 5 days, whereas when I had it setup the other way it failed straight away and didn't get any better even after 3 days.

Support always says about giving steps to recreate the problem, but they are so far not willing to spend the time to investigate my problem where it occurs straight out of the box.

the problem is that it is not possible to see what exactly is causing the problem by observing (connecting to) the radios. They did it in our case and it involved installation of special packages to the radios - with restart so the locked modulation problem disappeared and we had to wait for the another problem hit.

I am very wary of upgrading links as it seems we are being used as test subjects. I don't feel being told to "try" something is solving anything. I understand it's difficult when a problem occurs, you need to be able to re-create it to then find a solution, but when the fault happens straight away from first power up, what better scenario can there be to jump on it and find out why?

what I know about the problem there is no report of it since ROS6.8rc1. May be your case it the first one but I hope it isn't

In my humble opinion, it is the last measured rate that is holding down the wireless speed and choking throughput, not that there is a wireless problem, if this is software triggered from hardware, then the problem is hardware and I am here, willing and able to give as much time to solving this as you need MikroTik, my family, livelihood and business depend on it, just don't take too long, it's already been over a month and in another month my network will hopefully be servicing hundreds more clients using your products, so don't fail me..,

Gary

[/quote]

I would like to add one comment yet:
- the problem with locked NV2 modulation seems to have something related with radio interference. Probably if there is no interference the problem will not likely occur. You are using wide channel (40mbps) which does increase the probability of interference (IMHO)...
- if I need to transfer approx 50mbps+ I use more professional equipment than Mikrotik ones (using 10ghz or other band suitable for directional radio links). In this way I (and many others) am saving the 5ghz band for another use (delivering data to customers via APs etc) and I am having more robust and reliable uplinks...

Until 5.22 the link between my two SXT's with both chains activated used to enter stall mode. After 5.22 stalling was fixed but it entered 6.5 Mbps rate mode.
Since then I only use SXT on single chain mode.
Is there someone in the world who linked two SXT's for a week with traffic spikes of 40-60 Mbps and had no problems? I have 4-5 setups and I just gave up the ideea. (Lucky me the bandwidth of a single chain was enough)

Until 5.22 the link between my two SXT's with both chains activated

Upgrade to 6.11 http://download2.mikrotik.com/routeros/ ... e-6.11.npk

the problem with the locked data-rates to 6.5mbps is fixed in newer Router v6 releases.
Please upgrade the RouterOS to the current release - v6.11
Also you need to upgrade both - AP and the Clients.

Upgraded to 6.11. Firmware 3.12.
The issue is still there just that it has other flavour.
It worked well for 30 minutes and then the connection rate (for tx in this specific case) went up and down from 6.5 to 120 Mbps. The RX stayed at 270/300 Mbps.
The throughput can be seen in the picture. Now I upgraded both sides to firmware 3.13 and rebooted. Currently showing 270Mbps/300Mbps on both sides with BTEST udp running fixed at 50Mbps/50Mbps. I will get back with the results.

Every single link with SXT's with dual chains enabled that I tested developed the behaviour. How cannot this issue be isolated? Really.

And I am back with updates: Disconnecting the link by clicking the minus sign (-) on the side with low TX CCQ caused a reconnection but the CCQ and rate were still low (not steady 6.5 but oscilating at 6.5-60 Mbps).
However, if I disconnected the link from the other side it started working well again.

Bottom line, the issue is not fixed yet.

LE: The link dropped with control frame timeout/registration timeout. Link restored by watchdog on the other side. Disabling the second chain for another year or so ) ...

Disconnecting the link by clicking the minus sign (-) on the side with low TX CCQ caused a reconnection but the CCQ and rate were still low (not steady 6.5 but oscilating at 6.5-60 Mbps).
However, if I disconnected the link from the other side it started working well again.

Bottom line, the issue is not fixed yet.

We have the same issue as you. Problem is not fixed yet. With ROS 6.10 on both sides of P2P link. TX CCQ is vely low and rate is 6,5-30Mbit.
After remove wireless client (clicking minus) then is everythink OK - tx/rx - 130/130. CCQ ok
Unfortunately I forgot to generate supout and send to support. If you have supout.rif (before and after) sent it to support@mikrotik.com

How often does it happen now with newer RouterOS versions?
If you are able to reproduce this problem please report to support@mikrotik.com with the support output files attached from both ends.
Also if you could provide remote-access to such link, it would help us.

I have a similar problem. After upgrading to 6.12 from 6.9 there was bad connection between two sxts (about 300m) for several days, than Tx locked on 6mbps on an AP and Rx on a client without any real throughput. Restart and downgrade to 6.9 didn't help. It was set to 5Ghz-A/N, 40Mhz, NV2. I've tried to switch it to only A, 20Mhz, 802.11 and different channel, it didn't help. Rx on the AP (Tx on the client) jumps from 6mbps to 90mbps (before upgrade it was 180/180, I've disabled higher modulations) on N and to 54mbps on A.

UPD: Ticket#2014042266000767

On newer releases (or older, same thing) it happens every 1 or 2 hours, on every link that i've tested if the throughput is constant over 40 mbps.
I see this behaviour especially on SXTs, but also on rb711G-5HnD (once in a week or so but this week occured 3 times).

It only happens when running with both chains enabled.

Please contact the support@mikrotik.com to get access to the v6.13rc versions so you could try out the new test RouterOS version which has some improvements for the wireless driver including the new wireless-fp package.

When you are doing the 40mbps test when it goes down does it gets back to 40mbps after some time and if yes how long do you need to wait till that happens?
Also maybe you have some misconfiguration issues, try to reset the wireless configuration and configure the settings you only need and try again.

Maybe you could provide us remote access to your link so we could debug it?

Are you saying that you set up a test link and did btest for hours and didn't saw this issue? In my opinion that's it all it takes to see this *specific* case.

The throughput never goes back once it degrades.
Misconfigurations - I personally think are excluded. 7 links, all of them with minimum settings (n-only mode, nv2, station bridge on client, bridge mode on the AP side).
As power source I use http://www.meanwell.com/search/AD-55/AD-55-spec.pdf , cable runs 15 m - 60 m.

we haven't seen such problem in the test link.
If you could provide us remote access to such link where the problem could be easy to reproduce that would help us to find the cause of this problem and hopefully to fix it as well.

Hi boys!, i'm from Argentina, and i have the same problem with a ptp link with 2 STX.
The bandwitch is going alright for 10.. 15 minutes and then all the traffic go to down. In these moment the Wlan interface is locked to 6.5 Mbps.

I tryed distinct routeros releases, and upgrading the firmware, but i cant fix the problem.

somebody have any news?

i'm Sorry for my bad english.
best regards

oxigeno20, please contact support@mikrotik.com and send us the support output files from both ends. That could help us to understand the problem and how to fix it.
If you could provide us remote access to your link it would speed up the process as well.
How often does this problem happens?

This happen in a 800 mt backhaul link where we connect to the Fiber of Silica Network. We are buying 100 Mb and we need transport these bandwidth with this link.
The bandwidth test is OK, but when i use channel width 20/40, everything's going alright, until every 10, 15 minutes the data rates goes down and get locked to 6,5 mbps; too, the traffic go away.
The only way to unlock this is re-enabling the wireless card. (but the radio link never lost, is like if, i lost the IP connectivity)

Otherwise, when i use channel width 20, or 10 the link works well. But the bandwith is very poor. But at less it isn´t lost conectivity.

I don't have remote access to these link, because it was replaced by two Ubiquitis Rocket 5M.

If you find the solution, we can come back to test again.

Best Regards
Nicolas

I'm having a similar problem with a pair of SXT 5nD r2 s. I'm about to put them in the field so I hope a remote fix is possible... Putting both of them on a table and getting them to link, before deploying as a PtP link, I got a signal strength of -41 to -56 (if I *try* to keep it low), but the speed sticks at 6 Mbps both ways. Tx/Rx CCQ is 6/6, but the composite CCQ is more like 74. I have them in NV2 with 20 MHz channels, but tried 20/40, and tried 802.11, and it still seems stuck at 6 Mbps.

Any clues? Thanks.

From ROS 6.11 or 6.12 I never seen this problem (locked modulation to 6,5Mbit)

One of the two radios is at 6.13, the other at 6.17 (I upgraded it when I unpacked it).

Now that it's in the field, the two units about .3 km apart, the link is working at full speed. The signal is actually stronger than it was in the office, since they're pointing at each other. Is it possible that using them indoors leads to multipath problems?

Following up my July post... the two SXTs have been in the field. Until a few weeks ago, they were happily locking in MCS15 or at least close, being dead line of sight 980 feet apart. They don't often carry much traffic as they're a backup link, but help keep the network resilient.
Then about a month ago we had about 8 feet of snow. (Actually, a series of storms, first 3 feet then 2 feet and then more. It's a mess here in Boston. The snow pile is 2-3 feet high after its own compression.) The radios are on rooftops, on sleds, and one of them, on a sled atop a city school, shut down. I suspect a cable problem but nobody has been up there. Both radios are accessible. A few days ago, the failed radio came back to life. The signal strength is -50 to -60 (I actually turned the out put down to +4 dBm since that's plenty.) But instead of MCS15, its mostly converging at 11a-6 Mbps or occasionally 11a-9 or MCS0. NV2 CCQ is 6, 802.11n CCQ is 61.
I've upgraded both units to 6.27, but it doesn't help the speed. Any ideas? Would snow in a Fresnel zone, or near the radio but not in the path, prevent higher order modulation from working? Thanks.

Maybe this problem was solved in old wireless package(to ROS 6.29)
With wireless-fp and wireless-CM2 is problem back (from ROS 6.30). NV2 molulation is locked with latest firmware and latest ROS 6.36.2
Someone with the same problem?