MikroTik

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.

Posted: **Sat Feb 23, 2019 1:08 am**

This is not AC mode, AC mode will reach around 240Mbps on 40MHz

Posted: **Sat Feb 23, 2019 4:46 am**

Hi, then is ARM already fixed? There are no more packet losses?

Posted: **Sat Feb 23, 2019 8:39 am**

This is not AC mode, AC mode will reach around 240Mbps on 40MHz

yeee single TCP stream 240 Mbit from 40 Mhz

Mby in lab.

Posted: **Sat Feb 23, 2019 9:03 am**

This is not AC mode, AC mode will reach around 240Mbps on 40MHz
yeee single TCP stream 240 Mbit from 40 Mhz Mby in lab.

Still a waste of spectrum these days. Hope .ax shows up soon. >100M Capacity/10MHz is 2019.

Posted: **Sat Feb 23, 2019 9:34 am**

With ubiquiti AF HD we are very close to have 100 mb/s download speed with 10 MHz for PtP NOW for AP side with cambium we have >300 Mb/s@20 MHz using ultra dense mu-mimo technology

Posted: **Sat Feb 23, 2019 9:52 am**

With ubiquiti AF HD we are very close to have 100 mb/s download speed with 10 MHz for PtP NOW for AP side with cambium we have >300 Mb/s@20 MHz using ultra dense mu-mimo technology

So if DISC Lite5 ac DiscG-5acD 240mbit (if it really works) cost is 45$, what is the cost of cambium per mbit?
This is NV2 ARM thread.

Posted: **Sat Feb 23, 2019 10:04 am**

With ubiquiti AF HD we are very close to have 100 mb/s download speed with 10 MHz for PtP NOW for AP side with cambium we have >300 Mb/s@20 MHz using ultra dense mu-mimo technology
So if DISC Lite5 ac DiscG-5acD 240mbit (if it really works) cost is 45$, what is the cost of cambium per mbit?
This is NV2 ARM thread.

Wisps learned that the expensive resource is spectrum not Hardware. To stay on topic: NV2 Arm has to be improved much further to be more spectrum efficient.

Posted: **Sat Feb 23, 2019 10:05 am**

With ubiquiti AF HD we are very close to have 100 mb/s download speed with 10 MHz for PtP NOW for AP side with cambium we have >300 Mb/s@20 MHz using ultra dense mu-mimo technology

Omg 2x2 mimo vs 4x4 mimo compare No sense. AF HD 2x2 true but for 4096 QAM nede clean spectrum

Posted: **Sat Feb 23, 2019 6:05 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)

Rudy,
as my result yes, 802.11 is better, but in ptp.. I'm not sure why I need to use TDM in ptp configuration. I wait this mainly for PtMP, and now will try to update and make test (ap under load all time)
I think now is not matter use external bandwidth test, because last MT firmware use all cores for test
20 streams by default. Bellow is my test PtP

Posted: **Mon Feb 25, 2019 10:11 am**

at the end works, a little slow but work¡¡¡¡¡¡

Posted: **Mon Feb 25, 2019 12:27 pm**

Now that works perfectly nv2. Will it release mikrotik mantbox with arm that admits a greater number of users and throughput?

Posted: **Mon Feb 25, 2019 12:34 pm**

I think first mikrotik release omnitik ac arm but i don't know

Posted: **Mon Feb 25, 2019 1:29 pm**

Now it is much better but it sometimes miss the NV2 slot and the modulation drop.

When I stop the speedtest from the arm device the tx and rx modulations goes higher, the speedtest using UDP is perfect using TCP unleashes more the issue the cpu values are:

system resource cpu print follow
# CPU LOAD IRQ DISK
0 cpu0 5% 0% 0%
1 cpu1 33% 33% 0%
2 cpu2 9% 0% 0%
3 cpu3 3% 0% 0%

Here a print screen left mipsbe AC and left arm AC both clients are on the same roof the signal is better on the arm device

Now that works perfectly nv2. Will it release mikrotik mantbox with arm that admits a greater number of users and throughput?

Posted: **Mon Feb 25, 2019 1:42 pm**

Lite to lite

Posted: **Mon Feb 25, 2019 7:49 pm**

with v6.44rc4 seems to work much much better MT is very close to solve the iusse

Posted: **Mon Feb 25, 2019 10:12 pm**

with v6.44rc4 seems to work much much better MT is very close to solve the iusse

Your picture is with RC1 (this is without ARM fix)

Posted: **Tue Feb 26, 2019 8:55 am**

server8 you are not testing any ARM fixes. The fixes are in rc4 only.

Posted: **Tue Feb 26, 2019 9:03 am**

I have posted that with RC4 works much much better the performance now are much much closer to old AC devices

Posted: **Tue Feb 26, 2019 10:01 am**

RC4 for ARM works much much better for NV2 & pure 802.11 too. Here MIPSBE AC Basestation + ARM CPE good signal 50 dB but non line of sight for pure 802.11N mode. Before RC4 latency spikes for idle mode / no traffic only.

Posted: **Tue Feb 26, 2019 10:39 am**

The fixes are in rc4 only.

Normis, is there diference between rc4 and final 6.44? In wireless driver? Thanks

Posted: **Tue Feb 26, 2019 10:49 am**

6.44rc4 and 6.44 versions are identical.

Posted: **Tue Feb 26, 2019 10:23 pm**

just a question; now for ptp link wich is better between nv2 and 802.11n?

Posted: **Tue Feb 26, 2019 11:03 pm**

just a question; now for ptp link wich is better between nv2 and 802.11n?

nv2 was designed to optimise performance of point to multipoint networks. Usually vanilla 802.11 is faster in ptp however in cases where there is interference nv2 can perform better than 802.11.
When setting up ptp links I always cycle through 802.11/nstreme/nv2 and pick the best. Quite often this is 802.11 or nstreme and not nv2, but when setting up wireless links every environment is different so test test test and don't rely on what worked for someone inside a forum somewhere. Ptmp I always use nv2 though lately I have been hearing that 802.11 is performing better than it used to.

Posted: **Tue Feb 26, 2019 11:58 pm**

just a question; now for ptp link wich is better between nv2 and 802.11n?
nv2 was designed to optimise performance of point to multipoint networks. Usually vanilla 802.11 is faster in ptp however in cases where there is interference nv2 can perform better than 802.11.
When setting up ptp links I always cycle through 802.11/nstreme/nv2 and pick the best. Quite often this is 802.11 or nstreme and not nv2, but when setting up wireless links every environment is different so test test test and don't rely on what worked for someone inside a forum somewhere. Ptmp I always use nv2 though lately I have been hearing that 802.11 is performing better than it used to.

Don't forget to mention that even P2P links once set need every so many months a new check. Spectral environment change. Other users (operators) start using the same or near frequency for instance... A link once worked fine can be a disaster half a year later...

I am one of the user that for the last half year show many tests where 802.11 (rts/cts) outperforms NV2 almost every time again. And special in 'ac' the technology advanced where NV2 in my opinion did not....

Posted: **Wed Feb 27, 2019 2:25 am**

6.44rc4 and 6.44 versions are identical.

For the accurate test, does the AP (netmetal) should also has the 6.44 version or doest it matter?

Posted: **Wed Feb 27, 2019 5:25 pm**

6.44rc4 and 6.44 versions are identical.
For the accurate test, does the AP (netmetal) should also has the 6.44 version or doest it matter?

Brother, the AP is the main device to be upgraded!

Posted: **Thu Feb 28, 2019 9:27 am**

Hi all,
Someone has tested more scenarios with ARM, 5ghz AC, ROS 6.44 with NV2 or 802.11?
we´ve been facing this issues on our network and we need to solve this...

~150 RB922 AP and ~2000 arm CPE

Posted: **Thu Feb 28, 2019 9:28 am**

please upgrade and see. most people have reported good results.

Posted: **Thu Feb 28, 2019 9:34 am**

Hi all,
Someone has tested more scenarios with ARM, 5ghz AC, ROS 6.44 with NV2 or 802.11?
we´ve been facing this issues on our network and we need to solve this...

~150 RB922 AP and ~2000 arm CPE

Upgrade yesterday!!!!!!!!!!!

Posted: **Thu Feb 28, 2019 10:34 am**

We are making some tests and seems to work much much better but our scenario is 1 arm client and 30 mipsbe clients on the AP

I don't know if more arm clients on the AP is a problem

Posted: **Thu Feb 28, 2019 12:10 pm**

We are making some tests and seems to work much much better but our scenario is 1 arm client and 30 mipsbe clients on the AP

I don't know if more arm clients on the AP is a problem

@Server8,

wich MIPSBE device do you use as clients? I saw at this thread that mispse is betther than arm for AC...
The only have DynaDish5, the newer SXT AC lite is all arm...

Posted: **Thu Feb 28, 2019 2:10 pm**

Old SXT lite AC no more on the market actually we are installing mipsbe N after arm ac NV2 issue, yesterday we start back to install some arm ac devices to check it in real life but it's soon to understand if they works

Posted: **Thu Feb 28, 2019 6:46 pm**

nstreme will be ditched? Or is it allready?

Posted: **Thu Feb 28, 2019 6:58 pm**

please upgrade and see. most people have reported good results.

Ok, yesterday upgraded a NetMetal5 from 6.34.12 to 6.44 and all its 9 clients (a mixture of Sextants, LHG's and SXT lites) the same. All mipsbe and all working on 'n' modulation.
Although the NV2 improved a lot, 802.11n with rts/cts is still some 30% faster. The AP and its clients run in a very congested spectrum. Can find no 'free' channel in 40Mhz, 20Mhz sees adjacent AP's hitting with -70 etc. so although we run 40Mhz bandwidth, it sees some overlap with some -75 AP at distance. 802.11 has no issue to maintain almost consistend 50Mbps download towards clients, NV2 stays around 35Mbps. But that was no more then 25 so yes it improved... (or is spectrum different today?)

Yesterday als ran one Omintik5-ac with only 4 clients, all arm units (except this Omnitik off course) and here we saw that NV2 now performs almost the same as the 802.11 rtx/cts protocol.

During the week that comes I will test more P2MP networks since overal I do not see new issues so I can only expect to gain by upgrading.....

Posted: **Thu Feb 28, 2019 7:57 pm**

Now i´ve an AP with 26 ARM CPE. I wounder if i can do a stress test to all units at the same time, like high BW.

Posted: **Thu Feb 28, 2019 7:59 pm**

This is not AC mode, AC mode will reach around 240Mbps on 40MHz
yeee single TCP stream 240 Mbit from 40 Mhz Mby in lab.

Impossible:
802.11ac MCS9 = 200Mbps is highest possible connection rate for 40Mhz channel, one stream. You are on dual stream. You can't beat the standard...

Posted: **Thu Feb 28, 2019 8:02 pm**

Now i´ve an AP with 26 ARM CPE. I wounder if i can do a stress test to all units at the same time, like high BW.

You can, but you'll have to login to every unit and run it. You need a lot of open windows in your management PC..... And you'll find the maximum throughput is relatively low since the AP needs to process all that traffic for each unit which creates a lot of overhead that is bringing the usable throughput down.
Better is to stress test with 3-4 clients max, which is probably also much more reflecting reality....

Posted: **Fri Mar 01, 2019 12:30 pm**

Are there any improvements in nv2 regarding older architecture, mipsbe+AC (omnitik ac) ?
I'm still using 802.11 mode in such scenario and for some longer period of time I stopped buying those omnitiks.

Posted: **Sat Mar 02, 2019 12:39 am**

Now i´ve an AP with 26 ARM CPE. I wounder if i can do a stress test to all units at the same time, like high BW.
You can, but you'll have to login to every unit and run it. You need a lot of open windows in your management PC..... And you'll find the maximum throughput is relatively low since the AP needs to process all that traffic for each unit which creates a lot of overhead that is bringing the usable throughput down.
Better is to stress test with 3-4 clients max, which is probably also much more reflecting reality....

Well you only need to login into one router, a core like a CCR is prefered.
Open up some terminal windows and run:

/tool bandwidth-test 1.2.3.4 user=admin password=password protocol=udp local-tx-speed=5M remote-tx-speed=2M direction=both

Do this for as many CPEs you would like to test, select different speeds for some and you will have a good test of your network.

Posted: **Sat Mar 02, 2019 1:59 am**

Now i´ve an AP with 26 ARM CPE. I wounder if i can do a stress test to all units at the same time, like high BW.
You can, but you'll have to login to every unit and run it. You need a lot of open windows in your management PC..... And you'll find the maximum throughput is relatively low since the AP needs to process all that traffic for each unit which creates a lot of overhead that is bringing the usable throughput down.
Better is to stress test with 3-4 clients max, which is probably also much more reflecting reality....
Well you only need to login into one router, a core like a CCR is prefered.
Open up some terminal windows and run:
Code: Select all
/tool bandwidth-test 1.2.3.4 user=admin password=password protocol=udp local-tx-speed=5M remote-tx-speed=2M direction=both
Do this for as many CPEs you would like to test, select different speeds for some and you will have a good test of your network.

Ok, interesting. Never new that.... going to try that one day... now its weekend... But thanks anyway!

Posted: **Sat Mar 02, 2019 2:02 pm**

SXTsq 5 AC(arm)
ptp Link 80Mhz
using nv2
Throughput - 450mb/s
no packet loss
distance ~600m
looks very good, nv2 is best case scenario atm.

Posted: **Sun Mar 03, 2019 12:08 pm**

This is not AC mode, AC mode will reach around 240Mbps on 40MHz
yeee single TCP stream 240 Mbit from 40 Mhz Mby in lab.
Impossible:
802.11ac MCS9 = 200Mbps is highest possible connection rate for 40Mhz channel, one stream. You are on dual stream. You can't beat the standard...

The guy never said he was SISO, that was your own assumption. He said SINGLE TCP STREAM, with respect to the bandwidth test.
His calculations (240mbps @ 40mhz) are still incorrect though at least when it comes to PHY rates.

Perhaps 240mbps throughput is his real world experience in the field with 2-stream AC @ 40mhz, but he hasn't really explained what he means so we can only guess!

Posted: **Sun Mar 03, 2019 11:35 pm**

Now i´ve an AP with 26 ARM CPE. I wounder if i can do a stress test to all units at the same time, like high BW.
You can, but you'll have to login to every unit and run it. You need a lot of open windows in your management PC..... And you'll find the maximum throughput is relatively low since the AP needs to process all that traffic for each unit which creates a lot of overhead that is bringing the usable throughput down.
Better is to stress test with 3-4 clients max, which is probably also much more reflecting reality....
Well you only need to login into one router, a core like a CCR is prefered.
Open up some terminal windows and run:
Code: Select all
/tool bandwidth-test 1.2.3.4 user=admin password=password protocol=udp local-tx-speed=5M remote-tx-speed=2M direction=both
Do this for as many CPEs you would like to test, select different speeds for some and you will have a good test of your network.
Ok, interesting. Never new that.... going to try that one day... now its weekend... But thanks anyway!

Thanks so much @peson. Very good material,
i´ll test it tomorow.

We have a virtual machine, running Dude Server at the core network, where we can do this test scenario:
But if we have 4 CPEs with different management IP (ex: 10.10.10.1, 10.10.10.2, 10.10.10.3 and 10.10.10.4), we have to running 4 sessions of:

/tool bandwidth-test 10.10.10.x user=admin password=password protocol=udp local-tx-speed=5M remote-tx-speed=2M direction=both

Posted: **Mon Mar 04, 2019 1:36 am**

SXTsq 5 AC(arm)
ptp Link 80Mhz
using nv2
Throughput - 450mb/s
no packet loss
distance ~600m
looks very good, nv2 is best case scenario atm.

hi, can you share speedtest screenshots between radios and ping? please friend

Posted: **Mon Mar 04, 2019 10:39 am**

UDP + torrent, i can share with TCP if you need.

Posted: **Tue Mar 05, 2019 11:03 am**

UDP + torrent, i can share with TCP if you need.

thank you very much for sharing, greetings

Posted: **Sun Mar 10, 2019 3:28 pm**

Hello is there any improvement in nstreme in routeros 6.44?

Posted: **Sun Mar 10, 2019 4:32 pm**

Hello is there any improvement in nstreme in routeros 6.44?

No, only NV2

Posted: **Sun Mar 10, 2019 4:48 pm**

Hi! I would like know about nv2 on mipsbe. Is the performance was improved too or better stay on 6.42? On my network we never get over of about of ~50mb on nv2@20mhz on rush hour and about 25 client with plans between 5mb ~10mb.

Thanks!
David

Enviado de meu Mi A2 Lite usando o Tapatalk

Posted: **Tue Mar 12, 2019 12:47 pm**

@20 MHz 802.11N (not AC) NV2 now 110 Mbit/s for TCP speedtest good job mikrotik

. Now time for fix 40 MHz channel in this moment max speed only 150 Mbit for TCP

Posted: **Tue Mar 12, 2019 4:33 pm**

@20 MHz 802.11N (not AC) NV2 now 110 Mbit/s for TCP speedtest good job mikrotik . Now time for fix 40 MHz channel in this moment max speed only 150 Mbit for TCP

That makes little sense... If you see an improvement on the ROS for 20Mhz then you should also see the same kind of improvement on 40Mhz. The only thing that happens in 40Mhz compared to 20Mhz is de widht of the data pata. Now (theoratically) you can send twice as much data. It's like having now a 4 lane motorway instead of 2.

When you see this little improvement on the 40Mhz compared to 20Mhz as in your example then probably you have interference in the wide frequency. Where 20Mhz would have a pretty 'clear' channel the 40Mhz could well overlap with some other transmitting device which could ultimately make the connections even worse.
Because the radio energy now is devided over a twice a wide spectrum it means the power per hz goes down. And thus the S/N becomes smaller so the datarate cannot maintained at the same level and thus the capacity of the channel goes down.

So check if the 40Mhz channels is as free as the 20Mhz is....

Posted: **Tue Mar 12, 2019 5:55 pm**

Now time for fix 40 MHz channel in this moment max speed only 150 Mbit for TCP

+ 1

Posted: **Tue Mar 12, 2019 6:53 pm**

@20 MHz 802.11N (not AC) NV2 now 110 Mbit/s for TCP speedtest good job mikrotik . Now time for fix 40 MHz channel in this moment max speed only 150 Mbit for TCP

It is great! But it is possible percept in your print that on registration sheet that you have just 6 clients and so with that amount of clients on this antenna so it is relatively easy get highs throughput on this AP. Would you got a teatanother AP with more than 20 clients connected?

Enviado de meu Mi A2 Lite usando o Tapatalk

Posted: **Wed Mar 13, 2019 2:34 pm**

Hi, is mikrotik planning to use arm devices in sector antennas like mantboxes now that nv2 works correctly? Thank you

Posted: **Wed Mar 13, 2019 7:52 pm**

Netmetal mipsbe works great please don't ask for a new russian roulette

Posted: **Fri Mar 15, 2019 12:30 pm**

Still unsolved problem:
ARM client with NV2 is disconnected from AP without reason (ROS 6.44). In log is - lost connection, synchronization timeout
Solution? Reboot client from LAN side. Ticket#2019012222004029

Posted: **Fri Mar 15, 2019 1:00 pm**

Still unsolved problem:
ARM client with NV2 is disconnected from AP without reason (ROS 6.44). In log is - lost connection, synchronization timeout
Solution? Reboot client from LAN side. Ticket#2019012222004029

Watchdog?

Posted: **Fri Mar 15, 2019 1:50 pm**

Still unsolved problem:
ARM client with NV2 is disconnected from AP without reason (ROS 6.44). In log is - lost connection, synchronization timeout
Solution? Reboot client from LAN side. Ticket#2019012222004029

This is a general observation comment about Mikrotik ( not just ARM devices) , why does most of the connectivity issues occur on the wireless part of the router and yet the LAN side is still functional ?

Posted: **Fri Mar 15, 2019 3:32 pm**

Watchdog?

Yes watchdog is workaround. But we have more than 600 ARM clients. Watchdog on all? This is not solution....

This is a general observation comment about Mikrotik ( not just ARM devices) , why does most of the connectivity issues occur on the wireless part of the router and yet the LAN side is still functional ?

No this is not comment from mikrotik. Reboot or power shut down is our solution how to solve this...

Posted: **Fri Mar 15, 2019 6:31 pm**

Still unsolved problem:
ARM client with NV2 is disconnected from AP without reason (ROS 6.44). In log is - lost connection, synchronization timeout
Solution? Reboot client from LAN side. Ticket#2019012222004029

Sounds to me a wireless issue. Probably interference so NV2 sync between AP and CPE gets lost or corrupted and thus connection will be broken until next attempt might repair it.. etc. etc.
A reboot is not going to help it. Sort the wireless. Other frequency, increase S/N (or absolute signal), use other protocol (802.11 is usually better then NV2)

Posted: **Fri Mar 15, 2019 6:51 pm**

Sounds to me a wireless issue.

Yes, this is wireless bug. But only on ARM.
Mipsbe, mmips don´t have this problem.
This problem has nothing to do with SNR or CCQ. You can have the signal -45, CCQ = 100% and still disconnect from AP. The client will never reconnect himself.
In scan from client during problem is 0 networks!
After rebooting or disconnecting power works well. Maybe chipset bug or something with drivers

Posted: **Fri Mar 15, 2019 7:51 pm**

Sounds to me a wireless issue.
Yes, this is wireless bug. But only on ARM.
Mipsbe, mmips don´t have this problem.
This problem has nothing to do with SNR or CCQ. You can have the signal -45, CCQ = 100% and still disconnect from AP. The client will never reconnect himself.
In scan from client during problem is 0 networks!
After rebooting or disconnecting power works well. Maybe chipset bug or something with drivers

What is your software version? I run 6.44 now on all my AP's and clients and have some 700 clients. Some 50% are now arm devices but I don't see any difference between arm and mipsbe.
I also don't see these disconnects often. Sometimes yes, but that can be any device.
I run 802.11n or ac if the network is changed for it. It works much better then NV2 anyway.
But I still have some 50 clients on NV2 networks and have no issues like you'd prescribe.

Posted: **Fri Mar 15, 2019 7:59 pm**

What is your software version? I run 6.44 now on all my AP's and clients and have some 700 clients. Some 50% are now arm devices but I don't see any difference between arm and mipsbe.
I also don't see these disconnects often. Sometimes yes, but that can be any device. I run 802.11n or ac if the network is changed for it. It works much better then NV2 anyway.But I still have some 50 clients on NV2 networks and have no issues like you'd prescribe.

6.44 on clients. And on AP 6.43.x
This issue is random. Sometimes after 7days or xx days or xxx days. We use NV2 on all sector antenas and about 700 ARM clients

Posted: **Fri Mar 15, 2019 8:37 pm**

What is your software version? I run 6.44 now on all my AP's and clients and have some 700 clients. Some 50% are now arm devices but I don't see any difference between arm and mipsbe.
I also don't see these disconnects often. Sometimes yes, but that can be any device. I run 802.11n or ac if the network is changed for it. It works much better then NV2 anyway.But I still have some 50 clients on NV2 networks and have no issues like you'd prescribe.
6.44 on clients. And on AP 6.43.x
This issue is random. Sometimes after 7days or xx days or xxx days. We use NV2 on all sector antenas and about 700 ARM clients

Well, fist thing i would do is set the AP to 6.44 too. (and update firmware for all units!).
I noticed that when versions are not the same some CPE needed long time to connect. I never like to have different versions on CPE and AP anyway.
I always upgrade all clients first (AND firmware!) and end with the AP.

If you are working with mixed versions on devices that communicate with eachother and in this communications something goes wrong you have no clue which software version is the culprit. So first you need to eliminate that....

Posted: **Sun May 19, 2019 7:04 pm**

Now time for fix 40 MHz channel in this moment max speed only 150 Mbit for TCP
+ 1

Tried to use 40MHz instead of 20MHz using nv2 many years ago on a link that was up for nearly 7 years. It was rock solid but it did not become faster than 20MHz, in fact no differences at all. Flat out speed was around 20-30 Mbit/s when doing file transfer tests. No channel overlap or noice or fresnel zones.

Posted: **Sun May 19, 2019 10:50 pm**

Now time for fix 40 MHz channel in this moment max speed only 150 Mbit for TCP
+ 1
Tried to use 40MHz instead of 20MHz using nv2 many years ago on a link that was up for nearly 7 years. It was rock solid but it did not become faster than 20MHz, in fact no differences at all. Flat out speed was around 20-30 Mbit/s when doing file transfer tests. No channel overlap or noice or fresnel zones.

Mikrotik Performance with 20Mhz is good now,
but with 40 MHz they performe not well.

We Switched a 9 km Link Last week from Mikrotik
(M11G+ R11e-5HacD), Antenna is 27,5 dBi RF Elements (RF-ULD-TP-550) to Mimosa.

Spektrum is clean ,Signal Level is -64db, CCQ 99%
Mikrotik 20 MHz about 95MBit
Mikrotik 40 MHz about 130 MBit

No big difference between 802.11 and Nv2

Mimosa C5C 20 MHz about 125 MBit
Mimosa C5C 40 MHz about 230MBit

Tested with Mikrotik BTest from 4011 to Wap60Gx3

The best is the Latency on Mimosa, 1-2ms with Full load

Posted: **Mon May 20, 2019 12:14 am**

Now time for fix 40 MHz channel in this moment max speed only 150 Mbit for TCP
+ 1
Tried to use 40MHz instead of 20MHz using nv2 many years ago on a link that was up for nearly 7 years. It was rock solid but it did not become faster than 20MHz, in fact no differences at all. Flat out speed was around 20-30 Mbit/s when doing file transfer tests. No channel overlap or noice or fresnel zones.
Mikrotik Performance with 20Mhz is good now,
but with 40 MHz they performe not well.

We Switched a 9 km Link Last week from Mikrotik
(M11G+ R11e-5HacD), Antenna is 27,5 dBi RF Elements (RF-ULD-TP-550) to Mimosa.

Spektrum is clean ,Signal Level is -64db, CCQ 99%
Mikrotik 20 MHz about 95MBit
Mikrotik 40 MHz about 130 MBit

No big difference between 802.11 and Nv2

Mimosa C5C 20 MHz about 125 MBit
Mimosa C5C 40 MHz about 230MBit

Tested with Mikrotik BTest from 4011 to Wap60Gx3

The best is the Latency on Mimosa, 1-2ms with Full load

I have to disagree.
I have several P2P and P2MP links with Mikrotik running. Most with moderate to heavy congestion (and thus high noise levels) and all those that need it for the capacity are running on 40Mhz and one link even runs fine on 80Mhz. Not 4 times the throughput as on 20Mhz but 3 times yes...

I also have one Omnitik 5ac with 35-40 SXT-5ac's running in an overlapping 80Mhz bandwidth network. In the same region I have 3 Mimosa A5's with 30 to 45 clients.
Although the peak capacity to the Mimosas can reach 200Mbps I can do 150-180 on the Mikrotik and running tcp speedtest from 3 or 4 SXT's at the same time I can push almost up to 200Mbps over the Omnitik.
We lately have several Mimosa clients wining about connection dropps or slow internet and indeed I see the PHY rates go down at times. The Mikrotik seems to be more stable in the last moths.

Mimosa works all in SRS (= tdma) where basically all my Mikrotiks work nowaday in 802.11ac with RTS/CTS fully enable.

I did many tests on several Mikrotik 802.11ac and 'n' P2MP networks and only when there is strong interference NV2 will do better. But under moderate interference (or low) plain 802.11ac almost always outperforms NV2 by some 30 to 50%.
And all my network run latest 'stable' OS and fw.

I see many here on this forum stating that NV2 is better then 802.11ac but I showed already several times on different post it simply is not.
And with some 40 sectors in a 15 km wide region I have many different spectral environments but in 90% of the cases NV2 is not a winner....

Posted: **Tue May 21, 2019 12:27 am**

Now time for fix 40 MHz channel in this moment max speed only 150 Mbit for TCP
+ 1
Tried to use 40MHz instead of 20MHz using nv2 many years ago on a link that was up for nearly 7 years. It was rock solid but it did not become faster than 20MHz, in fact no differences at all. Flat out speed was around 20-30 Mbit/s when doing file transfer tests. No channel overlap or noice or fresnel zones.
Mikrotik Performance with 20Mhz is good now,
but with 40 MHz they performe not well.

We Switched a 9 km Link Last week from Mikrotik
(M11G+ R11e-5HacD), Antenna is 27,5 dBi RF Elements (RF-ULD-TP-550) to Mimosa.

Spektrum is clean ,Signal Level is -64db, CCQ 99%
Mikrotik 20 MHz about 95MBit
Mikrotik 40 MHz about 130 MBit

No big difference between 802.11 and Nv2

Mimosa C5C 20 MHz about 125 MBit
Mimosa C5C 40 MHz about 230MBit

Tested with Mikrotik BTest from 4011 to Wap60Gx3

The best is the Latency on Mimosa, 1-2ms with Full load

Nothing wrong with 40MHz or 80MHz from my testing
This is a test that I've been doing comparing 802.11 AC and NV2 on different channel width, non interference environment.
The tests have been running between a hAP AC and a Powerbox Pro. TCP test was maxing out the CPUs on the testing routers
AP: mANTBox 19S (MIPS) CPE: SXTsq 5 AC (ARM)
NV2-40 TCP DL/UL, UDP DL/UL 165/146, 277/260
802.11-40 TCP DL/UL, UDP DL/UL 197/178, 307/270
NV2-80 TCP DL/UL, UDP DL/UL 188/167, 517/437
802.11-80 TCP DL/UL, UDP DL/UL 208/189, 545/421

Posted: **Tue May 21, 2019 9:28 am**

@peson Try TCP test. NV2 no scale properly for TCP. I try external machines 2x CCR for tests NO BOTTLENECK FROM CPU just NV2 scale like shiet.

Posted: **Tue May 21, 2019 12:26 pm**

@peson Try TCP test. NV2 no scale properly for TCP. I try external machines 2x CCR for tests NO BOTTLENECK FROM CPU just NV2 scale like shiet.

Will expand the test with CCR1036.

Posted: **Wed May 22, 2019 10:27 pm**

TCP bandwithtest supportet only one cpu!

Posted: **Wed May 22, 2019 11:35 pm**

TCP bandwithtest supportet only one cpu!

Now BT for tcp use one core for one stream & close easy 1000Mbit port.

Posted: **Tue Jul 30, 2019 3:37 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

I have the same issue!
For now did you find solution?

Allison,
https://consumerepic.com

Posted: **Tue Jul 30, 2019 4:48 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
I have the same issue!
For now did you find solution?

You can still buy mipsbe devices, just find the right provider.
And why would you not use 'arm'? I have a 800+ devices Mikrotik network with a mix of all kinds of devices. 75% of my antenas are now 'arm' and they work absolutely fine. Due the higher cpu speeds much better in all kind of wireless scenarios then mipsbe although they also still do fine.
I have full P2MP networks running with either mipsbe (Netmetal) or are devices and as clients both kinds. Some of my networks have up to 35 associated units and we sell 50Mb package to the client

I don't see your issue....

Posted: **Tue Jul 30, 2019 7:36 pm**

I don't see your issue....
Me neither.

Rudy: Tried to PM you, but failed

Posted: **Tue Jul 30, 2019 8:27 pm**

I don't see your issue....
Me neither.

Rudy: Tried to PM you, but failed
rudy@marucom.es

Posted: **Thu Sep 26, 2019 5:18 pm**

Yes, this is wireless bug. But only on ARM.
Mipsbe, mmips don´t have this problem.
This problem has nothing to do with SNR or CCQ. You can have the signal -45, CCQ = 100% and still disconnect from AP. The client will never reconnect himself.
In scan from client during problem is 0 networks!
After rebooting or disconnecting power works well. Maybe chipset bug or something with drivers

We are experiencing this same problem at an apartment complex that we installed this Summer. 12 buildings with SXTs linked to a mANT on the main building. All configured to the same 20MHz ac channel, all running nv2 only (because we're carrying SIP traffic). Every few days, we have a link drop that doesn't come back up on its own, at which point we have to fix the problem on-site. The SXT's log reports:

Code: Select all

sep/25 21:03:06 wireless,info 6C:3B:xx:xx:xx:3F@wlan1: lost connection, synchronization timeout

Disabling/enabling the wireless interface on the SXT doesn't reestablish the connection; the only solution we have found is to reboot the SXT.

Now, the above has only ever happened with the five SXTsq (arm) that we have installed there; never with the nine 5ac or SA5 (mipsbe) models--all operating in the same environment. In fact, as I write this we have two SXTsq that are experiencing this problem simultaneously, which led me to this thread. A bug with nv2 on ac, specific to the arm architecture, would explain the behavior we are seeing.

Edit: All MT devices in this installation are running ROS 6.44.5.

Posted: **Thu Sep 26, 2019 5:29 pm**

You say that

Edit: All MT devices in this installation are running ROS 6.44.5.

But all ARM improvements and fixes were made only in v6.46 tree. Just wait until it's out of beta and then see how it works in your network.

Posted: **Thu Sep 26, 2019 5:36 pm**

Watchdog?
Yes watchdog is workaround. But we have more than 600 ARM clients. Watchdog on all? This is not solution....

In our case, even IP-based watchdog isn't an option. Most of our buildings now have backup links, so when these SXTsq radio links fail, they still have IP connectivity.

We'd have to schedule a script to check the wireless registration table, and if there isn't one, reboot--and then we have to remember to disable this script on each device before performing maintenance, etc.

The solution is for these devices to attempt to reestablish their radio links on their own, like other devices.

Posted: **Thu Sep 26, 2019 5:45 pm**

You say that

Edit: All MT devices in this installation are running ROS 6.44.5.
But all ARM improvements and fixes were made only in v6.46 tree. Just wait until it's out of beta and then see how it works in your network.

Thank you for confirming that this is a known problem that is being addressed, but we can't wait. Subscribers have been losing Internet and phone service for weeks, and every additional day moves them all closer to canceling. If I can put an end to all these problems by replacing five SXTsq with other SXT models, that's what I'm doing today.

Also, starting in 6.45, we found that neighbor discovery is no longer displaying the IP addresses of our devices; just MACs. Our admin traffic, including device IP addresses is on a VLAN, and no traffic is carried on the default. Thanks to the neighbor discovery "fix" in 6.45, it is now correctly showing us that none of these devices have IP addresses on the default VLAN, rather than helpfully showing us their IP addresses on our admin VLAN. We downgraded our entire network (~200 MT devices) to 6.44.5 because of this, and don't plan to upgrade until discovery works again for our configuration.

Posted: **Tue Oct 15, 2019 3:07 pm**

Solution
Netinstall Arm 6.44.3
Extra Package
Advanced tools
DHCP
Security
Wireless
Mpls
System
Routing

I have been using 3ptp links since last 15 days and it's working great.

Posted: **Wed Oct 16, 2019 8:19 am**

install arm 6.44.3 extra packages via Netinstall
only 7 packages needed to upload
advanced tool, dhcp, mpls, routing, security, system, wireless

mine is fixed. now all my 3 PTP connections are ok.

Posted: **Fri Oct 18, 2019 9:09 pm**

install arm 6.44.3 extra packages via Netinstall
only 7 packages needed to upload
advanced tool, dhcp, mpls, routing, security, system, wireless

mine is fixed. now all my 3 PTP connections are ok.

LOL for NV2 ARM now only 6.46 Beta &.....120 Mbit/s from 20Mhz channel p2mp (MIPS BE base + ARM CPE client)

Posted: **Sun Oct 20, 2019 2:48 am**

can't confirm.
on some ptp links looks more stabile, but on ptmp omni ac ----60m distance----> sxtsq ac, on 40mhz gives 127mbps down and 45up,
(nv2 ratio 75% down dynamic)
on 802.11 179/110, ping avg 1ms CCQ99-100% during test.
Ptmp populated with 6xCPE at similar distance,

Posted: **Sun Oct 20, 2019 11:12 am**

My experience says that arm devices works in NV2 AC mode like old mipse device but you must have a good signal (better than -50db) and good s/n and you don't have to ask more than 60 mbit/s of aggregate bandwidth with 30 cpes. AC 40 Mhz channel is not usable both old mipsbe and new arm devices Doubling the channel is not the solution if you have a minimal crowled spectrum expenting not more 80 max 90 mbit/s if you are lucky.

If you want more from your PtMP network using 20 Mhz channel you have to use other vendors with modern TDMA protocol, modern drivers running on modern hardware with modern features.

Mikrotik is a cheap hardware with old radio sotware without modern features we must accept it knowing that ROS is the best but that the radio hardware is the worst.

In PtP scenario AF, Mimosa and other "professional" radio wins every time so the best way to build your PtP network is not use Mikrotik.

Mikrotik funs.... we have to accept it

Posted: **Sun Oct 20, 2019 6:56 pm**

I recently called a post with nv3 since mikrotik told me not to use old protocols like nv2 but they didn't tell me what the new one was. Mikrotik neither solves the problem nor says he will do in the future

Posted: **Mon Oct 21, 2019 1:54 am**

I recently called a post with nv3 since mikrotik told me not to use old protocols like nv2 but they didn't tell me what the new one was. Mikrotik neither solves the problem nor says he will do in the future

Want some cheese with that wine? Please stop spamming the forum - you had an answer in the NV3 thread. Either post your full configuration or don't.

Posted: **Mon Oct 21, 2019 8:49 am**

I shared my configuration in the other forum but neither you nor mikrotik helped me. I would be very embarrassed to treat my clients or people as you do. It is known that the arm and the nv2 does not work correctly, why do you deny reality?

Posted: **Mon Oct 21, 2019 9:12 am**

Mikrotik is a cheap hardware with old radio sotware without modern features

Looks like you don't realize that Nv2 is developed entirely by MikroTik, so you can't say "without modern features".

Posted: **Mon Oct 21, 2019 10:06 am**

Yes! Me too! DISC AC LITE is the bugger. The arm SXT's are a lot more stable on the identical configuration. Dyna's fine. LHG fine. Just the damn DISC AC LITE.
The main problem I experience is when the control frame timeouts start happening. After a while the disc just disconnects from the AP and the system soft disables the radio behind the scenes. Even rebooting the AP does not help. The only way to rectify this is to go to client site and hard reboot the disc. This is happening with about 50% of deployed discs.
And a lot of packet loss. Always in blocks of 4.
Very frustrating. Very time consuming. Very expensive. Very embarrassing as a professional WISP.
Please can somebody help me!

Posted: **Mon Oct 21, 2019 11:25 am**

My experience says that arm devices works in NV2 AC mode like old mipse device but you must have a good signal (better than -50db) and good s/n and you don't have to ask more than 60 mbit/s of aggregate bandwidth with 30 cpes. AC 40 Mhz channel is not usable both old mipsbe and new arm devices Doubling the channel is not the solution if you have a minimal crowled spectrum expenting not more 80 max 90 mbit/s if you are lucky.

If you want more from your PtMP network using 20 Mhz channel you have to use other vendors with modern TDMA protocol, modern drivers running on modern hardware with modern features.

Mikrotik is a cheap hardware with old radio sotware without modern features we must accept it knowing that ROS is the best but that the radio hardware is the worst.

In PtP scenario AF, Mimosa and other "professional" radio wins every time so the best way to build your PtP network is not use Mikrotik.

Mikrotik funs.... we have to accept it

Just run 802.11ac.
I have one Netmetal on omni antena with 40 associated mipsbe and arm devices in 80Mhz channel overlapping other nearby 80Mhz ac AP's (Mimosa and further away Mikrotik and UBNT) and we server clients with 100Mbps and get 150-180mpbs aggregated over the Netmetal without problems. Running all on 6.45.6.

NV2 is not as good, but the standard 802.11ac protocol is by itself very sturdy. Ping to clients is below 20ms (from border gateway over one wireless backhaul) and we have people using Skype, Voip and other real stuff (IPTV) without issues.
I have 30+ Mikrotik AP's and some 20 MT backhauls and almost in all instances 802.11ac runs better then NV2. Some backhaul actually performs better with nstreme or NV2 but that is usually when very strong interference is around.
The only argument is that you always need to look for -55 or better signals.
(With weaker signals Mimosa also sucks, actually even worse than MT and we have one eCambium2000 that is only doing slightly better then Mikrotik at the expense of a lot more money....

Posted: **Mon Oct 21, 2019 11:30 am**

I shared my configuration in the other forum but neither you nor mikrotik helped me. I would be very embarrassed to treat my clients or people as you do. It is known that the arm and the nv2 does not work correctly, why do you deny reality?

I have several mixed (mipsbe + arm) P2MP networks and have been comparing NV2 and 802.11ac a lot. While in 95% of the cases 802.11ac outperforms NV2 a lot in itself I never saw any problems with NV2 and arm devices compared to NV2 and mipsbe.
I really don't don't understand why several on this forum keep on saying NV2 and arm is worse then NV2 + mipsbe. In both cases it is worse then default 802.11ac but I never saw real difference between the two chipsets....

Posted: **Mon Oct 21, 2019 11:57 am**

Yes, just like WirelessRudy confirms, we have said this before.

Nv2 was designed for older chipsets, to solve problems that were there at the time. New chipsets and 802.11ac do not have the same issues, so there is no real benefit to use Nv2 now.

Posted: **Mon Oct 21, 2019 12:11 pm**

Yes, just like WirelessRudy confirms, we have said this before.

Nv2 was designed for older chipsets, to solve problems that were there at the time. New chipsets and 802.11ac do not have the same issues, so there is no real benefit to use Nv2 now.

Normis 802.11ac not work in PtMP scenario in crowled spectrum with hidden nodes we are forced to use NV2. All AP are a mix of old a new arm devices!!!
With mikrotik we have something like +200 APs and 5500 CPEs so let me consider my statement true
Maybe 802.11ax will solve the problem but we have no info from mikrotik about it!!!

Posted: **Mon Oct 21, 2019 12:12 pm**

Yes, just like WirelessRudy confirms, we have said this before.

Nv2 was designed for older chipsets, to solve problems that were there at the time. New chipsets and 802.11ac do not have the same issues, so there is no real benefit to use Nv2 now.

There are still problems with plain .ac and outdoor wireless regarding media access/hidden node. So a TDMA-Protocol like nv2 with AP-controlled media access would help running smoother and avoid voip-glitches. This might change with 802.11ax as there are scheduling mechanisms right within the standard which schedule by frequency and time.
So I dont want MT to do nv3 now. I want to get .ax ASAP

.

Posted: **Mon Oct 21, 2019 12:15 pm**

Yes! Me too! DISC AC LITE is the bugger. The arm SXT's are a lot more stable on the identical configuration. Dyna's fine. LHG fine. Just the damn DISC AC LITE.
The main problem I experience is when the control frame timeouts start happening. After a while the disc just disconnects from the AP and the system soft disables the radio behind the scenes. Even rebooting the AP does not help. The only way to rectify this is to go to client site and hard reboot the disc. This is happening with about 50% of deployed discs.
And a lot of packet loss. Always in blocks of 4.
Very frustrating. Very time consuming. Very expensive. Very embarrassing as a professional WISP.
Please can somebody help me!

I have some 20 DISC 5Lite ac's and they are we see no worse performance than any of the other devices we have. In fact, we have some 200+ LHG-5Lite ac's and sometime we have an irregular one losing its configuration. We've had that three times now. Usually after some short lived power cuts. But apart from that, Mikrotik units (of all kinds) are very stable and reliable. We rarely have failing units which we cannot say from Mimosa or eCambium devices we use....

Posted: **Mon Oct 21, 2019 12:46 pm**

Yes! Me too! DISC AC LITE is the bugger. The arm SXT's are a lot more stable on the identical configuration. Dyna's fine. LHG fine. Just the damn DISC AC LITE.
The main problem I experience is when the control frame timeouts start happening. After a while the disc just disconnects from the AP and the system soft disables the radio behind the scenes. Even rebooting the AP does not help. The only way to rectify this is to go to client site and hard reboot the disc. This is happening with about 50% of deployed discs.
And a lot of packet loss. Always in blocks of 4.
Very frustrating. Very time consuming. Very expensive. Very embarrassing as a professional WISP.
Please can somebody help me!
I have some 20 DISC 5Lite ac's and they are we see no worse performance than any of the other devices we have. In fact, we have some 200+ LHG-5Lite ac's and sometime we have an irregular one losing its configuration. We've had that three times now. Usually after some short lived power cuts. But apart from that, Mikrotik units (of all kinds) are very stable and reliable. We rarely have failing units which we cannot say from Mimosa or eCambium devices we use....

+1

Very impressive live time. We've still 133c boards to replace with newer HW.

Posted: **Mon Oct 21, 2019 11:42 pm**

hidden nodes

You do know about RTS/CTS and that it is off by default, right?

Posted: **Tue Oct 22, 2019 12:54 pm**

ALL AP & CLIENTS updated 6.46beta55. ARM+NV2+20Mhz+802.11N not AC (912UAG-5HPnD sector with 18 active clients) now gave 100-110 Mbit/s for TCP bandwidth test. NV2+802.11AC+20Mhz gave 120 Mbit from 20Mhz ( SXT G-5HPacD).........Pure 802.11 AC works much worse hidden nodes completely disaster RTS/CTS from 0 bytes don't help for long range ptmp links.

Posted: **Tue Oct 22, 2019 6:50 pm**

@2jAREK; Your screenshots are not giving good info. What are the RTS/CTS settings in both 802.11n or 802.11ac? What are signal strengths of the clients.

Did your readup on 802.11ac IEEE protocol standard? Hidden node is no longer an issue since it is the AP that hands out airtime to associated devices, unlike in802.11'n' protocol.

I run many AP's in 802.11ac mode and it almost always outperforms 802.11n devices, especial when there is lots of interference or units cannot 'see' eachother. ("Hidden node").

Another feature of 802.11 ac is the 80Mhz wide band. You can now use up to 4 AP's in the same band but make sure each has another 'pilot' channel. Now devices that 'hear' another AP in de band as what they should be listening too it will not use that 20Mhz channel for that CPE. Now this CPE will have less capacity but still 40Mhz bandwidth or in the worse case scenario 20Mhz.
Even in this worse case scenario, given that the signal is good enough you could still get higher MCS then possible under 'n' protocol

Because many CPE's now can work with 40 or even 80Mhz wide channel you create much more spectrum space for each AP to make use for sending and receiving data so the data demands from clients gets processed much faster then in 20Mhz thus much more time to deal with 'talking' to other clients.
On a mild to moderate used network (and I use up to 35-40 clients per AP!) this works perfect. NV2 can never give me the same results.
In NV2 ping times are only slightly lower but capacity is less then half and much more interference issues.....

But it needs a lot of fine tuning.
- Good to high signals. Use the best directional client antenna you can get for a reasonable price. (LHG, DISC)
- Always try to separate channel use (Competition!) as much as possible for AP's.
- Make wifi scan (and if possible spectral scan) from client to see where his biggest interferers come from and try to adjust things...
- Set RTS/CTS to always work and set "cts to self" on AP
- set Guard Interval to 'long' (more stable links at the expense of a little bit less throughput)
-set Preamble to long (more stable links at the expense of a little bit less throughput)
- Enable ANI both on client and AP
- Hw retries = 7 or lower.
- Choose your frequency carefully. 5Mhz up or down, or Ceee instead of eCee or eeeC can make a lot of difference....

I sometimes need a full day to find the best setting for an AP.... it means a lot of tests, tryouts and changes....
And sometimes I find the next week I have to start all over again because some friendly competitor decided to 'shruck' his bands too close to mine.....

And still sometimes NV2 is better or even nstreme. I have 80% of my AP's use plain 802.11ac and the rest is either nstreme or NV2.

Even on backhauls I mostly use 802.11ac now, mikrotik links doing 300Mbps over several km's are possible.....

Posted: **Tue Oct 22, 2019 7:36 pm**

@2jAREK; Your screenshots are not giving good info. What are the RTS/CTS settings in both 802.11n or 802.11ac? What are signal strengths of the clients.

..

LOOK CLOSER NV2+20Mhz+802.11N + ARM CLIENTS. RTS/CTS settings & HW retries without meaning FOR NV2 mode.

I have many 802.11AC sites not NV2. But pure AC works only fort short distance & good signals. If u have noise & 5 km links + p2mp 20 clients pure 802.1n/AC don't works no matter RTC/CTS & PREAMBLE & HW protection threshold 0 u SET just disconnects all time.

Posted: **Wed Oct 23, 2019 12:10 am**

LOOK CLOSER NV2+20Mhz+802.11N + ARM CLIENTS. RTS/CTS settings & HW retries without meaning FOR NV2 mode.

I have many 802.11AC sites not NV2. But pure AC works only fort short distance & good signals. If u have noise & 5 km links + p2mp 20 clients pure 802.1n/AC don't works no matter RTC/CTS & PREAMBLE & HW protection threshold 0 u SET just disconnects all time.

You are not showing details of the tryouts with 802.11ac. If we can't see how these are configured we don't know if you get the best out of 'ac'

I have a mix of towers all serving clients from 500mtres to 5km and all with interference from at least some 20 other sectors in the region. Many of my clients can get 100Mbps delivered (tcp single stream traffic) and 90% are arm devices in either 40 or 80Mhz wide channel.
We tried NV2 over and over again and I made several examples in this forum to show NV2 simply is not half as good as 802.11ac. Only in rare occasions we get 60% of capacity in NV2 compared to 'ac'.
I am still swapping 'n' devices for LHG's and DISC's and can't wait to get the rest running 802.11ac so we can start offering higher package to the clients. (And most need IPTV, works absolute fine on our 'ac' towers.

Posted: **Wed Oct 23, 2019 8:26 am**

Nothing will work reliably in "crowded spectrum ptmp with hidden nodes"!
You are asking to bend physics.

Posted: **Wed Oct 23, 2019 11:11 am**

LOOK CLOSER NV2+20Mhz+802.11N + ARM CLIENTS. RTS/CTS settings & HW retries without meaning FOR NV2 mode.

I have many 802.11AC sites not NV2. But pure AC works only fort short distance & good signals. If u have noise & 5 km links + p2mp 20 clients pure 802.1n/AC don't works no matter RTC/CTS & PREAMBLE & HW protection threshold 0 u SET just disconnects all time.
You are not showing details of the tryouts with 802.11ac. If we can't see how these are configured we don't know if you get the best out of 'ac'

I have a mix of towers all serving clients from 500mtres to 5km and all with interference from at least some 20 other sectors in the region. Many of my clients can get 100Mbps delivered (tcp single stream traffic) and 90% are arm devices in either 40 or 80Mhz wide channel.
We tried NV2 over and over again and I made several examples in this forum to show NV2 simply is not half as good as 802.11ac. Only in rare occasions we get 60% of capacity in NV2 compared to 'ac'.
I am still swapping 'n' devices for LHG's and DISC's and can't wait to get the rest running 802.11ac so we can start offering higher package to the clients. (And most need IPTV, works absolute fine on our 'ac' towers.

1) NV2 works well only for 20Mhz chanel. Don't scale properly 110-120 tcp with 20Mhz chanel & 130-150 from 40Mhz for TCP multi stream. Even in lab clear spectrum.
2)NV2 works well on Old BASEBOX 5N 912UAG-5HPnD & SXT G-5HPacD but completely unusable (70Mbit from 20Mhz) on Netmetals like 921UAGS-5SHPacT witch sector antena.

Posted: **Wed Oct 23, 2019 11:26 am**

I stop buy mikrotik AC gears.I buy only used cheap OLD LHG & SXT 802.11N. & wait for UBNT LTU. First tests gave 150Mbit from 20Mhz, 420Mbit from 50Mhz & good price 99$ for basic client CPE.

Posted: **Wed Oct 23, 2019 2:02 pm**

Does this competitor stuff use Nv2? Or you admit, that it works fine without Nv2?
I can repeat, the modern hardware is different. You should be able to make a good and working setup with 802.11ac
Nv2 was made for solving other problems with other hardware.

Posted: **Wed Oct 23, 2019 2:46 pm**

I stop buy mikrotik AC gears.I buy only used cheap OLD LHG & SXT 802.11N. & wait for UBNT LTU. First tests gave 150Mbit from 20Mhz, 420Mbit from 50Mhz & good price 99$ for basic client CPE.

Ok, maybe we should make a deal. I have some 100 LHG-n devices soon and actually we just threw some 50 SXT 802.11'n''s away.... We are facing out another 70 or so LHG-n to be replaced by new LHG 'ac' devices. And I have probably some 10-20 'old' SXT models coming back that are going to be replaced by either DISC's or the new SXT-sq5 'ac' devices.

Any interest in the old SEXTANT's? Or RF-Elements with Mikrotik 'n' boards in them. I might stop binning these if you want them? They all coming back from working environment but I want to upgrade my full MT P2MP network to 'ac' so we can start offering 100Mb package to clients..... I stil have some 200 units to go but as a small operator with little margin its going to take us another 6 months at least.... And I feel sorry for tipping so many still good (but not good enough!) working units that has done so good for years...

Most of the LHG's come in boxes from the new LHG-5ac we buy. We only replace the radio so all the rest (dish, adapter, inserter) are brand new. What'd we say? 100€ per box of 5 LHG's?
Send me an e-mail if interested: rudy@marucom.es.

I'd suppose MT will be happy with this deal since it will help me forwarding the purchase or more 'ac' devices from them!

Posted: **Wed Oct 23, 2019 3:22 pm**

Does this competitor stuff use Nv2? Or you admit, that it works fine without Nv2?
I can repeat, the modern hardware is different. You should be able to make a good and working setup with 802.11ac
Nv2 was made for solving other problems with other hardware.

OFC UBNT LTU use completely different hardware closer LTE than 802.11 but its still TDMA (0 problems with hidden nodes & NLOS & load balancing like 802.11AC even with RTS/CTS, WMM no matter real ISP need TDMA protocol).
Just don't give up development NV2. NV2&ARM now works same or better than MIPSBE for 20Mhz channel. Almost same good like pure 802.11AC 120Mbit for SINGLE TCP STREAM (17 active clients on AP)

Posted: **Wed Oct 23, 2019 5:55 pm**

OFC UBNT LTU use completely different hardware closer LTE than 802.11 but its still TDMA (0 problems with hidden nodes & NLOS & load balancing like 802.11AC even with RTS/CTS, WMM no matter real ISP need TDMA protocol).
Just don't give up development NV2. NV2&ARM now works same or better than MIPSBE for 20Mhz channel. Almost same good like pure 802.11AC 120Mbit for SINGLE TCP STREAM (17 active clients on AP)

Just curious have you used OFC UBNT LTU! and does it really give 0 problems with NLOS issues !

On a minor note , the date on the clock is incorrect!

Posted: **Wed Oct 23, 2019 10:31 pm**

I have a mix of towers all serving clients from 500mtres to 5km and all with interference from at least some 20 other sectors in the region. Many of my clients can get 100Mbps delivered (tcp single stream traffic) and 90% are arm devices in either 40 or 80Mhz wide channel.
We tried NV2 over and over again and I made several examples in this forum to show NV2 simply is not half as good as 802.11ac. Only in rare occasions we get 60% of capacity in NV2 compared to 'ac'.
I am still swapping 'n' devices for LHG's and DISC's and can't wait to get the rest running 802.11ac so we can start offering higher package to the clients. (And most need IPTV, works absolute fine on our 'ac' towers.

When comparing AC to NV2 is that running units with the same channel width - NV2= 20Mhz and AC=20Mhz?

Posted: **Wed Oct 23, 2019 11:22 pm**

When comparing AC to NV2 is that running units with the same channel width - NV2= 20Mhz and AC=20Mhz?

In some cases yes, in some we upgraded to 40Mhz (and in 2 even to 80Mhz wide). But before things became worse with NV2 going from 20 to 40Mhz. Now usually not. (But careful setting of frequency and pilot channel is needed with regular check and update. The spectrum changes all the time....)

Posted: **Tue Dec 03, 2019 8:17 pm**

After all this, is it now "safe" to build a network with mANTBox and arm .ac as clients?
I need to make a high speed ptmp 6 clients network.

Posted: **Tue Dec 03, 2019 9:03 pm**

802.11ac loses packets and is very vulnerable. It would be a lot to ask @normis for a tdma for the ac from mikrotik. All manufacturers have their tdma that works well. Why mikrotik no?

Posted: **Tue Dec 03, 2019 10:02 pm**

802.11ac loses packets and is very vulnerable. It would be a lot to ask @normis for a tdma for the ac from mikrotik. All manufacturers have their tdma that works well. Why mikrotik no?

Cambium Elevate & now.... almost all 802.11N mikrotik devices works much, much better than mikrotik software;) Or w8 for UBNT LTU.

Posted: **Wed Dec 04, 2019 7:03 pm**

802.11ac loses packets and is very vulnerable. It would be a lot to ask @normis for a tdma for the ac from mikrotik. All manufacturers have their tdma that works well. Why mikrotik no?
Cambium Elevate & now.... almost all 802.11N mikrotik devices works much, much better than mikrotik software;) Or w8 for UBNT LTU.

Feedback from UBNT LTU users is that it cannot handle noisy environments, requires a totally clean spectrum?

Posted: **Wed Dec 04, 2019 9:01 pm**

802.11ac loses packets and is very vulnerable. It would be a lot to ask @normis for a tdma for the ac from mikrotik. All manufacturers have their tdma that works well. Why mikrotik no?
Cambium Elevate & now.... almost all 802.11N mikrotik devices works much, much better than mikrotik software;) Or w8 for UBNT LTU.
Feedback from UBNT LTU users is that it cannot handle noisy environments, requires a totally clean spectrum?

Works but can't handle 1024-256QAM, max 64QAM & some packets drop. No latency spikes/jitter like 802.11 just drop. Test vs mikrotik netmetal. LTU needs clean spectrum for full speed.

Posted: **Wed Dec 04, 2019 9:54 pm**

Works but can't handle 1024-256QAM, max 64QAM & some packets drop. No latency spikes/jitter like 802.11 just drop. Test vs mikrotik netmetal. LTU needs clean spectrum for full speed.

The real performance benchmark for wireless equipment is when it can operate at (or close to) full speed in noisy environments.

Posted: **Fri Dec 13, 2019 8:39 pm**

With the new RouterOS v6.46 do you see some total traffic improvements on point-to-multipoint nv2 or other mt setups?

Posted: **Sat Dec 14, 2019 12:22 am**

With the new RouterOS v6.46 do you see some total traffic improvements on point-to-multipoint nv2 or other mt setups?

Wha we should see that?
We can’t test it, we removed all Mikrotik P2P

Posted: **Sat Dec 14, 2019 10:57 am**

We can’t test it, we removed all Mikrotik P2P

So why do you even bother replying to the post by @ronnie? His question obviously doesn't target you ...

Posted: **Sat Dec 14, 2019 11:01 am**

We can’t test it, we removed all Mikrotik P2P

So why do you even bother replying to the post by @ronnie? His question obviously doesn't target you ...

Maybe to express his anger and frustration, peoples like to use forums for that ....

Posted: **Sat Dec 14, 2019 11:24 am**

We can’t test it, we removed all Mikrotik P2P

So why do you even bother replying to the post by @ronnie? His question obviously doesn't target you ...
Maybe to express his anger and frustration, peoples like to use forums for that ....

Quite likely. And I understood it when his frustration was new. But this is going on for quite some time, he changed his PtMP gear meanwhile, so it's time for him to move forward (or seek professional help to deal with all of his personal problems) ...
This is part of forum discussing a new major version which we all should hope will bring us some major improvements (hopefully sooner rather than later). So I really hope he doesn't poison positive karma found around here ...

Posted: **Sat Dec 14, 2019 2:20 pm**

With the new RouterOS v6.46 do you see some total traffic improvements on point-to-multipoint nv2 or other mt setups?
Wha we should see that?
We can’t test it, we removed all Mikrotik P2P

As others said. You have said your opinion and everyone could search and find. So repeating again and again ...
Lets look forward and be positive.

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