MikroTik

Posted: **Thu Dec 20, 2018 5:30 pm**

In ptp -58-58 lhg arm ac without interferences i only have 80-90mb in nstreme. In 802.11 lost a lot of packet and in nv2.... 20-30 mb but irregular.

Posted: **Thu Dec 20, 2018 5:59 pm**

I have partially to correct myself: the last firmware still miss the slot but now it works a little bit better but 30% slower than old AC hardware

And that's the progress

New AC - worse than old

Posted: **Fri Dec 21, 2018 6:10 am**

Greetings.

LHGac ARM

I have the same problem or worse, I show screenshots of a PtP link.

better 802.11 results, but on "occasions" there is packet loss during speed tests.

someone with the same problem?

Posted: **Fri Dec 21, 2018 9:07 pm**

There is no comment from Mikrotik so you have to life with that „features“

Posted: **Fri Dec 21, 2018 10:56 pm**

I have the packet problem Too same problem....

Posted: **Sat Dec 22, 2018 12:01 am**

I have the packet problem Too same problem....

ARM works only for pure 802.11 CPE only. No AP no Bridge no WDS no nstreme no NV2. Station & NAT now works fine. Don't try Queue too only hardware Queue.

Posted: **Sat Dec 22, 2018 3:53 am**

There is no comment from Mikrotik so you have to life with that „features“

I do not want to live with that, I will return it to my supplier for warranty

Posted: **Sat Dec 22, 2018 6:24 am**

There is no comment from Mikrotik so you have to life with that „features“
I do not want to live with that, I will return it to my supplier for warranty

That is what we have done.....
We build new Tower not with Mikrotik, there is no Business Case, 12 Month and no solution!

Posted: **Tue Dec 25, 2018 11:20 am**

It is Christmas day... No arm fix no Ros 7. Please @Mikrotik... One more time said us if they have plain solve the problem and when. Wisp need solutions no problem. Change hardware is Too espensive and waste of time... Its Too dificult for us this situation and more dificult our silence...

Posted: **Tue Dec 25, 2018 12:02 pm**

It is Christmas day... No arm fix no Ros 7. Please @Mikrotik... One more time said us if they have plain solve the problem and when. Wisp need solutions no problem. Change hardware is Too espensive and waste of time... Its Too dificult for us this situation and more dificult our silence...

Build new towers with another vendor......
Rebuild smal towers with new stuff and pick up the clients for another towers, this is how we doing......

We are don’t believing in any solution from Mikrotik

Clients from another vendors are more expensive but, we are able to sell 100 and 200MBit plans, that is not possible with Mikrotik

If I think back the changeover time begins after missing Spectral scan, we know yet, that we had waisted time by waiting for MT is changing something.....

Posted: **Thu Dec 27, 2018 3:32 am**

It is Christmas day... No arm fix no Ros 7. Please @Mikrotik... One more time said us if they have plain solve the problem and when. Wisp need solutions no problem. Change hardware is Too espensive and waste of time... Its Too dificult for us this situation and more dificult our silence...
Build new towers with another vendor......
Rebuild smal towers with new stuff and pick up the clients for another towers, this is how we doing......

We are don’t believing in any solution from Mikrotik

Clients from another vendors are more expensive but, we are able to sell 100 and 200MBit plans, that is not possible with Mikrotik

If I think back the changeover time begins after missing Spectral scan, we know yet, that we had waisted time by waiting for MT is changing something.....

100-200MBit in the air? only with Cambium or Mimosa maybe... what you using?

Posted: **Thu Dec 27, 2018 5:58 am**

It is Christmas day... No arm fix no Ros 7. Please @Mikrotik... One more time said us if they have plain solve the problem and when. Wisp need solutions no problem. Change hardware is Too espensive and waste of time... Its Too dificult for us this situation and more dificult our silence...
Build new towers with another vendor......
Rebuild smal towers with new stuff and pick up the clients for another towers, this is how we doing......

We are don’t believing in any solution from Mikrotik

Clients from another vendors are more expensive but, we are able to sell 100 and 200MBit plans, that is not possible with Mikrotik

If I think back the changeover time begins after missing Spectral scan, we know yet, that we had waisted time by waiting for MT is changing something.....
100-200MBit in the air? only with Cambium or Mimosa maybe... what you using?

AP: Mimosa A5c + RF Element Horns
Client: C5 in future we will try C5x

Posted: **Thu Dec 27, 2018 11:06 pm**

No reply @mikrotik with loss packet in 802.11?

Posted: **Thu Dec 27, 2018 11:12 pm**

No reply @mikrotik with loss packet in 802.11?

Yes you are right. Unfortunately, Mikrotik does not comment these problems

Posted: **Thu Dec 27, 2018 11:37 pm**

Why don't request @mikrotik? I am sure ypu read this post....

Posted: **Thu Dec 27, 2018 11:40 pm**

Why don't request @mikrotik? I am sure ypu read this post....

They don’t need to answer , people’s buying this beta shit every day.....

Posted: **Thu Dec 27, 2018 11:49 pm**

No Mistry mikrotik loss a lot of clients...

Posted: **Fri Dec 28, 2018 12:39 am**

No Mistry mikrotik loss a lot of clients...

Not enough, otherwise it would be fixed long time ago

Posted: **Mon Dec 31, 2018 12:43 pm**

Last day in 2018.
Let's do a little summary - the problem is here with us since 2017 (first LHG5ac with 6.40.2) and by the end of 2018 has been NOT resolved.
Mikrotik does not communicate, does not solve...

Do you think we can expect the problem to be repaired in 2019?

Posted: **Mon Dec 31, 2018 1:13 pm**

Maybe with new drivers in V7 but the main question is when V7 'll be released?

Posted: **Mon Dec 31, 2018 1:30 pm**

Maybe with new drivers in V7 but the main question is when V7 'll be released?

Maybe in 2019, but they don’t care, so we don’t care too, we has to grow, and did exchange on some Places with great success, we don’t need Mikrotik anymore....

Posted: **Mon Dec 31, 2018 3:54 pm**

If mikrotik dont solve quickly the problem. 2019 will be last mikrotik year...

Posted: **Tue Jan 01, 2019 6:20 am**

I see they are hiring an RF engineer.... Maybe they don't even have employees who know how to fix it

Posted: **Tue Jan 01, 2019 3:47 pm**

Easy, very easy don´t buy unfixed product. Buy mipsbe thats works fine

Posted: **Tue Jan 01, 2019 5:35 pm**

Easy, very easy don´t buy unfixed product. Buy mipsbe thats works fine

There are no mispbe ac CPE‘s available they are all legacy
A serious manufacturer had stopped ARM Hardware with issues and delivers the old working hardware to coustomers

Posted: **Sat Jan 05, 2019 4:25 pm**

Mikrotik should be sell ac mipsbe product until solve the problem.

Posted: **Sat Jan 05, 2019 4:56 pm**

From support:

Hello,

Apologies for the inconvenience, this issue is being investigated by our development team and should be fixed in the upcoming releases of the RouterOS.

Best regards,

Posted: **Sat Jan 05, 2019 5:06 pm**

From support:

Hello,

Apologies for the inconvenience, this issue is being investigated by our development team and should be fixed in the upcoming releases of the RouterOS.

Best regards,

i´ve got this mail in march 18 some days before mum Berlin..... and until now nothing

Posted: **Sat Jan 05, 2019 5:17 pm**

I have dame message Too...

Posted: **Sat Jan 05, 2019 9:40 pm**

it's an hardware bug and it can't be resolved

Posted: **Sat Jan 05, 2019 10:11 pm**

it's an hardware bug and it can't be resolved

possible, we cannot control it, no other vendor in WISP business has ARM and TDMA.....
BUT IF IT HARDWARE, WHY THEY DON´T SELL THE OLD STUFF......

Posted: **Sat Jan 05, 2019 10:30 pm**

please @Mikrotik request us this situación it`s Too dificult for us and our coustomers....

Posted: **Sat Jan 05, 2019 10:41 pm**

it's an hardware bug and it can't be resolved
possible, we cannot control it, no other vendor in WISP business has ARM and TDMA.....
BUT IF IT HARDWARE, WHY THEY DON´T SELL THE OLD STUFF......

Cambium have ARM epmp-force-300-25 They must disable 3 cores & use only ONE CORE at this moment but works very good.

Posted: **Sun Jan 06, 2019 10:28 pm**

it's an hardware bug and it can't be resolved
possible, we cannot control it, no other vendor in WISP business has ARM and TDMA.....
BUT IF IT HARDWARE, WHY THEY DON´T SELL THE OLD STUFF......
Cambium have ARM epmp-force-300-25 They must disable 3 cores & use only ONE CORE at this moment but works very good.

But if this is a solution, then why we haven’t Ros doing the same?

Posted: **Sun Jan 06, 2019 11:25 pm**

I Hope arm solution every day...

Posted: **Sun Jan 06, 2019 11:46 pm**

I Hope arm solution every day...

We have a lot of Mikrotik CPE out there, but in last 6 month we realized how competitors are able to deliver higher speeds, Mikrotik is outdated, I don’t believe that we came back to Mikrotik

Posted: **Mon Jan 07, 2019 3:27 pm**

New firmware, same problem

Posted: **Mon Jan 07, 2019 3:38 pm**

New firmware, same problem

Wait for Christmas.....

Posted: **Mon Jan 07, 2019 4:00 pm**

We have a lot of Mikrotik CPE out there, but in last 6 month we realized how competitors are able to deliver higher speeds, Mikrotik is outdated, I don’t believe that we came back to Mikrotik

Deliver higher speed using how much bandwidth (80-160MHz?)

Posted: **Mon Jan 07, 2019 4:06 pm**

one more time.... please mikrotik, normis chupaka... request us

Posted: **Mon Jan 07, 2019 4:29 pm**

We have a lot of Mikrotik CPE out there, but in last 6 month we realized how competitors are able to deliver higher speeds, Mikrotik is outdated, I don’t believe that we came back to Mikrotik
Deliver higher speed using how much bandwidth (80-160MHz?)

No, try 280MBIt TCP with Mikrotik @40mhz

Posted: **Mon Jan 07, 2019 5:53 pm**

What I meant to say was - for other competitors to deliver higher speeds (exclude full duplex) are they using 80-160Mhz bandwidth per AP channel ?

Posted: **Mon Jan 07, 2019 7:37 pm**

What I meant to say was - for other competitors to deliver higher speeds (exclude full duplex) are they using 80-160Mhz bandwidth per AP channel ?

No they don’t use MT for Wireless

Posted: **Tue Jan 08, 2019 5:07 pm**

6.44.50 and 6.44.54 destroy mi ptp with arm

Posted: **Tue Jan 08, 2019 5:30 pm**

please tell me why did you say that? which protocol you are using.

Posted: **Tue Jan 08, 2019 5:31 pm**

Protocolo is not important all protocols fail Lost packet, slow speed, strange problems...

Posted: **Tue Jan 08, 2019 8:48 pm**

Protocolo is not important all protocols fail Lost packet, slow speed, strange problems...

ARM to ARM = fail. Change AP side use MIPSBE like NETMETAL & use only pure 802.11 not NV2 / NSTREME.
In my opinion ARM should not be sold, this is the beta version of the product or alpha.

Posted: **Tue Jan 08, 2019 11:21 pm**

we should return to mikrotik all the arm and be exchanged ... what do you think?

I hate this situacion, my clients dont stop to call me... I had to change a lot of equipment

Posted: **Tue Jan 08, 2019 11:36 pm**

we should return to mikrotik all the arm and be exchanged ... what do you think?

I hate this situacion, my clients dont stop to call me... I had to change a lot of equipment

We did not deploy much of them, and after our stock with Mispbe is empty we changed brandm

They don’t care, why we should care?

Posted: **Wed Jan 09, 2019 2:18 am**

not sure if this shows up but this will solve my problem

Posted: **Wed Jan 09, 2019 3:49 am**

what are the models and how much are they?

Posted: **Wed Jan 09, 2019 7:07 am**

what are the models and how much are they?

B5 and B5c are PTP Radios

B5 has integrated Antenna and B5c is connector based

https://mimosa.co/products/specs/b5

Posted: **Wed Jan 09, 2019 8:43 am**

Hi guys. Yes wireless situation is annoying. But this is still a MT forum. This should not be used to praise other vendors. So please consider removing your posts with foreign gear.

Something to consider:
MT is great with routers.
MT is great with their new 3xx line switches
LHG60 is great
802.11ax may change things

Posted: **Wed Jan 09, 2019 9:12 am**

mikrotik has caused me many problems and does not solve them. some things work well but many do not. We have lost a lot of time and money because of the mikrotik arm. If mikrotik does not want to solve the problem we have the right to look for arternatives. In my country it is considered scam to sell products that do not work. Also mikrotik does not respond to problems.

Posted: **Wed Jan 09, 2019 9:43 am**

not sure if this shows up but this will solve my problem

Much better but 10 x expensive than ubnt or mt

This is not a solution in this point. You have not mount this for customer...

B5 is the best for PtP link, 1Gbps full duplex.

The same will do AF5xHD and will cheaper with antennas x2

Posted: **Wed Jan 09, 2019 10:41 am**

mikrotik has caused me many problems and does not solve them. some things work well but many do not. We have lost a lot of time and money because of the mikrotik arm. If mikrotik does not want to solve the problem we have the right to look for arternatives. In my country it is considered scam to sell products that do not work. Also mikrotik does not respond to problems.

Everyone always has the free decision to buy anything. If a product does not work as *advertised* just give it back.

If you loose money using a product which is not developed further and does not work great ... it is your business decision. If you expect help from a vendor using his products this is your right. But a vendor is not committed to do this. Buy a cisco and call them for help. You will end up at sales offering you an expensive contract. If you want updates you need a contract.

So dont whine. Order equipment from a different vendor, test it and use it.

This nv2 situation is for so long now. Everybody whining *now* likes to whine or does not understand how to do his job. As you see this thread is still here and everybody is able to read and see the limitations.

Despite all of this: This is still a MT forum and not the presentation place for other vendors equipment. Just follow the board rules.

Posted: **Wed Jan 09, 2019 10:52 am**

802.11ax may change things

802.11ax is useless without Software revolution, but with the delay they have had for AC, we would probably see AX in 2021, ROS 7 could be available.....

Why not discuss alternative? They don’t answer anything, so I think they don’t need to sell 802.11 Hardware anymore, and that is what I said more then 18 month ago, they did decide do only low cost Outdoor Wireless, and don’t invest time in Development.

Mikrotik is more going for routing, switching, Fiber not for wireless.
But doing such decision without telling customers is more than contempt

Posted: **Wed Jan 09, 2019 11:23 am**

802.11ax may change things
802.11ax is useless without Software revolution, but with the delay they have had for AC, we would probably see AX in 2021, ROS 7 could be available.....

Mikrotik despite doing not enough for nv2 was the first wisp vendor offering an .ac product. Problem with .ac and tdma protocols is that the common cpus are to weak. Vendors who offer better .ac experience for wisps do this by making HW modifications or complete other chipsets. MT uses what their favorite chipset vendors are offering. 802.11ax will have some stuff integrated into the chipset which will help wisps. So this might change things a bit. And as you see with 60GHz. Where are your favorite vendors there.

Why not discuss alternative? They don’t answer anything, so I think they don’t need to sell 802.11 Hardware anymore, and that is what I said more then 18 month ago, they did decide do only low cost Outdoor Wireless, and don’t invest time in Development.

Because it is a MT forum? Think of your users talking on your forum where to shop else.

Mikrotik is more going for routing, switching, Fiber not for wireless.
But doing such decision without telling customers is more than contempt

This is not the truth. Look at LHG60. And there is still place for MT 5GHz where it does not need to scale. Hardware is very reliable. And SW features are very good.

Posted: **Wed Jan 09, 2019 11:33 am**

we need a day and hour that magical sw that all solution STE

Posted: **Wed Jan 09, 2019 3:50 pm**

Mikrotik again sell beta / alpha products & promised to solve the problem fast. They lie again & play on time. Now after months can't send back because have only 14 days in my country for this. The only way to defend a good name is to fix it. No fix = no buy & black PR from me.

The first big lie and time game from mikrotik is the first generation of AC:
1)Still unstable if use IP firewall & priorities for WMM pure 802.11 (watch dog reboot sometimes)
2)Still NV2 works worse than older generation for 802.11N mode not AC !
3)Still no Spectral scan....

Better sell old good hardware like Cambium.
802.11N from mikrotik & NV2 works great & beast Vs noise from another networks.

Posted: **Wed Jan 09, 2019 5:08 pm**

One more time no answer

Posted: **Wed Jan 09, 2019 6:02 pm**

This is the end lalala (cit. Doors)

Posted: **Wed Jan 09, 2019 6:51 pm**

Today I wrote for support that we ask their expression here on the forum

Posted: **Wed Jan 09, 2019 8:01 pm**

If mikrotik request please honzam tell us.

Posted: **Thu Jan 10, 2019 6:37 pm**

*) wireless - improved signal strength at low TX power on LHG 5 ac, LHG 5 ac XL and LDF 5 ac ("/system routerboard upgrade" required);
*) wireless - improved system stability for all ARM devices with wireless;

who has tested?

Posted: **Thu Jan 10, 2019 8:01 pm**

I try. It is fake...

Posted: **Thu Jan 10, 2019 10:46 pm**

Are you sure?

Posted: **Fri Jan 11, 2019 12:25 am**

I actually bought a couple LHG60 ( claim: The LHG60 can do 1Gbps full duplex actual throughput (both directions 1Gbps at the same time) but only for shorter runs, like under 2KM. ) despite already having bad exp with LHG 5ac. So, Yeah as much as I can get I would like mikrotik but if Mikrotik will have issues it is unavoidable ( if it is not allowed please point me if there is any and I will gladly remove my post ) to discuss alternative products to replace the ones having issues.

Posted: **Fri Jan 11, 2019 1:22 pm**

Are you sure?

Unfortunately, it is the truth. Also tested it on the LHG5 AC

Posted: **Fri Jan 11, 2019 4:56 pm**

The worst is mikrotik silent

Posted: **Sat Jan 12, 2019 10:35 am**

@Mikrotik does not solve the problem. Maybe it's time to try alternative software. Has anyone tried with other software?

Posted: **Sat Jan 12, 2019 10:38 am**

@Mikrotik does not solve the problem. Maybe it's time to try alternative software. Has anyone tried with other software?

For ARM Hardware there is nothing.....
https://openwrt.tetaneutral.net/release ... x/generic/

Posted: **Sat Jan 12, 2019 4:26 pm**

Maybe we should pay open wrt to create arm software. Mikrotik won't solve the problem

Posted: **Sat Jan 12, 2019 4:46 pm**

Maybe we should pay open wrt to create arm software. Mikrotik won't solve the problem

Better buy new Hardware, and throw this low cost electronics away

Posted: **Sat Jan 12, 2019 11:47 pm**

I think we should Will Be find a solution. We are better to mikrotik. We are very strong. We are the alternative to Big companies. We are democraticed internet. We are the future. If mikrotik can't solve this problem, we can solve it

Posted: **Sun Jan 13, 2019 3:51 am**

Had the misfortune of buying some disclite5 AC units . Replaced deliberant APC units. Worst wireless choice I've ever made. 52db snr, endless dropouts.
Wish I had read this thread b4 buying.
I'm putting these units back in their boxes once the ubnt gear arrives tomorrow.
Stick to making routers mikrotik your arm radio gear isn't fit for sale.

Posted: **Mon Jan 14, 2019 12:34 am**

I think we should Will Be find a solution. We are better to mikrotik. We are very strong. We are the alternative to Big companies. We are democraticed internet. We are the future. If mikrotik can't solve this problem, we can solve it

Unless it is a hardware limitation.

Posted: **Tue Jan 15, 2019 5:09 pm**

At the end on Monday Im going to remove all my arm hardware it's too dificult for me and Too expensive but it's the solution. Bye Mikrotik see you in the hell...

Posted: **Tue Jan 15, 2019 5:26 pm**

At the end on Monday Im going to remove all my arm hardware it's too dificult for me and Too expensive but it's the solution. Bye Mikrotik see you in the hell...

Dramatic. Phrasing on forums is realy dumb. Go to your local bakery and if they have old bread. Turn to the salesman and wish him to go to hell.
You kids are real world persons, are you ???

Posted: **Tue Jan 15, 2019 5:33 pm**

Dramatic is how know that you have an unfix product you sale this product and generaté a Big damage in operator and clients. And the most dramatic is that you don't fix the problem in one year and still sale the product. Bakeries, supermarket and another shops don't sale bad product and if the sale bad product goberment punish them.

Posted: **Tue Jan 15, 2019 5:43 pm**

if the sale bad product goberment punish them.

Pure quality stuff right here

Posted: **Tue Jan 15, 2019 5:57 pm**

At the end on Monday Im going to remove all my arm hardware it's too dificult for me and Too expensive but it's the solution. Bye Mikrotik see you in the hell...

You made that promise earlier, why are you still here?

viewtopic.php?f=7&t=136002&p=693764#p693764

Five years working with @Mikrotik ... Today is the last day. It´s a pitty...

Posted: **Tue Jan 15, 2019 6:01 pm**

This was the last day that i buy mikrotik product. I wait that they solve the problem. And them i need change my arm equipment

Posted: **Wed Jan 16, 2019 12:54 am**

wow, I am in the customer service industry and even how irate the customer is, we were trained not to tell them to look for a solution elsewhere or tell them to do good on their threat...

I was expecting response to mfr476 would be:

Hi mfr476,

We apologize that the product is giving you such a headache. We understand your pain and currently we have our top techs on it. This issue has been escalated to our highest level. We already assigned 80% of our engineers to work on the issue.. Unfortunately, we are still looking for solutions. We currently are having issues with 1. ex. 2. ex 3. ex.. and If we still can't find a solution in another month we will be asking assistance from ________ ( a more exp company or engineer ) to solve the problem.

An update every now and then would be nice as it gives your customer a sense that you are indeed are working on the issue but is facing some roadblocks.

But that's just me.

Posted: **Wed Jan 16, 2019 1:29 pm**

Seems to be company policy to not answer difficult topics and to play dead.
Potential customers are being replied to with product proposals, but whoever already bought is left behind.

Posted: **Wed Jan 16, 2019 1:33 pm**

This is not a support forum. Even though I do work at MikroTik, officially this is a user forum, and I also mostly write my personal opinion, not MikroTik opinion.
Please contact MikroTik through official channels if you would like to get "customer support".

MikroTik is well aware of Nv2 issues with ARM devices, but they are not easy to solve, because new chipsets are fundamentally different and Nv2 was made in times when there were different chipsets, different wireless standards, and different requirements*. It's not clear yet, if the issues can be resolved, or when they can be resolved. MikroTik is still working on this issue.

--
* see also: viewtopic.php?f=1&t=43612&p=219271&hilit=Nv2#p219271

Posted: **Wed Jan 16, 2019 2:55 pm**

This is not a support forum. Even though I do work at MikroTik, officially this is a user forum, and I also mostly write my personal opinion, not MikroTik opinion.
Please contact MikroTik through official channels if you would like to get "customer support".

MikroTik is well aware of Nv2 issues with ARM devices, but they are not easy to solve, because new chipsets are fundamentally different and Nv2 was made in times when there were different chipsets, different wireless standards, and different requirements*. It's not clear yet, if the issues can be resolved, or when they can be resolved. MikroTik is still working on this issue.

Normis, thanks for reply. It started to look like you have been banned from commenting on this problem.
Yes, we can write for support but we will not know anything about this problem. Your (Mikrotik support) answer was that it will be soon resolved. Nobody responds to other my emails ... Problem still unresolved

If this problem is unsolvable (difficult to solve) you should have reported that all AC devices (ARM) do not support NV2. We would not buy them and did not solve it.
You solve this problem from 2017 and no result !!
Mark

Posted: **Wed Jan 16, 2019 3:20 pm**

why mikrotik still buy arm if mikrotik know problem?

Posted: **Wed Jan 16, 2019 3:37 pm**

Modern protocols are adequate and work really well without Nv2.
Nv2 is only needed if you have large legacy networks and need to add more devices to them.

The simple answer is that Nv2 is an old solution to an old problem, but modern CPUs are not compatible with it and don't really need it. We keep improving Nv2 for ARM, but there is only so much that can be done realistically. New versions are already better than it was.

Posted: **Wed Jan 16, 2019 3:43 pm**

Modern protocols are adequate and work really well without Nv2.
Nv2 is only needed if you have large legacy networks and need to add more devices to them.

The simple answer is that Nv2 is an old solution to an old problem, but modern CPUs are not compatible with it and don't really need it. We need to make Nv3 or something else, because software fixes will not be 100% enough. We keep improving Nv2 for ARM, but there is only so much that can be done realistically. New versions are already better than it was.

Hi normis,

we all know about this, but why Mikrotik is stop selling SXTac Lite5, this device works in old networks.
We have much places where we are not able to deliver proper Service with 802.11 (Data + Voip)
we need a TDMA based System.

Will we see NV3?

Posted: **Wed Jan 16, 2019 4:02 pm**

There are many reasons why older models can't be made anymore, and why new models have other types of chips, I can't go into that detail.

Posted: **Wed Jan 16, 2019 4:48 pm**

When works fine 802.11 with ap mipsbe and cpe arm?

Posted: **Wed Jan 16, 2019 6:05 pm**

There are many reasons why older models can't be made anymore, and why new models have other types of chips, I can't go into that detail.
There are other ways to resolve this, but they need new hardware.

For now you can use any outdoor devices with 802.11n (non AC), they are MIPS, for example LHG, LDF, SXT Lite series, SXTsq Lite series, Disc, Groove, Omnitik etc.

May be you could give some hope by talking on 802.11ax. As there are chipsets available I guess there is something in your labs.

Posted: **Wed Jan 16, 2019 6:09 pm**

There are many reasons why older models can't be made anymore, and why new models have other types of chips, I can't go into that detail.
There are other ways to resolve this, but they need new hardware.

For now you can use any outdoor devices with 802.11n (non AC), they are MIPS, for example LHG, LDF, SXT Lite series, SXTsq Lite series, Disc, Groove, Omnitik etc.
May be you could give some hope by talking on 802.11ax. As there are chipsets available I guess there is something in your labs.

We need solutions fast not hope & future promes.

Posted: **Wed Jan 16, 2019 6:21 pm**

Modern protocols are adequate and work really well without Nv2.
Nv2 is only needed if you have large legacy networks and need to add more devices to them.

The simple answer is that Nv2 is an old solution to an old problem, but modern CPUs are not compatible with it and don't really need it. We need to make Nv3 or something else, because software fixes will not be 100% enough. We keep improving Nv2 for ARM, but there is only so much that can be done realistically. New versions are already better than it was.

Hehe, that took some time (a year?) to finally get a clear say about this.

Even with all my previous posts and tests last year showing NV2 was outperformed by plain 802.11 (and nstreme) if properly configured still this words where never used....

Suggestion: Write a comment in the wireless wiki that in heavy congested, dense populated P2MP network it is best to use 802.11?
(And by the way, I don't see so much difference between misbe or arm units. Even the DiscLite 5Ghz ac unit delivers my 30Mbps package date to the client.)
Just done some test with an 7 client P2MP AP that has overlapping 40Mhz channel with other AP and could push an LHG-5ac together with a DISC-5ac to both some 40-45Mbps, each on its own easy to 100Mbps.
Done the same test with 80Mhz channel (overlapping 3 other AP's) and could both have running some 70-80 each or as a single user could get 180-190Mbps on both...
Total throughput over the AP (Netmetal with RF-elements horn) was some 130Mbps max in 40Mhz but touching 200Mbps on 80Mhz channel....
Networks are in full 'ac' mode. nstreme is almost the same. NV2 sucks... not even half the speeds..... no matter what config I try....

For now good enough for my 30 and 50Mb packages.

I have to admit some of my AP's won't do as good as this one. It's a complicate puzzle to get the best results and signals can only be -60/-65 at its worse. Aim is -50 and preferred is below that.....
(Where I used to have 70% SXT's in my network, most of these are replaced now either by DISC-ac or LHG-ac. 2 years ago -60 was good enough, -70 workable, -80 the limit.....

Posted: **Wed Jan 16, 2019 11:14 pm**

Please @Mikrotik we only need that arm works in one protocolo very well, only one...

Posted: **Thu Jan 17, 2019 12:59 am**

Please @Mikrotik we only need that arm works in one protocolo very well, only one...

Use csma + RTS/CTS and you're fine...

Posted: **Thu Jan 17, 2019 3:31 am**

I think these could easily been avoided all by indicated in the spec sheet:

Model:
xxxxxxx
Transfer speed via wireless link ( ideal condition )
802 - 400mbps both directions TCP
nv2 -100mbps both directions TCP
nsextreme - 120mbps both directions TCP

something like that. Then the customers would have an informed decision basing on the information given and there will be no threads like this as it would simply be dismissed as " Slower speeds are due to the protocol overhead or it was already indicated in the spec sheets "

Posted: **Thu Jan 17, 2019 9:33 am**

Please @Mikrotik we only need that arm works in one protocolo very well, only one...
Use csma + RTS/CTS and you're fine...

How can i use this with my equipment?

Posted: **Thu Jan 17, 2019 10:39 am**

Please @Mikrotik we only need that arm works in one protocolo very well, only one...
Use csma + RTS/CTS and you're fine...

1)NV2 802.11N +NV2 @ 20Mhz 100 mbit/s from sector 20 clients.
2)Pure 802.11N +rts/cts @20Mhz 90-20 mbit/s sometimes UPLOAD rates are falling to 6Mbps latency spikes. Some clients lose 90% packet loss (sector 20 clients)

NV2 works great for 20Mhz channel it does not scale correctly for 40/60/80Mhz. For good TCP/IP one session speed need rly good SNR from AP side (collocation problem).

More about RTS/CTS are here https://www.sciencedirect.com/science/a ... 0715000129

Posted: **Thu Jan 17, 2019 11:48 am**

..........................................
2)Pure 802.11N +rts/cts @20Mhz 90-20 mbit/s sometimes UPLOAD rates are falling to 6Mbps latency spikes. Some clients lose 90% packet loss (sector 20 clients)

NV2 works great for 20Mhz channel it does not scale correctly for 40/60/80Mhz. For good TCP/IP one session speed need rly good SNR from AP side (collocation problem).

More about RTS/CTS are here https://www.sciencedirect.com/science/a ... 0715000129

Very high packet loss means that the antenna has a big issue with interference, NV2 is much better at dealing with interference,
All of which would indicate that the performance/design of a antenna is more important that the wireless protocol used, especially when throughput is increased as any antenna
imperfections are magnified?

Posted: **Thu Jan 17, 2019 11:54 am**

I think these could easily been avoided all by indicated in the spec sheet:

Model:
xxxxxxx
Transfer speed via wireless link ( ideal condition )
802 - 400mbps both directions TCP
nv2 -100mbps both directions TCP
nsextreme - 120mbps both directions TCP

something like that. Then the customers would have an informed decision basing on the information given and there will be no threads like this as it would simply be dismissed as " Slower speeds are due to the protocol overhead or it was already indicated in the spec sheets "

Doing this would be a vendor promise which could not be guarateed.

Posted: **Thu Jan 17, 2019 12:21 pm**

@n21roadie no packet los because too much collisions from hide nodes UPLOAD rate fall at 6mbps for worse signal station. Clean spectrum RTS/CTS no help very much. Just try BT 1 tcp sesion from 20 nodes simultaneously for 802.11 +RTS/CTS @ change for NV2.
+big ACK problem for pure 802.11N/AC under heavy load & saturation, NV2 works much much better @20Mhz

Posted: **Thu Jan 17, 2019 3:04 pm**

So here we go again.. (good! The more discussion the better!

)

Package loss might be less in NV2, but imho when you have more then double the speed available that is not so much of an issue. The package simply gets resend (tcp) and that's it.

If I have a sector with 10, 20 or even 30+ clients associated, I still see relative little usage in general. No matter when I look, any AP that needs to deliver more then 30Mbps to its clients for a prolonged time is a rare event. Sometimes when a couple of clients open something at the same time I see a spike of 30-40Mbps, sometimes into 50...
So yes, running BT from 6 or more clients then NV2 will probably give each a better share with less package losses

But for the day to day practice it is good enough when a clients request gets handled by the highest possible speed to free the spectrum. When running csma with properly configure rts/cts I see for traffic to only 2 or 3 clients hardly any package losses. The new csma+rts/cts protocol in 'ac' works pretty fine.
I can run from two clients a BT test and both have 90-100Mbps to a server in the LAN that halves if both are tested at the same time. And 1/3 roughly when 3 tests.. But is still much more then the same tests in NV2.

To stay in pace with the competition offering 30 or 50Mbps packages we need to go with it and offer the same. (It's always "up to"). With NV2 I cannot offer that. Not even with an AP that has only 6 clients.... 30 is max. run a second and it collapse...
With csma I can run at least two at almost 50 at the same time. Meaning that if we install, or a single client runs a speedtest, we get what we sell... 30 or 50Mbps....
Off course not when 2 or 3 or more clients at the same time hit the same www.speedtest.net button! But when happens this?

We have a normal client base with facebook, skype, Whatsapp use and video cameras and IPTV/Netflix etc. and occasional downloads. In NV2 we get complaints from users they are not getting their speeds. They usually start to test when something already has gone wrong, like freezing picture of broken IPTV streams...
In csma we get no complaints (so far)
Even several IPTV streams over csma work fine. You'll see the characteristic traffic (high peaks of download followed by pauzes) from serveral clients at the same time and all have smooth HD TV over the csma AP. When the same happens with NV2 the network gets saturated much faster and the complaints follow...

(At 100Mbps air capacity in the csma P2MP network an IPTV stream can use short bursts of high speed traffic to fill its buffers. Leaving a lot of medium time free. When the capacity is half (NV2) then these bursts are half and thus take twice the time and thus halves the medium time for other traffic. Etc. etc. Maybe now there is a bit less package loss but that is well compensated by the double as high amount of data that can be transported.
Off course gamers and or a lot of VIOP need other approaches and NV2 might be better. But in hour network gamers (that need the best connection) are almost none existing. And Voip? Everybody uses Whatsapp and Skype and it seems people are used to be it not the same as a 'real' phone line. I at least hardly ever get complaints and when I make a call from my fiber backbone connected router to my mum in an other country that has fiber I still see no difference then with a client on my WISP network...)

Posted: **Fri Jan 18, 2019 12:57 am**

I think these could easily been avoided all by indicated in the spec sheet:

Model:
xxxxxxx
Transfer speed via wireless link ( ideal condition )
802 - 400mbps both directions TCP
nv2 -100mbps both directions TCP
nsextreme - 120mbps both directions TCP

something like that. Then the customers would have an informed decision basing on the information given and there will be no threads like this as it would simply be dismissed as " Slower speeds are due to the protocol overhead or it was already indicated in the spec sheets "
Doing this would be a vendor promise which could not be guarateed.

Thus, the disclaimer " ideal condition "

Posted: **Fri Jan 18, 2019 11:16 am**

New firmware any wireless referente... Any Tri It with wireless?

Posted: **Fri Jan 18, 2019 11:45 am**

New firmware any wireless referente... Any Tri It with wireless?

Please use google translate

Posted: **Fri Jan 18, 2019 11:55 am**

new firmware no reference to wireless. Has anyone tried if the arm improves?

Posted: **Fri Jan 18, 2019 4:03 pm**

@WirelessRudy

...When running csma with properly configure rts/cts I see for traffic to only 2 or 3 clients hardly any package losses. The new csma+rts/cts protocol in 'ac' works pretty fine.......

(1) Are you using just 802.11 and not Nstreme,
(2) Properly configured rts/cts - any examples you can give,
(3) new csma+rts/cts protocol - is it working good on "N".

Posted: **Fri Jan 18, 2019 4:38 pm**

how can I configure my ap in csma + rts / cts protocol?

Posted: **Sun Jan 20, 2019 3:09 pm**

@WirelessRudy
...When running csma with properly configure rts/cts I see for traffic to only 2 or 3 clients hardly any package losses. The new csma+rts/cts protocol in 'ac' works pretty fine.......
(1) Are you using just 802.11 and not Nstreme,
(2) Properly configured rts/cts - any examples you can give,
(3) new csma+rts/cts protocol - is it working good on "N".

1) I have every P2MP network prepared for all 3 protocols and each clients listens to the AP's frequency only. Then I try each of the protocol while running some BT test from 2-4 clients to see which give the best results. NV2 alsways looses... Most of the time 802.11 is the best but some of my AP's show nstreme slightly better. (I have protection management 'enabled' and sometimes see several clients flip because of that and then in nstreme mode its much better. So this AP goes to nstreme....)
2) rtx/cts has to be 'always on' and other wireless robustness 'on' (adaptive-noise-immunity=client-mode guard-interval=long hw-protection-mode=rts-cts hw-retries=5 hw-protection-threshold=0 preamble-mode=long )
3) For 'ac' standard the csma+rts/cts has been re-designed by the IEEE and has been improved. But I don't think that works in 'N' protocol working network. The new protocol is downwards compatible if the AP is 'ac' where the CPE is still 'legacy' 'n'. But off course this 'n' cpe cannot directly benefit from the improved 'ac' protocol. But in a pre-dominant 'ac' network with a occasional 'n' unit these last will benefit too since the rest of the network works better and thus more 'airtime' is available for the 'n' units.....

The Wiki explains exactly how the different protocols have to be set. And in Google you can find loads of information about what the improvements of 'ac' are compared to 'n'. Basically that was the reason I started to try 802.11 ac whic already gave me such good results with Mimosa. And I also tried is because NV2 usually really sucks.....

Posted: **Mon Jan 21, 2019 10:10 am**

I work better in nstream Too. I can't work in 802.11 because i use voip. The problem is poor capacity...

Posted: **Mon Jan 21, 2019 6:19 pm**

I work better in nstream Too. I can't work in 802.11 because i use voip. The problem is poor capacity...

"VOIP" as in real phonelines over IP? Or Skype, facetime, whatsapp, etc. etc. That's also voip and work fine over my 802.11 AP's...

But I'd presume these VOIP calls are relative rare occasions. And people probably are used to poor connections anyway, especial if they use it over their Wifi.
Real VOIP as replacement for a real fixed copper line is a bit more sensitive I'd agree.

I don't understand what you mean with

poor capacity

, as far as I can see its almost the same as 802.11 and basically double that of NV2..

Posted: **Tue Jan 22, 2019 3:43 pm**

My old N cpe mikrotik works faster than my new ac cpe.

Posted: **Tue Jan 22, 2019 4:11 pm**

Just for sure, speed is measured from CPE btest or via pc for cpe? According to my measurements in certain modes, the btest does not work well, especially for new arm processors or even a combination of arm - mips.

Posted: **Tue Jan 22, 2019 5:25 pm**

My old N cpe mikrotik works faster than my new ac cpe.

Mikrotik call this feature......

Posted: **Tue Jan 22, 2019 8:40 pm**

Hi, this is our scenary and proper experience...

We have a backbone with 5 towers in a 10° beam angle at around 3 to 8 km of distance from our main tower, all concentrated in a PTMP Dynadish (upgraded to Level 4 to work in AP-bridge mode)...

The setting for the best performance, througput, latency, etc is all in 5Ghz-Only-N, 20/40Mhz eC, NV2 with dynamic-downlink=75% and TDMA period size=4ms, SGI, Short Preamble, MCS12 max, Frame Life-time=4, Hw-Retries=5, Inmunity activated ("ap and client" in the dynadish, "client" in remotes sites), etc...

In peak time is around 120-140Mb of througput, stable and with good latency...

Tested in Nstreme the througput is similar, but have more packet loss and higher latency.

In 802.11 is a disaster... (yesterday i test again with the WirelessRudy recommendations and the same, nothing good)

Before the Dynadish we test a LHG XL 5ac (low-cost arm cpu) and was a disaster in NV2, Nstreme and 802.11...

Today our best MT combination is mipsbe, 802.11n and NV2...
Soon we think to change all the stations of the remote towers (SXTsq, LHG and LHG XL) to dynadish, to complete the 802.11ac mipsble solution...

Is something doing this PTMP scenary pure mipsbe in 802.11ac to share experience?

Regards,

Posted: **Wed Jan 23, 2019 1:34 am**

@Alessio Garavano; Can you explain your setup again? Don't understand how it is....

You have one main backbone AP that serves at 10° 5 Dynadish stations that in return feed a tower to feed clients?

Posted: **Wed Jan 23, 2019 6:03 am**

I have the same idea,but I want to use some stationbox cc xl 19 dbi with 922 card inside.The main reason is that the 90°,120° antennas make too much noise in my tower.The question,is it correct due to the very little opening angle?.

Posted: **Wed Jan 23, 2019 8:46 am**

I have the same idea,but I want to use some stationbox cc xl 19 dbi with 922 card inside.The main reason is that the 90°,120° antennas make too much noise in my tower.The question,is it correct due to the very little opening angle?.

Don’t buy Plastic Antennas like Dynadish, look for RF Elements Horns! Next benefit if you leave the Mikrotik train you only have to exchange the adapter + Elektronic, the Antenna could stay in place

Posted: **Wed Jan 23, 2019 10:51 am**

alejosalmon we use QRT as AP and it works great we shield it on the tower https://www.interprojekt.it/anti-noise- ... -1751.html so we don't have any problem with colocation

Posted: **Wed Jan 23, 2019 11:41 am**

alejosalmon we use QRT as AP and it works great we shield it on the tower https://www.interprojekt.it/anti-noise- ... -1751.html so we don't have any problem with colocation

QRT with 10 degree coverage as AP? You must have many of these as sector or all clients close together....?

Posted: **Wed Jan 23, 2019 11:44 am**

I have the same idea,but I want to use some stationbox cc xl 19 dbi with 922 card inside.The main reason is that the 90°,120° antennas make too much noise in my tower.The question,is it correct due to the very little opening angle?.
Don’t buy Plastic Antennas like Dynadish, look for RF Elements Horns! Next benefit if you leave the Mikrotik train you only have to exchange the adapter + Elektronic, the Antenna could stay in place

I never understood the purpose of Dynadish anyway. QRT is much better and cheaper. Dynadish has huge sidelobs so don't work well in colocation with other AP when frequencies are close.
Plus for QRT you can buy metal shield, always better for noise reduction then plastic dome from Dynadish.j

Posted: **Wed Jan 23, 2019 11:54 am**

alejosalmon we use QRT as AP and it works great we shield it on the tower https://www.interprojekt.it/anti-noise- ... -1751.html so we don't have any problem with colocation
QRT with 10 degree coverage as AP? You must have many of these as sector or all clients close together....?

Yes we have a lot of QRT on the tower you can use with an angle of 15° less interference and higher perfomance

Posted: **Wed Jan 23, 2019 2:21 pm**

alejosalmon we use QRT as AP and it works great we shield it on the tower https://www.interprojekt.it/anti-noise- ... -1751.html so we don't have any problem with colocation
QRT with 10 degree coverage as AP? You must have many of these as sector or all clients close together....?
Yes we have a lot of QRT on the tower you can use with an angle of 15° less interference and higher performance

Ok, we have one tower serving some 100+ clients with 8 sectors of different range. All RF-Elements apart from one that we have with a 10 degree 23dBi Mars antena with rb922.
All other AP's are Netmetals on RF-Elements. We have 3x30, 2x40, 2x60 degree and one 10 degree 23dBi Mars antena with rb922.
Some AP's have still a mix of 'n' and 'ac' protocol clients. SXT's or LHG's and some Sextants.
Some other AP's are already converted in 'full' 'AC' network with SXT-sq's (arm), SXT-ac (mipsbe), DISC (arm) and LHG-5ac (arm)
All working in 5Ghz band with 40Mhz channel width.

Same tower has 7 backhauls running from it all in the 5Ghz band (1x ubnt Airfibre5x) and in 20 to 50Mhz wide bands.

At 6 meters distance we have tower of competition with 3 x ubnt sector and 1 x Airfibre5 and one ubnt ac backhaul.
At 150 meters distance we have tower of other competition with 4 x ubnt sector and 2 x ubnt backhaul.

Plenty of noise in that area....

All my AP's working in either N/AC mode or full AC mode in 802.11 rts/cts mode.
Clients can get 50Mbps and last night I ran that speed from 3 clients on the same sector both in 'n' or 'ac' and there was almost a sustained 50Mbps to these clients. I also ran a ping to one of these clients and with 30ms average wity a max of 100ms and only an occasional package drop I think it runs pretty good.

I cannot see any difference between 'arm' or 'mipsbe' devices.
Any of the AP's that is set to NV2 gets half the capacity and half the speed to the client. I tried all possible configuration options to no avail, nstreme and 802.11 outperform NV2 by 100%

If I do a test between CPE and a CCR router behind the netmetal most client have 100+Mbsp of airspeed available. Two clients at the same time still see both getting some 60 or 70. With 3 it drops to around 50 and with 4 it falls back to 20-30 each. More then 2 simultaneous sees the station with the poorest conn. rate drop its speed first.
All signals are in the -35 to -60 range with an occasional -65. (My aim is -55 or better but try not stronger then -40 and worse then -60 is actually up for antena change (if possible).)

Posted: **Wed Jan 23, 2019 3:38 pm**

share configuration please

Posted: **Wed Jan 23, 2019 4:06 pm**

share configuration please

who?

Posted: **Wed Jan 23, 2019 7:14 pm**

WirelessRudy you say that you can't see any difference between arm devices and mipsbe ones,but there is a lots complaints about packet loss in that architecture by using 802.11,nv2,nstreme.Please tell us more about it.Thanks

Posted: **Wed Jan 23, 2019 8:02 pm**

WirelessRudy you say that you can't see any difference between arm devices and mipsbe ones,but there is a lots complaints about packet loss in that architecture by using 802.11,nv2,nstreme.Please tell us more about it.Thanks

Exactly! Because I don't see that difference I did mention it....

Just for the sake, I ran 2 bw tests; one initiated (download, 1 tcp stream) from a rb911Lite5 ac (mipsbe) and one same parameters from DISC Lit5 ac
Ap has 14 units associated and works in 20Ce/ac protocol (All associated units are 'ac')
Bandwith test runs through 2 wireless backhauls and 2 CCR's for mpls routing towards gateway (CCR) which has a queue for each of this client set to 50Mb burst and 33 regular (we sell 30Mb)
It is also near prime time and both backhauls transport traffic of some 300 clients....

From both I run the bw test.
The rb911 has a connection rate (download) of some 270Mbps with a CCQ regurlary touching 100%. Signal is -23 (way too much but ok, It at 150 meters distance, 30 meters below.)
The DISC has a connection rate (download) of some 243Mbps with a CCQ 60-85%. Signal is -54. (This units 'looks' through a tower with 5Ghz ubnt sectors and 2 backhauls at 250 meters and the client is a 3km)

The rb911 runs a relative stable 28Mbps download (25 mins)
The DISC runs a les stable but average 23Mbps download (same time)
The AP shows other traffic from other 12 clients and is continiously showng 50-80Mbps

Ping with 256 package size and 500ms timeout:
DISC shows 25ms average with 2% package loss out of 1000 packages now
RB911 shows 13ms average with 1% package loss out of 1000 packages...

The small difference at the expense of the DISC is due its weaker signal and lower CCQ (The signal path is 15 times longer and the noise must be horrendous going to shoot 'through' another 4 sector ubnt tower. I actually picked the worse client from this sector I now realize...)

So I think the DISC Lite5ac is working absolutely fine in this 802.11ac environment. (I had the bw test running for almost 30 minutes while writing this post.)

DISC

/interface wireless
set [ find default-name=wlan1 ] adaptive-noise-immunity=client-mode allow-sharedkey=no ampdu-priorities=0 amsdu-limit=8192 \
    amsdu-threshold=8192 antenna-gain=0 area="" arp=enabled arp-timeout=auto band=5ghz-n/ac basic-rates-a/g=6Mbps bridge-mode=enabled \
    channel-width=20/40/80mhz-XXXX compression=no country=no_country_set default-ap-tx-limit=0 default-authentication=no \
    default-client-tx-limit=0 default-forwarding=yes disable-running-check=no disabled=no disconnect-timeout=3s distance=dynamic \
    frame-lifetime=0 frequency=5180 frequency-mode=superchannel frequency-offset=0 guard-interval=any hide-ssid=no ht-basic-mcs=\
    mcs-0,mcs-1,mcs-2,mcs-3,mcs-4,mcs-5,mcs-6,mcs-7 ht-supported-mcs="mcs-0,mcs-1,mcs-2,mcs-3,mcs-4,mcs-5,mcs-6,mcs-7,mcs-8,mcs-9,mcs-\
    10,mcs-11,mcs-12,mcs-13,mcs-14,mcs-15,mcs-16,mcs-17,mcs-18,mcs-19,mcs-20,mcs-21,mcs-22,mcs-23" hw-fragmentation-threshold=\
    disabled hw-protection-mode=rts-cts hw-protection-threshold=0 hw-retries=5 installation=any interworking-profile=disabled \
    keepalive-frames=enabled l2mtu=1600 mac-address=B8:69:F4:89:1A:2E max-station-count=2007 mode=station mtu=1500 \
    multicast-buffering=enabled multicast-helper=default name=wlan1 nv2-cell-radius=30 nv2-downlink-ratio=50 nv2-mode=\
    dynamic-downlink nv2-preshared-key=erwtennet@MC nv2-qos=default nv2-queue-count=2 nv2-security=enabled nv2-sync-secret="" \
    on-fail-retry-time=100ms preamble-mode=long radio-name=C4e-109 rate-selection=advanced rate-set=default rx-chains=0,1 scan-list=\
    5615 secondary-channel="" security-profile=default ssid="" station-bridge-clone-mac=00:00:00:00:00:00 station-roaming=enabled \
    supported-rates-a/g=6Mbps,9Mbps,12Mbps,18Mbps,24Mbps,36Mbps,48Mbps,54Mbps tdma-period-size=2 tx-chains=0,1 tx-power-mode=default \
    update-stats-interval=disabled vht-basic-mcs=mcs0-7 vht-supported-mcs=mcs0-9,mcs0-9,mcs0-9 vlan-id=1 vlan-mode=no-tag \
    wds-cost-range=50-150 wds-default-bridge=none wds-default-cost=100 wds-ignore-ssid=no wds-mode=disabled wireless-protocol=any \
    wmm-support=enabled wps-mode=push-button

AP

/interface wireless
set [ find default-name=wlan1 ] adaptive-noise-immunity=ap-and-client-mode allow-sharedkey=no ampdu-priorities=0 amsdu-limit=8192 amsdu-threshold=8192 antenna-gain=0 area="" arp=enabled \
    arp-timeout=auto band=5ghz-onlyac basic-rates-a/g="" bridge-mode=enabled channel-width=20/40mhz-Ce compression=no country=no_country_set default-ap-tx-limit=0 default-authentication=no \
    default-client-tx-limit=0 default-forwarding=no disable-running-check=no disabled=no disconnect-timeout=3s distance=dynamic frame-lifetime=0 frequency=5615 frequency-mode=superchannel \
    frequency-offset=0 guard-interval=long hide-ssid=no ht-basic-mcs=mcs-6 ht-supported-mcs=mcs-6,mcs-11,mcs-12,mcs-13 hw-fragmentation-threshold=disabled hw-protection-mode=cts-to-self \
    hw-protection-threshold=0 hw-retries=7 installation=any interworking-profile=disabled keepalive-frames=enabled l2mtu=1600 mac-address=CC:2D:E0:FF:FF:68 max-station-count=2007 mode=ap-bridge \
    mtu=1500 multicast-buffering=enabled multicast-helper=default name=wlan1 nv2-cell-radius=10 nv2-downlink-ratio=80 nv2-mode=dynamic-downlink nv2-preshared-key=erwtennet@MC nv2-qos=default \
    nv2-queue-count=2 nv2-security=enabled nv2-sync-secret="" on-fail-retry-time=100ms preamble-mode=long radio-name=C4-AP5 rate-selection=advanced rate-set=configured rx-chains=0,1 scan-list=\
    5550-5700 secondary-channel="" security-profile=802.11 ssid=MaruCom-C4e station-bridge-clone-mac=00:00:00:00:00:00 station-roaming=enabled supported-rates-a/g=6Mbps tdma-period-size=auto \
    tx-chains=0,1 tx-power-mode=default update-stats-interval=disabled vht-basic-mcs=mcs0-7 vht-supported-mcs=mcs0-7,mcs0-7,mcs0-7 vlan-id=1 vlan-mode=no-tag wds-cost-range=50-150 \
    wds-default-bridge=none wds-default-cost=100 wds-ignore-ssid=no wds-mode=disabled wireless-protocol=802.11 wmm-support=enabled wps-mode=push-butto

n

Posted: **Wed Jan 23, 2019 10:09 pm**

Perfect.What version of routeros are you using in arm and mispbe cpes? Thanks for sharing with us your results.

Posted: **Wed Jan 23, 2019 10:47 pm**

We have dishes alu for LDF AC, LHG AC and others.

240Mbps stable on 80MHz? How many we can reach at 40MHz? 50Mbps?

Posted: **Wed Jan 23, 2019 11:24 pm**

Perfect.What version of routeros are you using in arm and mispbe cpes? Thanks for sharing with us your results.

6.43.8

Posted: **Wed Jan 23, 2019 11:25 pm**

We have dishes alu for LDF AC, LHG AC and others.

240Mbps stable on 80MHz? How many we can reach at 40MHz? 50Mbps?

If you get 240Mbps on 80MHz then you get half of that on 40Mhz....

Posted: **Wed Jan 23, 2019 11:32 pm**

Really? No way man, Ubnt AC 240-280Mbps on 40Mhz at 8km

Around 130Mbps at 20MHz...

Posted: **Thu Jan 24, 2019 11:04 am**

Really? No way man, Ubnt AC 240-280Mbps on 40Mhz at 8km Around 130Mbps at 20MHz...

I beleive 130 is roughly half of 240-280........

Posted: **Thu Jan 24, 2019 11:04 am**

Really? No way man, Ubnt AC 240-280Mbps on 40Mhz at 8km Around 130Mbps at 20MHz...

Mimosa too, but Mikrotik maxes out with 180-190 Mbit @ 40 Mhz

Posted: **Thu Jan 24, 2019 11:21 am**

Really? No way man, Ubnt AC 240-280Mbps on 40Mhz at 8km Around 130Mbps at 20MHz...
Mimosa too, but Mikrotik maxes out with 180-190 Mbit @ 40 Mhz

speeds are a factor of bandwidth, the amount of clients, protocol used, signals strength (=MCS rate) and package losses (=interference)

In lab without interference, good signals and only one client you get roughly 50% of the conn. rate as throughput speed. Minus overhead due protocol and other stuff 45-55% tcp is more realistic speed compared to the conn. rate.
The conn. rates more then doubles by doubling the channel bandwidth. Resulting in almost doubling the available tcp throughput.
If you get 100Mbps with 20Mhz then you get 200Mbps with 40, 400Mbps with 80Mhz etc.

Mikrotik only has one 750Mhz cpu where Mimosa works with 1,2Ghz I believe plus they have a better firmware. Also their antennas are better then the usually Mikrotik setups...
I would say Mikrotik theoretically can do some 70-80% of what Mimosa can do. But the more clients per AP the faster Mikrotik looses capacity compared to Mimosa.
(These are personal opinions. I have 4x Mimosa A5 with some 80 clients in a dense region working in 80Mhz band and in a wider area some 600 Mikrotik clients and some 40 AP's.
I also have one eCambium2000 setup with some 8 clients, some SXT elevate, some ubnt elevate and some eCambium stuff.. In other words, I can compare things a bit. Al tough not a situation is the same.)

Posted: **Thu Jan 24, 2019 4:01 pm**

@WirelessRudy, how would You compare effectiveness of Elevate vs original ROS (% of bndwdth/jitter) ?
And how would You compare 80mhz ptmp A5c vs mikrotik AC?
As my networki is rather old, I could say I'm building it since beginnig of Mtik adventure in this field, I've got a lot towers mikrotik only. Trying to keep it up to date, swapped
AP to OmnitiksAC that gave me rather headache than improvement so I wonder what steps should I take in face of nstreme/nv2 "development" process.
And Your experience in this area seems to be very interesting for me, so any answer would be very welcome.

Best regards

Posted: **Thu Jan 24, 2019 5:24 pm**

Ac is "mikrotik 10 year challenge"

Posted: **Thu Jan 24, 2019 6:49 pm**

@WirelessRudy, how would You compare effectiveness of Elevate vs original ROS (% of bndwdth/jitter) ?
And how would You compare 80mhz ptmp A5c vs mikrotik AC?
As my networki is rather old, I could say I'm building it since beginnig of Mtik adventure in this field, I've got a lot towers mikrotik only. Trying to keep it up to date, swapped
AP to OmnitiksAC that gave me rather headache than improvement so I wonder what steps should I take in face of nstreme/nv2 "development" process.
And Your experience in this area seems to be very interesting for me, so any answer would be very welcome.
Best regards

My network was 100% and is now some 80% based on Mikrotik. I started with Mikrotik in 2004 I believe. But since about 6 years ago started to look around and decided to try Mimosa in our neigbourhood that now has fiber as well. Only because I swapped to Mimosa and offer 50, 100 and 200Mbps package to my clients here for a little bit less then the fiber company charges I still have all my clients here. When we would have stayed with the crappy Mikroik NV2 from 2/3 years ago I'd probably had lost all my clients to fiber.....

Now it seems with the new line of 'ac' models with faster cpu and (slow-) improvements in ROS and I'd massively updating several of my P2MP networks into 'ac' I can start to offer 30 and 50Mbps in the countryside.

When it comes to "comparing" is my experiences and looking at the results between the different brands and way it's used.
Mimosa was from day one (3 years ago) 'ac' and their tdma is definately better then that of Mikrotik.

We also have one eCambium2000 with beamforming antenna (both 802.11'n') that we won in a raffle and we use with some 8 clients. Although I wouldn't have bought it for the investment it works good. Clients are just connected and have good speeds.
(So why not change into eCambium? Well, I have no money tree in my backgarden. Changing a P2MP network from one vendor into another is not only changing an AP, but also all clients... meaning a heavy extra investment that also needs a lot of time (only one installer) and during the swap you need to make sure clients still have a connection....)

Posted: **Fri Jan 25, 2019 2:14 am**

@WirelessRudy
thank You for reply

Do I got You right, that on 80mhz ptmp scenario You can supply clients with 200mbps?
ofcourse I do understand it's real world so overbooking is taken into account. But no complains from customers is enough , isn't it?

Posted: **Fri Jan 25, 2019 11:21 am**

@WirelessRudy
thank You for reply
Do I got You right, that on 80mhz ptmp scenario You can supply clients with 200mbps?
ofcourse I do understand it's real world so overbooking is taken into account. But no complains from customers is enough , isn't it?

With Mimosa I have no issue in reaching 200mbps for my clients. In Mikrotik I don't know. I only did a rough test the other day where the 80mhz band overlapped at least two other sectors on the same tower and could run 175Mbps at peaks from a LHG-5ac but maybe with more careful picking of a frequency and finetuning the network I could. But it's too much time consuming to make a perfect test environment.

Posted: **Fri Jan 25, 2019 12:06 pm**

Yes, I'm aware that You spoke about gears with handwritten lowercase "m" on cover.
Thanks again.
Live long and prosper.

Posted: **Tue Feb 05, 2019 3:51 pm**

From support:

Hello,
Unfortunately, our development team has been unsuccessful to fix the issue with ARM ac chips combined with nv2 yet. It is still being worked on, but perhaps a new TDMA protocol will be developed to support our new chip-sets, if the issue will not be resolved. Apologies for the inconvenience.

Posted: **Tue Feb 05, 2019 4:47 pm**

From support:

Hello,
Unfortunately, our development team has been unsuccessful to fix the issue with ARM ac chips combined with nv2 yet. It is still being worked on, but perhaps a new TDMA protocol will be developed to support our new chip-sets, if the issue will not be resolved. Apologies for the inconvenience.

With the same Timeline as ROS 7?
lol......

Posted: **Tue Feb 05, 2019 8:17 pm**

I changed all my mikrotik arm equipment for other brand and now I work fine. Arm problem would be solve in 2020.

Posted: **Tue Feb 05, 2019 9:25 pm**

It is a disgrace that in recent years Mikrotik on wireless cough, now is not done a spectral scan for AC !!!!
Shame
Still showing devices with ARM very poor transmission parameters with NV2, why long ago does not work on NV3 ????
Instead, new and new features are being made, but old things are coughing.
I'm crying.

Posted: **Tue Feb 05, 2019 9:36 pm**

It is a disgrace that in recent years Mikrotik on wireless cough, now is not done a spectral scan for AC !!!!
Shame
Still showing devices with ARM very poor transmission parameters with NV2, why long ago does not work on NV3 ????
Instead, new and new features are being made, but old things are coughing.
I'm crying.

There is enough working from other vendors on the market, buy that

Posted: **Wed Feb 06, 2019 12:39 am**

A sector with 15 clients a/n/40mhz and the one I've tested is old single core .ac.
Under each picture you can find the protocol used.
Sadly in 802.11 is not stable and clients gets a lot of disconnections so I'm sticking with nstreme.
The conclusion is Mikrotik have lost speed in any protocol, a lot.
Just for fun.

Posted: **Fri Feb 08, 2019 11:39 pm**

A sector with 15 clients a/n/40mhz and the one I've tested is old single core .ac.
Under each picture you can find the protocol used.
Sadly in 802.11 is not stable and clients gets a lot of disconnections so I'm sticking with nstreme.
The conclusion is Mikrotik have lost speed in any protocol, a lot.
Just for fun.

Are the pictures showing your bandwidth tests on 802.11, NV2 and Nstrem in that order?

Posted: **Sat Feb 09, 2019 5:44 pm**

A sector with 15 clients a/n/40mhz and the one I've tested is old single core .ac.
Under each picture you can find the protocol used.
Sadly in 802.11 is not stable and clients gets a lot of disconnections so I'm sticking with nstreme.
The conclusion is Mikrotik have lost speed in any protocol, a lot.
Just for fun.
Are the pictures showing your bandwidth tests on 802.11, NV2 and Nstrem in that order?

Posted: **Sat Feb 09, 2019 6:29 pm**

I remember when the fastest was nstreme, then NV2 and the worst was 802.11
Today it's exactly the opposite we not need

Posted: **Sat Feb 09, 2019 10:08 pm**

A sector with 15 clients a/n/40mhz and the one I've tested is old single core .ac.
Under each picture you can find the protocol used.
Sadly in 802.11 is not stable and clients gets a lot of disconnections so I'm sticking with nstreme.
The conclusion is Mikrotik have lost speed in any protocol, a lot.
Just for fun.
Are the pictures showing your bandwidth tests on 802.11, NV2 and Nstrem in that order?

Yes look at the image names

Posted: **Sat Feb 09, 2019 10:19 pm**

A sector with 15 clients a/n/40mhz and the one I've tested is old single core .ac.
Under each picture you can find the protocol used.
Sadly in 802.11 is not stable and clients gets a lot of disconnections so I'm sticking with nstreme.
The conclusion is Mikrotik have lost speed in any protocol, a lot.
Just for fun.

Don't know, by your picture it shows 802.11 is by far the best. And stable. Jitter is the same as the rest and jitter is a measurement of the variation in ping times.

I have now some 50% of my AP running on 802.11 and see a massive increase in speed of users connected. It actually doesn't matter if these clients are all 'n' or predominantly 'n' or all 'ac'.
Throughput is highest on 802.11. But nstreme follows close I must say.
I see no more disconnects in 802.11 then in NV2 or nstreme. But it depends a bit on th eAP. I have 2 AP's that actually see a better nstreme, but slightly. And one AP that gives best result in NV2. Don't know why.

I did a pingplotter test towards several client antenas and had that run for days. Only during times of heave overall usage (overall = all clients on the network) I see higher ping times. But independent of the protocol. But clients speeds are much higher, so those that watch IPTV get higher bursts and leave the network more free then in NV2.

No, the more I work with it and compare the more confidence I get in using 802.11ac as the main protocol for Mikrotik P2MP...

Posted: **Sun Feb 10, 2019 3:52 am**

A sector with 15 clients a/n/40mhz and the one I've tested is old single core .ac.
Under each picture you can find the protocol used.
Sadly in 802.11 is not stable and clients gets a lot of disconnections so I'm sticking with nstreme.
The conclusion is Mikrotik have lost speed in any protocol, a lot.
Just for fun.
Don't know, by your picture it shows 802.11 is by far the best. And stable. Jitter is the same as the rest and jitter is a measurement of the variation in ping times.

I have now some 50% of my AP running on 802.11 and see a massive increase in speed of users connected. It actually doesn't matter if these clients are all 'n' or predominantly 'n' or all 'ac'.
Throughput is highest on 802.11. But nstreme follows close I must say.
I see no more disconnects in 802.11 then in NV2 or nstreme. But it depends a bit on th eAP. I have 2 AP's that actually see a better nstreme, but slightly. And one AP that gives best result in NV2. Don't know why.

I did a pingplotter test towards several client antenas and had that run for days. Only during times of heave overall usage (overall = all clients on the network) I see higher ping times. But independent of the protocol. But clients speeds are much higher, so those that watch IPTV get higher bursts and leave the network more free then in NV2.

No, the more I work with it and compare the more confidence I get in using 802.11ac as the main protocol for Mikrotik P2MP...

That's exactly why I asked, since the statements was "Sadly in 802.11 is not stable and clients gets a lot of disconnections so I'm sticking with nstreme"
From my experience, as Ruby says, 802.11 with rts+cts works best with these ARM ac devices. They are somehow not working well on NV2.
In Nstreme they work well (very stable), but as nstreme protocol limits is reached at ~110-120Mbit it's mostly overcome with 802.11ac. So far, 802.11ac on ARM devices is the best choice. My opinion.

Posted: **Sun Feb 10, 2019 12:39 pm**

So far, 802.11ac on ARM devices is the best choice. My opinion.

My APs are mostly netmetal (mipsbe AC) and my CPEs are typically LHG XL (mipsbe N)
I use NV2 with dynamic downlink of 70/80% and 20Mhz channels

To be fair to Mikrotik, since the couple of changes they made in 2018 our bandwidth per sector shot up from 30-40mbits to 70-80mbits.
This is on par with what we are getting with UBNT AC PRISM APs with Litebeam AC stations, although with Mikrotik we are not having AC stations (this is sadly because of LHG AC problems with NV2!)

So NV2 is currently very happy with 10-20 N clients per netmetal sector on 20mhz channel and I (still) have the tower space AND spectrum to accommodate more as we grow. Yes AC with its denser modulations can add a bit more throughput, but I'm scared to start adding ARM AC CPEs to my network which a) will cross out nv2 as an option and b)may or may not cause me glitches and problems with the other wireless protocols, especially considering that will be combining three different chips (mipsbe, mipsbe-ac and arm-ac)

To conclude, for now our motto is: Better the devil you know than the devil you don't!

If Mikrotik release a NetMetal ARM which would work PERFECTLY with LHG XL AC and GOOD ENOUGH with N clients, that would give us a viable upgrade path for our networks.

Anyone from Mikrotik listening?

Posted: **Mon Feb 11, 2019 1:29 am**

So far, 802.11ac on ARM devices is the best choice. My opinion.
My APs are mostly netmetal (mipsbe AC) and my CPEs are typically LHG XL (mipsbe N)
I use NV2 with dynamic downlink of 70/80% and 20Mhz channels

To be fair to Mikrotik, since the couple of changes they made in 2018 our bandwidth per sector shot up from 30-40mbits to 70-80mbits.
This is on par with what we are getting with UBNT AC PRISM APs with Litebeam AC stations, although with Mikrotik we are not having AC stations (this is sadly because of LHG AC problems with NV2!)

So NV2 is currently very happy with 10-20 N clients per netmetal sector on 20mhz channel and I (still) have the tower space AND spectrum to accommodate more as we grow. Yes AC with its denser modulations can add a bit more throughput, but I'm scared to start adding ARM AC CPEs to my network which a) will cross out nv2 as an option and b)may or may not cause me glitches and problems with the other wireless protocols, especially considering that will be combining three different chips (mipsbe, mipsbe-ac and arm-ac)

To conclude, for now our motto is: Better the devil you know than the devil you don't!

If Mikrotik release a NetMetal ARM which would work PERFECTLY with LHG XL AC and GOOD ENOUGH with N clients, that would give us a viable upgrade path for our networks.

Anyone from Mikrotik listening?

Most of my AP's are Netmetals too. But I have one a Basebox 5 with only 'n' clients connected but even that one runs way better in 802.11'n'
Then I have several Omnitiks 5 ac (=mipsbe) with mainly arm devices connected but I see no differences between these mipsbe AP's as the NetMetals.
The only difference is the Omnitiks are working in what they are 360 degrees where the NetMetals all have RF-Element's horns as sectors.

I really see no differences between the different kind of chipsets. It's all about fine tuning and finding the proper frequencies.
And the good thing of 'ac' is you can work with 40Mhz or even 80Mhz where the 'secondairy channels can have some overlap with other AP's for some of the clients. These clients just avoid to use the overlapped channel while the rest of the network can still work with the full bandwidth.
I have now some of my AP's set to 80Mhz wide channels and although there is overlap with other remote AP's I see the speeds go up to the clients and by setting some lower MCS rate fixed I even get better CCQ!

But yeah, finetuning your P2MP is the hot word here. And one new AP or frequency shift from a competitor can throw all your hours of finetuning overboard .....

Posted: **Wed Feb 13, 2019 9:08 pm**

my provider has told me that there is no more ap with mipsbe. It is true? I have not bought anything for months and they call me worried. I recently changed all my arm for other manufacturer. I would like to know if mikrotik is going to solve the problem or I have to throw all the arm

Posted: **Wed Feb 13, 2019 9:25 pm**

But yeah, finetuning your P2MP is the hot word here. And one new AP or frequency shift from a competitor can throw all your hours of finetuning overboard .....

Yes its a never ending battle in p2mp. You are very lucky you can get good results on 80mhz. I don't have 80mhz of clean, contiguous spectrum in any direction (I define clean as not picking up other signals in the -80s or stronger). I very rarely get a better result on 40mhz than 20mhz! But even when I do I don't use it unless I really need the extra bandwidth, because it's more chance of fucking up (as per your original point!)

Posted: **Thu Feb 14, 2019 3:45 am**

But yeah, finetuning your P2MP is the hot word here. And one new AP or frequency shift from a competitor can throw all your hours of finetuning overboard .....
Yes its a never ending battle in p2mp. You are very lucky you can get good results on 80mhz. I don't have 80mhz of clean, contiguous spectrum in any direction (I define clean as not picking up other signals in the -80s or stronger). I very rarely get a better result on 40mhz than 20mhz! But even when I do I don't use it unless I really need the extra bandwidth, because it's more chance of fucking up (as per your original point!)

According your threshold my environment is not so much different. I have problems finding 40Mhz of 'clear' spectrum, let alone 80Mhz.
But you need to have a good knowledge of you physical environment and the location or your towers, your clients in respect to other towers and their sector antenas.
The good thing of 'ac' protocol is it has some sort of 'interference avoidance' system build in and with the combination of looking for relative high signal strengths. (I try to go for -40, -50 is acceptable, -55 just the limit and beyond that I am either looking for a bigger client antena or to find another solution....)

One of the 'nice' tools you can work with in 802.11 modus is that you can run a scan from both the client or the AP while the connection doesn't get lost.
On an AP looking for its best frequency it is not enough to look for free space '"at" the AP. You also need to know what the client's are been hammered at.
It can well be that where some canals only hit the AP with say -78 or -85 at the client the same 'alien' AP might come in with -50 or worse! So better look somewhere else or this client will see lots of problems. Do this for at least two of the clients spread over your working sector.
It's a lot of work and yeah, hence I work a lot in the middle of the night...
An AP takes several hours to do at times and I have some 40....... meaning that by the time I finished the last, I can start doing the first again.... a never ending battle...

Posted: **Thu Feb 14, 2019 3:48 am**

my provider has told me that there is no more ap with mipsbe. It is true? I have not bought anything for months and they call me worried. I recently changed all my arm for other manufacturer. I would like to know if mikrotik is going to solve the problem or I have to throw all the arm

All NetMetals, the preferred AP device, are still mipsbe and widely for sale...
https://mikrotik.com/products/group/wireless-systems

Why consider to ditch the arm devices? I have some 30% of these now in my network and have no more problems with these then the mipsbe devices..... and that is very little.

Posted: **Sat Feb 16, 2019 4:29 am**

Hello anyone has tried the new Version 6.44rc1 ?

*) wireless - improved system stability for all ARM devices with wireless;
*) wireless - improved system stability for all MIPSBE devices with 802.11ac wireless

Posted: **Sun Feb 17, 2019 10:09 am**

I changed my arm because my clients complained and threatened to report me. I only have two lhg ac in a lab ptp and with the latest firmware in 20 mhz these are the results= 50 mbs with ping 60-70...

Posted: **Tue Feb 19, 2019 7:53 pm**

Hello anyone has tried the new Version 6.44rc1 ?

Wait for RC2:
In the near future a new testing version will released (6.44rc2) that includes updates regarding nv2 issues with various software architectures.

Posted: **Tue Feb 19, 2019 9:16 pm**

Hello anyone has tried the new Version 6.44rc1 ?
Wait for RC2:
In the near future a new testing version will released (6.44rc2) that includes updates regarding nv2 issues with various software architectures.

The next rc will not have any new features next rc fixes only issues with current features

Posted: **Wed Feb 20, 2019 1:29 am**

I changed my arm because my clients complained and threatened to report me. I only have two lhg ac in a lab ptp and with the latest firmware in 20 mhz these are the results= 50 mbs with ping 60-70...

You are doing something wrong. I run higher (much higher) speeds in a P2MP environment with an AP associated with some 29 clients of different makes, all 'ac' in 802.11ac and can make up to 200Mb download over the AP to clients. Every single client reaches 150Mbps on its one, with 2 both get just over 100mbps, with 3 all three still have some 60Mbps... (80Mhz channel but with lots of overlap over other 5Ghz signal)

If your clients are to report you (for what?) then its because you don't know how to finetune your network.

Posted: **Wed Feb 20, 2019 8:44 am**

I changed my arm because my clients complained and threatened to report me. I only have two lhg ac in a lab ptp and with the latest firmware in 20 mhz these are the results= 50 mbs with ping 60-70...
You are doing something wrong. I run higher (much higher) speeds in a P2MP environment with an AP associated with some 29 clients of different makes, all 'ac' in 802.11ac and can make up to 200Mb download over the AP to clients. Every single client reaches 150Mbps on its one, with 2 both get just over 100mbps, with 3 all three still have some 60Mbps... (80Mhz channel but with lots of overlap over other 5Ghz signal)

If your clients are to report you (for what?) then its because you don't know how to finetune your network.

ARM-ARM BRIDGE or P2MP works like that very unstable & slow!!!!!!!!. MIPSBE-ARM works good only in pure 802.11

Posted: **Wed Feb 20, 2019 10:30 am**

I changed my arm because my clients complained and threatened to report me. I only have two lhg ac in a lab ptp and with the latest firmware in 20 mhz these are the results= 50 mbs with ping 60-70...
You are doing something wrong. I run higher (much higher) speeds in a P2MP environment with an AP associated with some 29 clients of different makes, all 'ac' in 802.11ac and can make up to 200Mb download over the AP to clients. Every single client reaches 150Mbps on its one, with 2 both get just over 100mbps, with 3 all three still have some 60Mbps... (80Mhz channel but with lots of overlap over other 5Ghz signal)

If your clients are to report you (for what?) then its because you don't know how to finetune your network.
ARM-ARM BRIDGE or P2MP works like that very unstable & slow!!!!!!!!. MIPSBE-ARM works good only in pure 802.11

True. 802.11 works better for all! Even for mipsbe I get better results in 802.11. Next is nstreme and NV2 is only 60% of what I can get in 802.11.
Last night did some more link tests and ended up 2 more links and one more P2MP switching from NV2 towards 802.11. The last is just so much better.......

Posted: **Wed Feb 20, 2019 12:01 pm**

True mipsbe + arm work So so. But arm + arm... My ptp is arm + arm. If anybody can solve the problem please contact me. I pay.

Posted: **Wed Feb 20, 2019 12:23 pm**

We have made some additional improvements for ARM and Nv2. The version with these fixes will be released in the upcoming days.

Posted: **Wed Feb 20, 2019 1:30 pm**

ARM-ARM BRIDGE or P2MP works like that very unstable & slow!!!!!!!!. MIPSBE-ARM works good only in pure 802.11

ARM-ARM work ok , 120 Mb TCP 20mHz in 802.11 , some packets lost, but very low
only NV2 problem

Posted: **Wed Feb 20, 2019 4:16 pm**

sergesa could you please share with us what models in arm have you tested? Thanks

Posted: **Wed Feb 20, 2019 4:51 pm**

Is omnitik ac legacy? A vendor said me

Posted: **Thu Feb 21, 2019 9:36 am**

ARM + NV2. New rc3 firmware looks very good !

Posted: **Thu Feb 21, 2019 9:56 am**

More improvements in next release for Nv2+ARM

Posted: **Thu Feb 21, 2019 10:33 am**

More improvements in next release for Nv2+ARM

Super!

Can I ask what happened? Do not solve the problem for years, and now is solved?

Posted: **Thu Feb 21, 2019 11:00 am**

years

First post here "22 Jun 2018, 15:25"

Posted: **Thu Feb 21, 2019 11:17 am**

years

First post here "22 Jun 2018, 15:25"

Not here on forum but problem exist from 2017.
What's new in 6.40.2 (2017-Aug-08 13:13):

Posted: **Thu Feb 21, 2019 11:19 am**

More improvements in next release for Nv2+ARM

Did you guys look into the time stamps?
"Last Link Up Time" and "Last Link Down Time" show time in the future...... Time on the router itself is right (corrected by sntp protocol) and in the log time stamps are right too.
But the times under the "W60G Station" tab in the Wireless table is still showing impossible times.
The screenshot is taken today, February the 21th at 10:15h.
The disconnect and re-connect took place the 19th, but the events are shown to be happening the 23th! That is next Saturday! Impossible!

Wrong Time stamps.JPG

Posted: **Thu Feb 21, 2019 11:35 am**

Fixes can start when issue is reported and reproduced. We did not know about it when the devices were released.

Posted: **Thu Feb 21, 2019 11:57 am**

Fixes can start when issue is reported and reproduced. We did not know about it when the devices were released.

From me it is reported to support from Frebruary 2018! I think you have older report from another ISP....
For example there is older topic: viewtopic.php?f=7&t=131174
and other topics on forum....
No matter, I do not want to quarrel. I'm glad you're finally working and solving ...

Thanks

Posted: **Thu Feb 21, 2019 12:00 pm**

Will there be some fixes for both 802.11 and nstream?

NV2 is not suitable for ptp links due to higher ping.

There is a high response in 802.11 and is prone to interference

Nstream is best for ptp but the maximum speed is less than for nv2 and 802.11 112M vs. 140M

Does mips not improve the current parameter?

Posted: **Thu Feb 21, 2019 12:02 pm**

please stick to topic, you can make a new topic about nstreme and mips

Posted: **Thu Feb 21, 2019 12:38 pm**

I think when u fix mixed mode for mipsbe and arm in nv2 u should make nv3 only for arm devices for new bases. This hardware is very good to be competitive and cheep comparing to cambium.

regards

Posted: **Thu Feb 21, 2019 3:18 pm**

I cant see rc3 firmware!!!
Where can download?

Posted: **Thu Feb 21, 2019 3:28 pm**

I cant see rc3 firmware!!!
Where can download?

No one is talking about RC2 or RC3, we talk about Wireless Protocol NV2

Posted: **Thu Feb 21, 2019 3:49 pm**

I cant see rc3 firmware!!!
Where can download?
No one is talking about RC2 or RC3, we talk about Wireless Protocol NV2

Yes, we are talking about RC3 firmware, but it is not yet publicly released...

Posted: **Thu Feb 21, 2019 4:01 pm**

very nice news!

Posted: **Fri Feb 22, 2019 11:13 am**

More improvements in next release for Nv2+ARM

Will be 6.44rc3 released officially? For all architectures?

Posted: **Fri Feb 22, 2019 1:48 pm**

alright, let us know what you see now:
viewtopic.php?f=21&t=145379&p=716706#p716706

Posted: **Fri Feb 22, 2019 3:00 pm**

I can not believe it, the nv2 works perfectly in arm with version 6.44rc4 giving more speed and stability than nstreme or 802.11.

Posted: **Fri Feb 22, 2019 3:06 pm**

Could a mantbox with an arm routerboard give more speed and number of users than with mipsbe routerboard?

Posted: **Fri Feb 22, 2019 3:36 pm**

I can not believe it, the nv2 works perfectly in arm with version 6.44rc4 giving more speed and stability than nstreme or 802.11.

How did you test? How many devices? P2MP? How many associated clients? Did you upgrade the AP only or also its clients?

Before I am going to try this version on one of my live P2MP networks (that all works much better in 802.11 then NV2) I would like to know all these answers.

And no new bugs introduced? Need to see more guys trying this one out.....

Posted: **Fri Feb 22, 2019 4:01 pm**

Why do you ask wirelessrudy? You work fine with arm in the past

Posted: **Fri Feb 22, 2019 4:10 pm**

Why do you ask wirelessrudy? You work fine with arm in the past

What a weird counter question is this.... You make a claim and people then would like to know how you came to that claim. That's not a weird question, this forum is full of it.

This new release is still wet from its paint and you already claim it made a big improvement. Since I need at least a couple of hours to upgrade and test a full P2MP network for any improvements in a new version I'd wonder how you'd be able to make such claim.

If your claim is based upon two devices communicating and now with the new OS much better, then that doesn't bear too much value. 'On the bench testing' has never been an equivalent to 'real life' testing since the outdoor 'real' conditions that have a major influence on the performance are very different.

Secondly:
I manage to get 802.11 working better then NV2. But according the posts many couldn't So where for these many the new OS might give a better result, I might well be on my network it won't.
And this latter would then imply that the new OS is not an improvement at all......

Hence my questions so I can make up my mind if an immediate upgrade could improve my networks or is it going to be another waste of time.....

Posted: **Fri Feb 22, 2019 6:54 pm**

ìt really work ! PtP 20MHZ TCP
1. 802.11 105/100
2. NV2 90/80
nv2 work what never before on ARM, but we wait continued improvements

Posted: **Fri Feb 22, 2019 7:31 pm**

ìt really work ! PtP 20MHZ TCP
1. 802.11 105/100
2. NV2 90/80
nv2 work what never before on ARM, but we wait continued improvements

This still shows 802.11 is better?
What signal strength on both ends? 1 stream tcp or more? Test between the two devices or from devices behind the two radio's? (like two CCR behind the 'arm' devices)

Posted: **Fri Feb 22, 2019 8:20 pm**

Nv2 in PTP with arm works now fine:

802.11 90 Mbps
Nstream 105 Mbps
Nv2 156 Mbps

Posted: **Fri Feb 22, 2019 8:44 pm**

156 on 20 or 40mhz???

Posted: **Sat Feb 23, 2019 12:58 am**

40 MHz 1 tcp between two arm devices.

MikroTik

ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol

Re: ARM devices and NV2 protocol