Very good question.

I can only say what is fact. Developers are not making changes for fun and games. They do actual work and work very hard. I know what they work on, so I can give you honest answer.

I have submitted a few tickets with the problems of NV2. The most recent was replied with "We are aware of the problems but we are fixing 802.11 first" I actually moved all of my point to point ac links to 802.11 (Can you even imagine it) and i was surprised to see that my throughput on tcp traffic doubled. My packet loss stopped and I no longer saw the incremental speed decrease i was seeing over multiple nv2 hops. Now my Multipoint Network is still NV2. It is stable enough to handle VOIP and decent Internet however. My customers that have VPN's are constantly complaining that they keep dropping the VPN connection. I am actually thinking of trying out 802.11 for multipoint as well (I know I know). NV2 is a great IDEA but it is a long way from a good working solution. I am also very sure that the Mikrotik Programers are working very hard. HOWEVER, I would make this suggestion. Instead of constantly adding new features. Stabilize what you have already released so it is usable by the people that are buying it for those advertised uses. Two philosophies I find are being more and more dismissed.

1. KISS it (Keep is simple stupid) - the more you Gum it up. the easier it is to break
2. Jack of all trades, Master of none. - You can't be all things to everyone but you can be the absolute best at a few things.

If i was Mikrotik I would ask my self these questions.
1. Is the base that made my company successful being served?
answer: No, Other companies has surpassed your stability and met your price point.

2. How do we Maintain our edge?
answer : Look at you company focus. and possibly split your development track of ROS into two branches.as
1. Consumer/SOHO/wifi branch - Focusing on new features and individual user experience
2. Carrier Branch - Focusing on Carrier related technologies. I.E. Fixing NV2 or making a better system. Fixing multi-core utilization with CCR.

It is a nice idea that one software will do it all. But the reality is. Consumer and SOHO operations require very different solutions then Carrier (wisp, ISP, etc.) operations do.

Please don't let ubiquity make Mikrotik absolute. I have allot of money in my Mikrotik network. (But I am starting to lose customers because of problems that are NEVER addressed in NV2).

Sorry so long winded.

Overall NV2 is very stable and yes its far from perfect, I have found NV2 to be more stable in noisy environments than 802.11, with Mikrotik as everything is done in software, CPU is king as faster CPU speed gives better performance?
I remove any packages not required and in a lot of cases default setting in wireless does not give me the best performance, so I adjust a lot of settings, in a nutshell you have to tweak like hell to get the best from Mikrotik and
in reality problems encountered by us can only be solved by us and some are under illusion that all issues can be solved by just getting better software, I think there should be special builds for different components ,
like PTP, AP, Routers, switches, etc as "One size does fit everyone perfectly"

We've been offering similar complaints to Mikrotik (face to face at MUM in NZ as well); and will STILL have an unresolved ticket that must be coming up 6 months old re: wireless performance and 4xx series board having issues with NV2 / Nstreme in 6.2x.x and we just get ye old "try the latest version" without any explanation and which STILL yields no improvement.

We have seen some improvement and good results out of 9xx series APs/CPE; but that doesn't really help us when we have several thousand 4 and 7 series boards out there that are wirelessly unstable on the latest versions of ROS (above 6.20); and Mikrotik appear to be making zero effort to work with us to resolve.

Long long long story short; we've been looking at switching to Cambium - even their ePMP equipment, at the very least does exactly what it says it will; and more importantly their support people are happy to be responsive and helpful.

FWIW its Ticket#2015021966000088

Its a shame; we love(d) mikrotik but it appears other vendors are now catching up / overtaking and even at Mikrotiks price point.

I do agree that tweaking is needed to get the most out of Mikrotik. I can not disagree more on a one size fits all perfectly. What you are telling me is a ISP with 2000 users should operated the same as a local wifi network. That is juvenile at best and as a forum guru i am highly disappointed in your reply. That is like saying that a linksys router works just as well as an enterprise cisco router. IT is simply untrue. In addition you don't see linksys (when owned by cisco) Run the SAME os as their enterprise routers.

The lack of understanding is starting to become obscene. When customers come to this forum with recommendations or requests. It is done as a loyal customer base trying to communicate with the company they do business with and Spend money on. The fact that all you ever get back is in just tweak it better is mind boggling. So Mr. n21Roadie Tell me how do you tweak NV2 to stop inherent packet loss and low TCP throughput when all you can adjust is frame size. Please put some examples and facts behind your statements. I have 3 different trouble tickets with full test results and configs on each system to Mikrotik with the reply that THEY KNOW THERE IS A PROBLEM. They just refuse to fix it.

I do agree that tweaking is needed to get the most out of Mikrotik. I can not disagree more on a one size fits all perfectly. What you are telling me is a ISP with 2000 users should operated the same as a local wifi network. That is juvenile at best and as a forum guru i am highly disappointed in your reply. That is like saying that a linksys router works just as well as an enterprise cisco router. IT is simply untrue. In addition you don't see linksys (when owned by cisco) Run the SAME os as their enterprise routers.

The lack of understanding is starting to become obscene. When customers come to this forum with recommendations or requests. It is done as a loyal customer base trying to communicate with the company they do business with and Spend money on. The fact that all you ever get back is in just tweak it better is mind boggling. So Mr. n21Roadie Tell me how do you tweak NV2 to stop inherent packet loss and low TCP throughput when all you can adjust is frame size. Please put some examples and facts behind your statements. I have 3 different trouble tickets with full test results and configs on each system to Mikrotik with the reply that THEY KNOW THERE IS A PROBLEM. They just refuse to fix it.

I omitted to add in my comment which should have read, "One size does NOT fit everyone perfectly" sorry?

to repeat I found NV2 to be more stable than 802.11 but a long way from being perfect as everyone knows here,

I am also a WISP and have had to solve my own issues, we cannot expect Mikrotik or any other supplier to solve our problems, why not - simply the issues are in most cases complicated with local and distant issues triggering some,

It never ceases to amaze me when users think better software will solve all wireless issues,
OK a particular build may suppress a issue for a while but does not solve it,

And in my opinion there is no supplier who can deliver wireless equipment "off the shelf" that is doesn't have operational shortcomings?

I like many others have setup a test network for testing new software before applying to the complete network and have spent a lot of time checking suggestions by other users and some were very good and others not so good, this is where I have got my tweaks that work for me, unfortunately there is no short cuts in getting the best or stabilizing a wireless network,

The first question I would be asking is what causes dropped packets with the equipment you have and how will i know if another supplier equipment will not have similar problems, no doubt some users will reply back saying brand x is great and then later you read others having a different type of issue with brand x

In my opinion there is a major fundamental operational issue with radio cards when they switch between TX and RX,
and this applies to all suppliers

You can argue for a while. We've end of 2015 and development goes on. Just tested a competitors gear and can't no longer argue to stay with nv2. I talked to MT. I talked in this forum that something has to be done. They developed hex and whatsoever but nobody cares. May be their decisions are appropriate for MT and they sell more home routers than cpes. So I have to shop elsewhere.

May be their decisions are appropriate for MT and they sell more home routers than cpes.

You can argue for a while. We've end of 2015 and development goes on. Just tested a competitors gear and can't no longer argue to stay with nv2. I talked to MT. I talked in this forum that something has to be done. They developed hex and whatsoever but nobody cares. May be their decisions are appropriate for MT and they sell more home routers than cpes. So I have to shop elsewhere.

I partly agree but as the switch to another brand for me will be a major task and cannot be understated the potential for increased number issues during the changeover,

To my knowledge all other competitors to date have two vital items missing
(1) Hardware auto tunable bandpass RF filter
(2) Custom Ratio of TDD for variable DL/UP

May be their decisions are appropriate for MT and they sell more home routers than cpes.

This is not a surprise but is my opinion is not accurate because YES they may not sell that many CPE's
for several reasons (price/performance, etc..) but unlike their competitors they sell components to "Made for Mikrotik"
companies, and this must surpass the sales of routers and switches.

One competitor integrates some filtering which allows to reduce interference on neighboring channels. There are 2 models. One has a sharper filter but allows only 40Mhz Channels. This is for PTMP. This is not GPS sync but reduces self interference and foreign interference. Did some testing and got some speedtest.net results (tcp) which blows mind.

You'll never swap all equipment at once. We've an always running update from older to newer equipment. Still 133c out there. So when we decide to do something new this is a migration which will run longer.

He is talking about rocket ac ptp and ptmp already available on market.

He is talking about rocket ac ptp and ptmp already available on market.

Well if he is I don't think they are doing front-end filtering (i.e. before first stage of amplification) any where else can be close to ineffective and sales spin makes for good reading.

lucky79, could you please post an export from your AP? Just to see how did you set it.
Did you change queue configuration? How did you test 70Mbps TCP?
Thank you!

/interface wireless
set [ find default-name=wlan1 ] ampdu-priorities=0,1,2,3,4,5,6,7 band=5ghz-onlyn \
    country="czech republic" disabled=no frequency=xxxx l2mtu=1600 mode=ap-bridge \
    nv2-cell-radius=10 rx-chains=0,1 ssid=xxxx tdma-period-size=auto tx-chains=0,1 \
    tx-power-mode=all-rates-fixed wireless-protocol=nv2

@lucky79
What is min and max distance for the CPE's to the AP?

@lucky79
What is min and max distance for the CPE's to the AP?

min 80m, max 500m

I think the conditions on this AP are very close to ideal, even there is many other collocated APs on neighboring channels (in my control) and some competitors around, there is very little interference.
So everyone should see similar results at least in their labs...

I have another AP 711GA-5HnD on 10dB OMNI with 13 clients between 50m and 3km, similar results, max throughput is around 70Mbps single TCP connection.

All clients on both AP are MIMO, some SXTs and some far CPEs PAR24Ex with 911s

@lucky79
What is min and max distance for the CPE's to the AP?

min 80m, max 500m

I think the conditions on this AP are very close to ideal, even there is many other collocated APs on neighboring channels (in my control) and some competitors around, there is very little interference.
So everyone should see similar results at least in their labs...

I have another AP 711GA-5HnD on 10dB OMNI with 13 clients between 50m and 3km, similar results, max throughput is around 70Mbps single TCP connection.

All clients on both AP are MIMO, some SXTs and some far CPEs PAR24Ex with 911s

Don't understand the need for a 24dBi CPE dish to travel just 3KMs, also the low client number on the AP's is helping you.

When you have heavy noisy environment, it's a great help.

We have even 29db CPE at such distance. Higher gain antenna = Narrower beam = better SNR. Of course, it allows us to use lower tx power, so we can reuse frequencies

Regards

Don't understand the need for a 24dBi CPE dish to travel just 3KMs, also the low client number on the AP's is helping you.

22-25dB CPE is a need for that distance to be able to sell 30Mb plans, especially when fresnel is not 100% clear. Add some noise and you would understand.
There are people in this thread with less clients and their throughput is much worse than mine, just showing that its possible but you need to engineer your network properly.

When you have heavy noisy environment, it's a great help.

We have even 29db CPE at such distance. Higher gain antenna = Narrower beam = better SNR. Of course, it allows us to use lower tx power, so we can reuse frequencies

Regards

I guess this is the secret. nv2 needs optimal conditions to scale in PTMP. Non optimal client connections tear tcp speed down. With .ac the requirements increase.

When you have heavy noisy environment, it's a great help.

We have even 29db CPE at such distance. Higher gain antenna = Narrower beam = better SNR. Of course, it allows us to use lower tx power, so we can reuse frequencies

Regards

I understand the use of high gain antenna's to give a narrow TX/RX beam but this does not apply to a Omni AP

When you have heavy noisy environment, it's a great help.

We have even 29db CPE at such distance. Higher gain antenna = Narrower beam = better SNR. Of course, it allows us to use lower tx power, so we can reuse frequencies

Regards

I understand the use of high gain antenna's to give a narrow TX/RX beam but this does not apply to a Omni AP

Why? From the client side, you will receive less noise with more directive antenna.

This will improve AP > CPE traffic.

We have some customer running with 29db CPE and connecting to Omnitik AP at 5-6km without issues.

Why? From the client side, you will receive less noise with more directive antenna.

This will improve AP > CPE traffic.

We have some customer running with 29db CPE and connecting to Omnitik AP at 5-6km without issues.

Why? From the client side, you will receive less noise with more directive antenna.

This will improve AP > CPE traffic.

We have some customer running with 29db CPE and connecting to Omnitik AP at 5-6km without issues.

Correct from client side with high gain directional it will have reduced signal pickup beyond main lobes in RX but the Omni
will have 360 degree pickup in RX mode, but then the lower gain of the Omni compared with a sector
AP is helping reduce the unwanted signal pickup

Is it just Omni's you use for AP's and not sectors?

It's not that I complain on wireless capabilities of mikrotik gear. It's kind of observation I made. About year ago after I got dissapointed by 802.11ac support from mikrotik I decided to use other producer equipment. The other one that gave me so much enjoyment to work with. But lately I was forced to upgrade some older links, and gave mikrotik one shot more.
Dynadish 802.11ac met my expectations. I was very happy to see nicely working ptp on new software 6.30.4. after few weeks I decided to upgrade other AP, mostly omnitiks. and here we are, what is wrong with.... multipoint mode?? It's a disaster! after day or two it eventually stops passing traffic to clients. neither auto nor 2ms mode helped. Omnitik AP, 12 apc connected, subscribers up to 16mbps, wireless data rate 39-78-90 some with dual polarization even 180mbps.
on the client side speedtest.net shows...3mbps and significant loss of packets. jitter is over reasonable range.
channel under spectral scan is totally clear.

I have complained about NV2 problems as much as anyone. I have notices however some improvement when using the wireless-cm package. You need to disable it from using cap and you push button authentication but i am seeing more stability and better tcp speeds. However The biggest issue i still see is actual throughput. On 802.11 and Routers 6.33 I do see fantastic speeds under 802.11(They did a update to the wireless-cm2 package. I don't understand why they can't bring these improvements to NV2.

I have complained about NV2 problems as much as anyone. I have notices however some improvement when using the wireless-cm package. You need to disable it from using cap and you push button authentication but i am seeing more stability and better tcp speeds. However The biggest issue i still see is actual throughput. On 802.11 and Routers 6.33 I do see fantastic speeds under 802.11(They did a update to the wireless-cm2 package. I don't understand why they can't bring these improvements to NV2.

I guess it is a HW limitation. The CPU is to weak to handle nv2 at higher data rates and higher number of cpes. Plain 802.11 is handled by the wireless part of the chipset. This wifi chipsets are not designed with a TDMA protocol in mind. For a chipmanufacterer like Atheros the numbers selled to WISP-Industry are neglectable compared to Laptop/PC Market. So MT would have to do some work at HW-Level to improve this. They still did not take this plunge (You have to spend a lot of money to do chipdesign) with the risk loosing the wireless part of their wisp business. For me it looks like they wait until Atheros delivers something better suited.

I've just reconfigured my PtMP setup from nv2 to plain 802.11ac, and it seems to work better now (tried nstreme too, but it also had issues like disconnecting frequently). Strangely enough, btest tcp results with nv2 seem significantly better than real speedtest.net results (that's what customers care about) - what's that, detecting when it's being tested like VW TDI cars?

But, don't the AC radios have their own separate CPU and firmware to offload the main CPU (unlike N radios)? Perhaps the TDMA protocol could take advantage of it, possibly at the cost of backwards compatibility with older radios? My setup is all new AC radios in clean 6GHz licensed spectrum (out of necessity, as 5GHz is already saturated), so why not make a new TDMA protocol specifically for AC radios if abandoning backwards compatibility helps make it work better.

One of the key differences that accounts for this is that the Ookla/Speedtest tools utilize multiple TCP connections to collect the measurement data which is key to avoiding the receive window limitation

I've just reconfigured my PtMP setup from nv2 to plain 802.11ac, and it seems to work better now (tried nstreme too, but it also had issues like disconnecting frequently). Strangely enough, btest tcp results with nv2 seem significantly better than real speedtest.net results (that's what customers care about) - what's that, detecting when it's being tested like VW TDI cars?

But, don't the AC radios have their own separate CPU and firmware to offload the main CPU (unlike N radios)? Perhaps the TDMA protocol could take advantage of it, possibly at the cost of backwards compatibility with older radios? My setup is all new AC radios in clean 6GHz licensed spectrum (out of necessity, as 5GHz is already saturated), so why not make a new TDMA protocol specifically for AC radios if abandoning backwards compatibility helps make it work better.

When you run btest, you're probably running several simultaneous TCP flow. When you run speedtest, just one stream is used, and results are lower

AC Radios do not have supporting CPUs to do TDMA. MT has to use the Atheros CPU of the chipset. There are Vendors who do HW-Modifikations to offload the CPU or to add GPS. This is what MT has to do to compete in WISP market. For home/indoor AP use this is not neccesary as this is plain 802.11.

AC Radios do not have supporting CPUs to do TDMA. MT has to use the Atheros CPU of the chipset. There are Vendors who do HW-Modifikations to offload the CPU or to add GPS. This is what MT has to do to compete in WISP market. For home/indoor AP use this is not neccesary as this is plain 802.11.

Well, but:
- UBNT M5 radios (ath9k) can do TDMA without an extra CPU, and while not perfect, they work reasonably well (except GPS which doesn't)
- AC radios (ath10k) do have an extra CPU running separate wireless firmware, perhaps that firmware could be modified to help TDMA on these radios

I've been running mostly UBNT M5 radios so far, but as 5GHz is getting crowded (too many competitors in the area), and UBNT are getting too paranoid about regulatory issues (limiting channels, forcing DFS etc.), so I decided to give MT AC a try for the new licensed 6GHz channels I've just got. And now I'm not convinced it was a good idea - MT, please prove me wrong by improving TDMA on AC radios.