Community discussions

 
server8
Member
Member
Posts: 380
Joined: Fri Apr 22, 2011 1:27 pm

Re: Significant improvement for wireless Nv2 PtMP

Fri Apr 06, 2018 3:05 pm

We have made a large deployment (70 ap) of new beta firmware on our network and I can confirm +25% in download speeds with GOOD upload speeds with maximum speed of 50Mb/s in peak time. Comparing new fw with ubiquiti AP gen 2 in the same enviroment mikoritk is slower. With ubiquiti we reach around 70 mb/s of download speed in peak time, the performance are the similar with no load on the AP.

Clients: from 25 to 40
Tdma perido size: auto
Mode: Dynamic downlink
Downlink ratio: 67%
Queue count: 2
Qos: default

We also see a little improvment moving from a/n/ac to n/ac

Mikrotik maybe with a little work on the NV2 scheduler we can stay closer to ubiquiti :-)
 
WirelessRudy
Forum Guru
Forum Guru
Posts: 3082
Joined: Tue Aug 08, 2006 5:54 pm
Location: Spain

Re: Significant improvement for wireless Nv2 PtMP

Fri Apr 06, 2018 7:31 pm

We have made a large deployment (70 ap) of new beta firmware on our network and I can confirm +25% in download speeds with GOOD upload speeds with maximum speed of 50Mb/s in peak time. Comparing new fw with ubiquiti AP gen 2 in the same enviroment mikoritk is slower. With ubiquiti we reach around 70 mb/s of download speed in peak time, the performance are the similar with no load on the AP.

Clients: from 25 to 40
Tdma perido size: auto
Mode: Dynamic downlink
Downlink ratio: 67%
Queue count: 2
Qos: default

We also see a little improvment moving from a/n/ac to n/ac

Mikrotik maybe with a little work on the NV2 scheduler we can stay closer to ubiquiti :-)
That's good news, and bad....
The good is that you can confirm there is a improvement, something others already noticed including me. But since some others also still say they don't see the improvement happening this always leaves room for doubts... hence the more, and the bigger operators, can confirm, the better....

The bad thing is/can be is that Ubiquity is better...... You are probably in a good situation with a big network using both brands so you can compare. Most of us probably can't and thus can only hope they have a good network, and hope its better then the competition. If now some says the comparison says Ubiquity is better, that is not good news. Not for me, not for most or our fellow Mikrotik users and not for Mikrotik. Let's hope they are not getting too much beers in Berlin and feel this as a kick under their b*tt to start working on it!

Now I do have some remarks on the side:

- To get the Ubiquity AP Gen2 you need the new hardware? With MT al you need is a (free!) upgrade..... so a time AND money saver...
- You made the comparison with 67% download ratio. Isn't that a little bit small?
On my network (+/- 750 households and small business) I see on average only a 5% upload compared to the download. Maybe 10-15% in rare cases.
I'd presume we have a very average client base so a 80% download ratio could be set without issues.....
I did some tests on both a P2MP network as in a P2P link and yes, the download ratio make a difference. And yes, 80% is better then 70% is better then 60......

This would make the comparison different?

On one of my networks I also did some tests to see what speeds I can get in different settings and I could push some clients over 80mbps in a 40Mhz wide band. Running on 4 clients at the same time (AP = Netmetal, NV2 'n' only, 29 associated clients.) I could push the AP towards 120Mbps and that speed was sort of distributed over those 4 clients.
But it depends a lot on the spectrum. Other P2MP networks can't be made that good....

I also have one network where 802.11an actually gave me even better results.
I'll guess a lot depends on the characteristics of your P2MP environment too.

Off course Mikrtotik still has a lot to work on. I also had a Mimosa AP for a while with 56 (!) SXT-5ac's running in their 'interop' mode (=802.11a/c) and could push the SXT's towards 200mbps.
Running 2 o 3 SXT's at the same time gave me almost half a gig aggregated over the AP!

(Why not stick with this setup now some might ask? Well, the Mimosa AP costs about 4 times as much as an Netmetal. It lacks a lot of ROS's functionality. When running tdma the max. amount of clients is 44 and these have to be Mimosa too. These CPE's cost 2,5 times as much as an SXT-5ac. And the reach of their 4x single stream antenna setup in the omni is not very far. 400-500 meter is about the maximum or you are degrading your network rapidly. At 1km or more you need their sectorized units with bigger antennas on the clients which drives the cost even higher. And then the performances are not so much better anymore then in a good tuned Mikrotik (or Ubiquity?) network.)

Anyway, now with their new 60G solutions (60G LHG presented again in Berlin MUM, but now with 'soon available' ) we can start thinking of making 60Ghz cells of up to 1 km! With super high speeds! I am already setting up 200 meter cells with their smaller units. These 60G CPE's are cheaper then a Mimosa CPE so for very short range heavy congested cells this is a nice solution.
At least most of my small distant backbones will be replaced by them!
Show your appreciation of this post by giving me Karma! Thanks.

Rudy R. Puister

WISP operator based on MT routerboard & ROS.
 
User avatar
karina
Member
Member
Posts: 446
Joined: Sat Feb 06, 2010 2:18 am
Location: Spain

Re: Significant improvement for wireless Nv2 PtMP

Sat Apr 07, 2018 7:28 pm

We have made a large deployment (70 ap) of new beta firmware on our network and I can confirm +25% in download speeds with GOOD upload speeds with maximum speed of 50Mb/s in peak time. Comparing new fw with ubiquiti AP gen 2 in the same enviroment mikoritk is slower. With ubiquiti we reach around 70 mb/s of download speed in peak time, the performance are the similar with no load on the AP.

Clients: from 25 to 40
Tdma perido size: auto
Mode: Dynamic downlink
Downlink ratio: 67%
Queue count: 2
Qos: default

We also see a little improvment moving from a/n/ac to n/ac

Mikrotik maybe with a little work on the NV2 scheduler we can stay closer to ubiquiti :-)
I am a little confused about the downlink ratio setting. I assumed the percentage setting was for fixed and dynamic was just dynamic with no bias. I read people are setting the ratio to Dynamic but also assuming the percentage setting make a difference. Can someone confirm the difference between 80% Dynamic and 80% fixed

Sent from my ONEPLUS A5010 using Tapatalk

 
User avatar
karina
Member
Member
Posts: 446
Joined: Sat Feb 06, 2010 2:18 am
Location: Spain

Re: Significant improvement for wireless Nv2 PtMP

Sat Apr 07, 2018 7:50 pm

We have made a large deployment (70 ap) of new beta firmware on our network and I can confirm +25% in download speeds with GOOD upload speeds with maximum speed of 50Mb/s in peak time. Comparing new fw with ubiquiti AP gen 2 in the same enviroment mikoritk is slower. With ubiquiti we reach around 70 mb/s of download speed in peak time, the performance are the similar with no load on the AP.

Clients: from 25 to 40
Tdma perido size: auto
Mode: Dynamic downlink
Downlink ratio: 67%
Queue count: 2
Qos: default

We also see a little improvment moving from a/n/ac to n/ac

Mikrotik maybe with a little work on the NV2 scheduler we can stay closer to ubiquiti :-)
I am a little confused about the downlink ratio setting. I assumed the percentage setting was for fixed and dynamic was just dynamic with no bias. I read people are setting the ratio to Dynamic but also assuming the percentage setting make a difference. Can someone confirm the difference between 80% Dynamic and 80% fixed

Sent from my ONEPLUS A5010 using Tapatalk
It's ok I read the manual again and realised that with dynamic the ratio comes into use when the ap is saturated. This brings me to ask how does ap determine when to use the ratio.. are there any settings that can effect the threshold

Sent from my ONEPLUS A5010 using Tapatalk

 
n21roadie
Forum Guru
Forum Guru
Posts: 1887
Joined: Fri Aug 07, 2009 10:36 pm
Location: Limerick,Ireland

Re: Significant improvement for wireless Nv2 PtMP

Sun Apr 08, 2018 3:02 pm

It's ok I read the manual again and realised that with dynamic the ratio comes into use when the ap is saturated. This brings me to ask how does ap determine when to use the ratio.. are there any settings that can effect the threshold

Sent from my ONEPLUS A5010 using Tapatalk
A very good question and I would add further as most functions in ROS are software based, I think ROS should build a wireless only version and add options/functions that do not impact on wireless performance?
A simple question is why do other vendors using similar chipsets have better wireless performance when running half duplex?
 
WirelessRudy
Forum Guru
Forum Guru
Posts: 3082
Joined: Tue Aug 08, 2006 5:54 pm
Location: Spain

Re: Significant improvement for wireless Nv2 PtMP

Sun Apr 08, 2018 5:22 pm

It's ok I read the manual again and realised that with dynamic the ratio comes into use when the ap is saturated. This brings me to ask how does ap determine when to use the ratio.. are there any settings that can effect the threshold

Sent from my ONEPLUS A5010 using Tapatalk
A very good question and I would add further as most functions in ROS are software based, I think ROS should build a wireless only version and add options/functions that do not impact on wireless performance?
A simple question is why do other vendors using similar chipsets have better wireless performance when running half duplex?
I can underwrite that last question in ful!

But a separate ROS version for wireless I think a bit difficult and unnecessary.
It would-be better when the WiKi/manual has a better wireless part.

I could do with a separate wireless manual that prescribes all the different possible settings and its implications and when recommended or not. With some examples.
Now you have to search several sections of the Wiki to find that info you'd need and you have to search and dig the forum to find out when what settings would be recommended or who when has the best results.
No sometimes is more like searching for the famous needle in a haystack...
Show your appreciation of this post by giving me Karma! Thanks.

Rudy R. Puister

WISP operator based on MT routerboard & ROS.
 
hapi
Member Candidate
Member Candidate
Posts: 222
Joined: Fri Mar 11, 2011 11:21 am
Location: Czech Republic

Re: Significant improvement for wireless Nv2 PtMP

Wed Apr 11, 2018 9:12 am

TDMA: 3ms
Cell radius: 10km
Mode: dynamic downlink
Queue Count: 2
Channel width: 20MHz
AP: v6.42rc56
all CPE: v6.41.4

Speed fluctuates regularly. Mainly CPE with CPU 400MHz or less.
TDMA 2, 3, 4, auto.. it does not matter. Same result.

Image
Last edited by hapi on Wed Apr 11, 2018 9:43 am, edited 1 time in total.
 
hapi
Member Candidate
Member Candidate
Posts: 222
Joined: Fri Mar 11, 2011 11:21 am
Location: Czech Republic

Re: Significant improvement for wireless Nv2 PtMP

Wed Apr 11, 2018 9:35 am

When testing speed on a client with a faster CPU, it cuts off the slower client's speed significantly in ratio 1:50!!! bad TDMA
this is not TDMA

Image
 
mistry7
Forum Guru
Forum Guru
Posts: 1280
Joined: Tue Oct 13, 2009 11:57 am
Location: Germany

Re: Significant improvement for wireless Nv2 PtMP

Wed Apr 11, 2018 11:25 am

When testing speed on a client with a faster CPU, it cuts off the slower client's speed significantly in ratio 1:50!!! bad TDMA
this is not TDMA

Image

I rolled back my Test AP because of users complaining about Voice quality, this could be the reason.....
 
User avatar
nichky
Long time Member
Long time Member
Posts: 522
Joined: Tue Jun 23, 2015 2:35 pm

Re: Significant improvement for wireless Nv2 PtMP

Wed Apr 11, 2018 11:47 am

If i will switch to sync master how will NV2 respond like dynamic downlink or fixed downlink or something else.

Thanks
Nikola Suminoski
MikroTik Consultan
MTCRE l MTCWE

!) Safe Mode is your friend;
 
hapi
Member Candidate
Member Candidate
Posts: 222
Joined: Fri Mar 11, 2011 11:21 am
Location: Czech Republic

Re: Significant improvement for wireless Nv2 PtMP

Wed Apr 11, 2018 11:59 am

random stop traffic. Top speed is excellent but speed fluctuates is tragic.

Image
 
hapi
Member Candidate
Member Candidate
Posts: 222
Joined: Fri Mar 11, 2011 11:21 am
Location: Czech Republic

Re: Significant improvement for wireless Nv2 PtMP

Wed Apr 11, 2018 12:13 pm

NV2 is still very bad.

802.11:
Image

nv2 2ms dynamic:
Image
 
n21roadie
Forum Guru
Forum Guru
Posts: 1887
Joined: Fri Aug 07, 2009 10:36 pm
Location: Limerick,Ireland

Re: Significant improvement for wireless Nv2 PtMP

Wed Apr 11, 2018 4:12 pm

TDMA: 3ms
Cell radius: 10km
Mode: dynamic downlink
Queue Count: 2
Channel width: 20MHz
AP: v6.42rc56
all CPE: v6.41.4

Speed fluctuates regularly. Mainly CPE with CPU 400MHz or less.
TDMA 2, 3, 4, auto.. it does not matter. Same result.

@ hapi Just looking at your clients CCQ and they are terrible ! Are you using default or set data rates?
 
hapi
Member Candidate
Member Candidate
Posts: 222
Joined: Fri Mar 11, 2011 11:21 am
Location: Czech Republic

Re: Significant improvement for wireless Nv2 PtMP

Wed Apr 11, 2018 4:14 pm

they are not terrible. They are terrible because the NV2 without the load does not show the correct ccq. The loaded client has CCQ OK. And it's also seen that NV2 goes CCQ down, but the 802.11 holds up.

You do not talk to a beginner.
 
n21roadie
Forum Guru
Forum Guru
Posts: 1887
Joined: Fri Aug 07, 2009 10:36 pm
Location: Limerick,Ireland

Re: Significant improvement for wireless Nv2 PtMP

Wed Apr 11, 2018 4:21 pm

NV2 is still very bad.

802.11:

nv2 2ms dynamic:
@ hapi Sorry for this but those very high signals ( -22,......) could be overloading wireless input stages and it appears in this situation that 802.11 is more tolerant than NV2?
 
hapi
Member Candidate
Member Candidate
Posts: 222
Joined: Fri Mar 11, 2011 11:21 am
Location: Czech Republic

Re: Significant improvement for wireless Nv2 PtMP

Wed Apr 11, 2018 5:49 pm

Your theory? nonsense. We also have an AP with better signals and even if there is a weaker client and is alone on the AP. Do not worry about things. This is not the only place where the same thing happens. NV2 has always been worse with many clients. Otherwise it behaves with v6.40 in the same place. With the new NV2 it behaves better, but not so good still. And classic nstreme can do better work at this point, but it does not reach UBNT yet.
 
n21roadie
Forum Guru
Forum Guru
Posts: 1887
Joined: Fri Aug 07, 2009 10:36 pm
Location: Limerick,Ireland

Re: Significant improvement for wireless Nv2 PtMP

Wed Apr 11, 2018 9:09 pm

Your theory? nonsense. We also have an AP with better signals and even if there is a weaker client and is alone on the AP. Do not worry about things. This is not the only place where the same thing happens. NV2 has always been worse with many clients. Otherwise it behaves with v6.40 in the same place. With the new NV2 it behaves better, but not so good still. And classic nstreme can do better work at this point, but it does not reach UBNT yet.
After a very quick search -please read the following to support my "Theory"
https://community.ubnt.com/t5/airMAX-Wi ... d-p/188574

https://community.ubnt.com/t5/airMAX-Ge ... d-p/197202

Could I suggest as a test as you have issues NV2 (and for our network NV2 is very stable - but getting more throughput is always a challenge)
Have you tried to lower AP power by entering +db number in "Antenna Gain" and try to get client signals in the 50-65 dbm range and test NV2 ?
 
hapi
Member Candidate
Member Candidate
Posts: 222
Joined: Fri Mar 11, 2011 11:21 am
Location: Czech Republic

Re: Significant improvement for wireless Nv2 PtMP

Wed Apr 11, 2018 10:55 pm

50-65 dB is low. The world does not know what the conditions are in the Czech Republic. -65dB is almost the level of ambient noise.

I'm not going to solve the RX levels unless you do it yourself. We also have PTP connections with -20dB. You can test + 5dB on your desk and it works fine. The wifi chipset's full-speed readiness is + -75dB. Against -60dB it is only 15dB spacing.

As I said, the results are the same in other locations where signals are around -50dB.
 
WirelessRudy
Forum Guru
Forum Guru
Posts: 3082
Joined: Tue Aug 08, 2006 5:54 pm
Location: Spain

Re: Significant improvement for wireless Nv2 PtMP

Thu Apr 12, 2018 1:38 am

Your theory? nonsense. We also have an AP with better signals and even if there is a weaker client and is alone on the AP. Do not worry about things. This is not the only place where the same thing happens. NV2 has always been worse with many clients. Otherwise it behaves with v6.40 in the same place. With the new NV2 it behaves better, but not so good still. And classic nstreme can do better work at this point, but it does not reach UBNT yet.
I'll guess every network has its characteristics. NV2 is designed to overcome problems in P2manyP networks. So it would be a complete failure if that would not be the case. And since most in Mikrotik land claim it does work better than plain 802.11 I think your statement of NV2 not being so good at all bears little fundament.
TDMA is especially designed to give each associated station a fair part of the radio time compared to its need to send or receive data. In 802.11 basically all radio's fight for airtime with AP and if then some of those CPE's can't even 'hear' each-other we get the 'hidden-node' issue on top of it.

In my opinion, when 802.11 is extended to an 'always-on' RTS/CTS addition (A compulsory add-on for IEEE wifi but disabled by default) in a high client number network where there is no more than 3-6dB signal differences between clients this network can outdo a tdma network in low usage networks. With tdma such a network would wast airtime in slots to clients that actually not use it. Overhead.

When the amount of aggregated traffic goes up between all client theoretically there will be moment that tdma should take the upper hand since each station gets its turn in a proper way and the overhead 'loss' wil be compensated by the more orderly processing of client's traffic.
802.11 in heavy used high client number network will start to waste too much 'negotiating' time (=overhead) that increased with the amount of traffic and the amount of stations fighting for airtime.

I have had a network with 60 SXT-5n devices on a Mimosa AP and it worked very good. 1, 2 up to 4/5 clients could easily reach 100-150mbps of speeds (MT bandwidth test, tcp).
I never tried such a big network on a Netmetal Omnitik but even with smaller networks I could never even reach 80Mbps.

Now I have one Netmetal running 29 mix of Mikrotik devices that runs on 802.11an because it just performs much better then with NV2. But this is like the Mimosa test network, a network with relative low usage. If I see 50Mbps aggregated throughput (clients have 25Mb contracts) I would call that "busy".
Same with the Mimosa, even with 64 clients I hardly ever saw more then 50Mb of aggregated client traffic.

But I have an other network that are much more heavily used and also see much more adjacent channel interference. Here tdma (NV2) is always a winner... (So far, now I have an 29 user AP with latest NV2 improvements but in NV2 it sucks.... I need to try 802.11)

Over the 15 years working with Mikrotik I tried several times nstreme and to be honest never got good results. And we tried all possible variables but it just never worked. Recently I tried again on both some P2MP and 3 backhauls. Only one backhaul showed better results in nstreme. All other tests saw either NV2 a winner or 802.11.

THE big improvement in NV2 is the downlink/uplink ratio setting. That works well, even in backhaul scenarios. If you have a link that could hardly cope with the capacity in one direction due all kind of factors. Set a ratio and suddenly it works much better! In some P2MP networks I tried I also saw some improvement. But in some other nothing at all....

Another big help is that the newer generation CPE's have much better perfoming CPU's and better radio's so here is some to gain as well....

The bottom line is; there is no simple 'one fits all' solution. Every P2MP, every backhaul has to be tested and tested and run with live traffic to see what is the best solution.
Together with the tenths of variables this meas a lengthily process and every config change brings it all down so your clients are not happy.

This is where Mikrotik really lacks improvements in the wireless. We could do with tools to change settings 'on the fly' wherever possible and the need to run a proper spectral scan, also on 'ac' devices! This is a real shortcoming! (MT should buit a second radio in each CPE. Like they did with the SXT-ac but that 2nd one is 2.4Ghz. Who wants that??? Make it 5Ghz! an only! So we can run a spectral scan while the unit still runs. And with a filter that could filter out the AP' frequency. Mimosa can do that. Why not MT?)
Show your appreciation of this post by giving me Karma! Thanks.

Rudy R. Puister

WISP operator based on MT routerboard & ROS.
 
hapi
Member Candidate
Member Candidate
Posts: 222
Joined: Fri Mar 11, 2011 11:21 am
Location: Czech Republic

Re: Significant improvement for wireless Nv2 PtMP

Thu Apr 12, 2018 1:54 am

Your theory? nonsense. We also have an AP with better signals and even if there is a weaker client and is alone on the AP. Do not worry about things. This is not the only place where the same thing happens. NV2 has always been worse with many clients. Otherwise it behaves with v6.40 in the same place. With the new NV2 it behaves better, but not so good still. And classic nstreme can do better work at this point, but it does not reach UBNT yet.
NV2 is designed to overcome problems in P2manyP networks. So it would be a complete failure if that would not be the case.

viewtopic.php?f=21&t=132181#p649247

And this is what? This is complete failure.

I do not want to talk about how bad it is. I show how NV2 is in a difficult environment. This is the meaning of this thread. If I have to go to 802.11, it does not make sense for us to use MIKROTIK because 802.11 can also be another manufacturer that currently works on MIKROTIK much better than their own protocols.
 
WirelessRudy
Forum Guru
Forum Guru
Posts: 3082
Joined: Tue Aug 08, 2006 5:54 pm
Location: Spain

Re: Significant improvement for wireless Nv2 PtMP

Thu Apr 12, 2018 2:13 am

50-65 dB is low. The world does not know what the conditions are in the Czech Republic. -65dB is almost the level of ambient noise.

I'm not going to solve the RX levels unless you do it yourself. We also have PTP connections with -20dB. You can test + 5dB on your desk and it works fine. The wifi chipset's full-speed readiness is + -75dB. Against -60dB it is only 15dB spacing.

As I said, the results are the same in other locations where signals are around -50dB.
Experiences over the years and trying to get the higher signal levels so we can get the higher speeds to the clients I sort of distilled the following:

Up to -25dBm signal is not hurting receiving radios, but I'd prefer never to go better then -30dBm. We only had one link that we really needed a high througput on a 40Mhz channel which in 'n' could only be achieved with -25dBm signals on both ends....


Could we run -70 to -80 in the 'old' days with little interference and demand, now I find -60 is about the limit for P2MP networks. We do have some clients that are still above that but we try to do our best in changing AP, bigger antenna etc. to get that client below -60dBm
Ideally in the country side where we want to deliver 20 to 50Mbps to the clients we try to get signals towards -50dBm, at least better then -55dBm and -60dBm the absolute minimum for new installations.

In a urban environment with competition of fibre, we have a smaller cell setup. Clients no more then 500 meters away from AP. And all signals around -40dBm to get at least 60dB SN ratio to get to the highest MCS rates. (And to bring 100Mbps to the client you still need 40Mhz wide channel....)

If we'd take in aspect that the noise floor level is usually between -100 and -115 a signal of -40dBm is really needed to get to the higher MCS rates. (MCS14 and higher)
For 50Mb throughput you already need MCS13 as a minimum in a 20Mhz wide channel band. Since signals and thus rates always fluctuate we need some margin too and for the loss data due re-sending of packages (I'd rarely see 100% CCQ) we have even more losses. So MCS14 or higher is needed which means we are always trying to get a SNR of 45 or better. (100 - 45 gives a signal of -55dBm)
To get more than 50Mbps you already need 40Mhz channels or higher or even higher MCS ('ac') rates (thus signal) in 20Mhz. Meaning signals better then -50dBm.

http://www.revolutionwifi.net/revolutio ... pping.html
Show your appreciation of this post by giving me Karma! Thanks.

Rudy R. Puister

WISP operator based on MT routerboard & ROS.
 
0ldman
Forum Guru
Forum Guru
Posts: 1445
Joined: Thu Jul 27, 2006 5:01 am

Re: Significant improvement for wireless Nv2 PtMP

Thu Apr 12, 2018 8:31 am

Generally you can't get full modulation with signals stronger than a -38 in my experience.

If it is requiring -20s to work in your area you might want to find another frequency or line of work. That is utterly horrible. The actual chipset is designed for like -40 to -97dB. You're usually running into issues in the -40s with A/BG, N can handle it better and AC can actually use it.

Mikrotik in 802.11 mode still has roughly 10dB better receive sensitivity than any other hardware I've used. UBNT drops out around -77, when the weather gets bad I've got a few customers that still browse at -88. There are reasons aside from nv2 to use MT.
 
WirelessRudy
Forum Guru
Forum Guru
Posts: 3082
Joined: Tue Aug 08, 2006 5:54 pm
Location: Spain

Re: Significant improvement for wireless Nv2 PtMP

Thu Apr 12, 2018 12:29 pm

Generally you can't get full modulation with signals stronger than a -38 in my experience.

If it is requiring -20s to work in your area you might want to find another frequency or line of work. That is utterly horrible. The actual chipset is designed for like -40 to -97dB. You're usually running into issues in the -40s with A/BG, N can handle it better and AC can actually use it.

Mikrotik in 802.11 mode still has roughly 10dB better receive sensitivity than any other hardware I've used. UBNT drops out around -77, when the weather gets bad I've got a few customers that still browse at -88. There are reasons aside from nv2 to use MT.
What do you mean with "full modulation"?

One of my main links that served now as a backup to a 60Ghz link, but served as main for some years always runs absolutely fine with -30dBm. In fact when it was a main backhaul that needed to transport up to 200Mb real traffic of clients we had it run in -25dBm levels. 802.11'n' with NV2. Always worked fine with speeds running at times close to this 200Mbps and ping times of 2 up to maybe 15 or 15ms when fully utilised. Lowering the output (we tested that several times) only brought the MCS down and thus the maximum throughput.)
Now this link only serves of a fall back in case the 60Ghz Metrolinq goes down so we tuned power somewhat down not to bombard our towers on both ends with too much signals...

Like I said, in the 'old' days when people where happy enough to send a mail or arrange a flight ticket or go to their online banking with a signal -80 they would still get a service. Now my AP's are much more saturated because we have more clients and each clients has more traffic demand and also want it faster. At the same time we have some 40 5Ghz Wifi APs's in a region where 8-10 years ago there were only 10 you'd can imaging how the spectrum looks....
If you now would have one client with -80, or even -70 that tries his IPTV to work he brings the whole P2MP network to a standstill! This client needs to be upgrade to better gain antena to bring him much closer to -50's..... Sometimes we just can't make it better and we loose the client. (How do we explain a client that had for years internet from us now we just can't get his service anymore like he'd wanted? We hate to loose a client, he hates it to be let down....)
It's just like driving an old T-Ford for commuting 100km on a daily base. Could the commute 20km on a weekly base absolutely fine 70 years ago, If today the commuter and the traffic department would have to deal with T-Fords, traffic would be a disaster....... So we give them better cars, and make better roads and what do we get? Wining people because they are still in a traffic jam.... These people tend to forget the mileage done daily on the road network is some 1000 times higher then 70 years ago..... Like internet traffic is probably 1000 times higher then 8-10 years ago.....

Working with signals in the -60 to -80 range is nowadays only possible in real remote areas where there is hardly any other Wifi around and demand is small.....
Show your appreciation of this post by giving me Karma! Thanks.

Rudy R. Puister

WISP operator based on MT routerboard & ROS.
 
taduikis
Member
Member
Posts: 423
Joined: Sat Jul 07, 2007 12:09 pm

Re: Significant improvement for wireless Nv2 PtMP

Thu Apr 12, 2018 3:23 pm

No wonder everyone is complaining and whining about poor WiFi performance.. signals of -20 dBm.. sweet jesus.. help me live through this madness..
 
0ldman
Forum Guru
Forum Guru
Posts: 1445
Joined: Thu Jul 27, 2006 5:01 am

Re: Significant improvement for wireless Nv2 PtMP

Thu Apr 12, 2018 7:12 pm

Full modulation, max speed, highest modulation.

Not trying to offend, but English isn't your first language, is it? Just trying to figure out how that isn't clearly understood.

I haven't pushed the AC limits in testing like I have the other hardware, I have tested 802.11n and below quite thoroughly, any receive signal stronger than around -38 shows a drop in performance. It is like someone sitting beside you talking with a megaphone, you hear it, but it is overpowering your ear's, it is distorting the receiver, essentially. They have a designed range to work, roughly -40 to -97 or so.
 
WirelessRudy
Forum Guru
Forum Guru
Posts: 3082
Joined: Tue Aug 08, 2006 5:54 pm
Location: Spain

Re: Significant improvement for wireless Nv2 PtMP

Thu Apr 12, 2018 8:06 pm

Full modulation, max speed, highest modulation.

Not trying to offend, but English isn't your first language, is it? Just trying to figure out how that isn't clearly understood.

I haven't pushed the AC limits in testing like I have the other hardware, I have tested 802.11n and below quite thoroughly, any receive signal stronger than around -38 shows a drop in performance. It is like someone sitting beside you talking with a megaphone, you hear it, but it is overpowering your ear's, it is distorting the receiver, essentially. They have a designed range to work, roughly -40 to -97 or so.
My English isn't my first language no, but it is coming close. After 45 years working in an English environment I think it's not so bad. ;-)
But even if you would have written it in Dutch, (my native language, "modulation" = "modulatie") I would still asked you the same.......

This forum is filled with mainly not so technically funded people and only a handful of experts at best. The average remarks are not from the last group hence I'd asked the question since it was not completely clear to me what you'd mend by it. what you'd refer to as "modulation" is what we usually use in "connection rate". It's the same but heho, sometimes we have some tunnel vision...

In my experience at times links or P2MP connections won't reach the highest modulations with signals of -40 or worse. Basically it's all about S/N ratio. If you have overlapping or side channel interference that hits your radio with -70 or -60 or even -55! (Yes that happens, and NO, that cannot always be avoided...) the only way to still get relative high connection rates is to crank up the absolute signal. And I never experienced real issues with -30 signal. Yes, -25 is getting my eyebrows lifted and stronger would give me serious doubts. But -30 is sometimes needed to get a high rate, and in some instances my clients are that close to a tower it becomes almost impossible to reduce the signal. I do have some SXT's that receive with -24 from tower. Even if they are turned around they still get -30! But then the CCQ drops to very low regions and the client has no more service.
Pointing up? Well, if 180 turn won't help, a facing to heaven doesn't neither.
And the bottom line is, the client has high speed and the network or the AP doesn't seem to suffer from it. It's one of our best performing networks! (30 clients, 40Mhz wide band and people can browse with up to 60mbps. A single client has a higher contract to go to 100mbps and doesn't wine....
Show your appreciation of this post by giving me Karma! Thanks.

Rudy R. Puister

WISP operator based on MT routerboard & ROS.
 
WirelessRudy
Forum Guru
Forum Guru
Posts: 3082
Joined: Tue Aug 08, 2006 5:54 pm
Location: Spain

Re: Significant improvement for wireless Nv2 PtMP

Thu Apr 12, 2018 8:15 pm

In addition to my last remarks:
To stay away of interference from other sources we tend to use high gain directional antenas on most of our links. But the result is also we increase the signals a lot.
We have been playing before 2 Jirious 30dBi disks on a 350 meter link just to get a link going in a spectrum full in use. But we had to tune down the radio to very low output to make a -40 signal. Basically we talk 4 or 6 dBm. We actually found that the links became unstable. On other occasions where we had the same issue we found that most Mikrotik devices don't like it when we set outpot lower than some 10 dBm.
Use lesser gain antenna's? Well, but then we spread the signal over our area and it starts hurting other units.... Shielding is focus is gain. Less gain but high focus is something that doesn't seem to exist.
Sometimes its a puzzle. (And it is not for no reason we were probably one of the first that used Metrolinq's 60Ghz solution to bridge these short distances in Spain... ;-) Now the 5Ghz is only a backup.)
Show your appreciation of this post by giving me Karma! Thanks.

Rudy R. Puister

WISP operator based on MT routerboard & ROS.
 
0ldman
Forum Guru
Forum Guru
Posts: 1445
Joined: Thu Jul 27, 2006 5:01 am

Re: Significant improvement for wireless Nv2 PtMP

Thu Apr 12, 2018 9:50 pm

Gotcha.

I guess the phrase "your mileage may vary" applies here.

I've seen -20s on my old hardware from it's next door neighbors (my other hardware on the tower) and I've taken steps to change that. My average neighbor signal is now -65 to -75 (shielding, shielding, shielding). On the old 802.11a/g hardware you couldn't even get anything to connect properly if the neighbor picked up at a -20 even on a channel 200mhz away.

I don't see how our experiences are so vastly different, but I'm not going to argue, just going to make allowances for strange things.

Whatever works for you, but I can't do that here in testing. When I connect two SXT 2 or SXT 5 @ -28 the max modulation I can get is 54mbps and throughput is garbage, CCQ is horrible, etc. I even see that in the field, some of my customers want wireless but they set their computer on the same desk as their router, pull a -35 and complain about speeds. I tell them to move the computer and all is well.

It is very odd.
 
n21roadie
Forum Guru
Forum Guru
Posts: 1887
Joined: Fri Aug 07, 2009 10:36 pm
Location: Limerick,Ireland

Re: Significant improvement for wireless Nv2 PtMP

Thu Apr 12, 2018 10:28 pm

50-65 dB is low. The world does not know what the conditions are in the Czech Republic. -65dB is almost the level of ambient noise.

I'm not going to solve the RX levels unless you do it yourself. We also have PTP connections with -20dB. You can test + 5dB on your desk and it works fine. The wifi chipset's full-speed readiness is + -75dB. Against -60dB it is only 15dB spacing.

As I said, the results are the same in other locations where signals are around -50dB.
It must be very frustrating trying to work with that ambient noise level !
I am sure you have already tried re-locating PTP's and AP's + CPE's that are effected the most to where interference is reduced ?
 
n21roadie
Forum Guru
Forum Guru
Posts: 1887
Joined: Fri Aug 07, 2009 10:36 pm
Location: Limerick,Ireland

Re: Significant improvement for wireless Nv2 PtMP

Thu Apr 12, 2018 10:31 pm

.................... But we had to tune down the radio to very low output to make a -40 signal. Basically we talk 4 or 6 dBm. We actually found that the links became unstable. On other occasions where we had the same issue we found that most Mikrotik devices don't like it when we set outpot lower than some 10 dBm.
......................
Can I ask if output power was above 10dBm were the links stable?
 
WirelessRudy
Forum Guru
Forum Guru
Posts: 3082
Joined: Tue Aug 08, 2006 5:54 pm
Location: Spain

Re: Significant improvement for wireless Nv2 PtMP

Fri Apr 13, 2018 3:01 am

.................... But we had to tune down the radio to very low output to make a -40 signal. Basically we talk 4 or 6 dBm. We actually found that the links became unstable. On other occasions where we had the same issue we found that most Mikrotik devices don't like it when we set outpot lower than some 10 dBm.
......................
Can I ask if output power was above 10dBm were the links stable?
Yes, with higher output they were fine. This were SXT-HG-n units we took away now we have the 60Ghz link running.
But I saw similar on some SXT-Lites that were very close to a tower. It was better to have it hit the tower with -25 and it's output somewhere around 10dB while if we set the output lower the connection rates started to jump up and down resulting in more un-stable ping.

But this is all info from some 2-3 years ago. Maybe it's not that bad any more with the newer devices...
Show your appreciation of this post by giving me Karma! Thanks.

Rudy R. Puister

WISP operator based on MT routerboard & ROS.
 
Zod
Frequent Visitor
Frequent Visitor
Posts: 91
Joined: Mon Apr 23, 2012 11:02 pm

Re: Significant improvement for wireless Nv2 PtMP

Fri Apr 13, 2018 10:46 pm

I tried this code on a 5Ghz RB411GL that is an AP bridge with 11 connected CPE. 10 of those are regular clients. The other one is feeding a small repeater. SNR on all CPE is 37dB or more. Most CCQ are 80/80 or better, there are two that are around 50/50

All CPE are running station-WDS ROS Version 6.39.1
TDMA Period Size 3ms 10km
QoS Default
Queuecount 2
Dynamic downlink 75%
HW rertries from 3 to 7

Here is what I saw:

Befor the upgrade this radio maxed out at about 40Mbps real traffic every night. It should be replaced but there is a very rigid reason why that cannot happen.

So before the upgrade I started up 15 bw tests from 15 CPE's 7 of which were connected to this radio and 8 were on the repeater behind it to the CCR on the backhaul, using TCP and 20 conns.

Before the upgrade the BandWidth Test tool showed about 50Mbps. After upgrade with Retries at 3, the BW Test showed 97Mbps! with no packet loss. Awesome!

BUT that evening when real traffic reached ~59Mbps packet loss was over 25% and jitter was up to 250 ms!!

I increased Retries to 5 and BW Test throughput came down to 67Mbps AND Real world traffic reached ~50Mbps with packet loss at 5%, jitter was still bad at up to 200ms!

I have now increased retries to 7 and BW Test shows about 55 Mbps. I won't know what real world traffic looks like for a few more hours yet but so far this has not produced any measurable result for this case.

I recall that WDS impacted NStreme throughput at one point - could that be the cause for the very high Packet Loss and poor performance ?

Z
 
planetcaravan
Member Candidate
Member Candidate
Posts: 259
Joined: Tue Aug 25, 2009 5:33 pm

Re: Significant improvement for wireless Nv2 PtMP

Wed Apr 18, 2018 1:07 pm

I've updated 3 x 921UAGS-5SHPacD to 6.42 using:

Band: A/N
Channel: 20 MHz
NV2 with 50 downlink ratio

I've noticed a big increase on WLAN throughput
 
mistry7
Forum Guru
Forum Guru
Posts: 1280
Joined: Tue Oct 13, 2009 11:57 am
Location: Germany

Re: Significant improvement for wireless Nv2 PtMP

Wed Apr 18, 2018 2:05 pm

I've updated 3 x 921UAGS-5SHPacD to 6.42 using:

Band: A/N
Channel: 20 MHz
NV2 with 50 downlink ratio

I've noticed a big increase on WLAN throughput
please check your latency
Do you deliver voice service?
 
planetcaravan
Member Candidate
Member Candidate
Posts: 259
Joined: Tue Aug 25, 2009 5:33 pm

Re: Significant improvement for wireless Nv2 PtMP

Wed Apr 18, 2018 4:02 pm

Latency seems to be remains the same as before
Yes, I deliver voice service
 
jonmansey
Frequent Visitor
Frequent Visitor
Posts: 69
Joined: Sat Sep 18, 2004 3:43 am

Re: Significant improvement for wireless Nv2 PtMP

Sat Apr 21, 2018 8:12 am

Add me to the list of disasters with the 6.42. I also have an OmniTik 5HnD. With 6.42 running nv2 with about 15 SXT5 lite clients, the ping time went crazy, super jittery with a lot of timeouts, plus I couldn't maintain a winbox connection to the SXTs, winbox file transfers kept failing and overall throughput fell significantly.

I ended up needing to use nstreme to get the network stable again. Downgrading back to 6.41.4 nv2 would have been an option too. I tried tdma timeout 2ms and auto, tried dynamic and fixed, tried adaptive noise immunity on and off, no change. I do have radar nearby and tried multiple channels, all with similar results.

Are we starting to see a pattern with OmniTik not working right under 6.42 nv2? Anyone with an OmniTik PtMP get the expected success and improvement with 6.42?
 
hapi
Member Candidate
Member Candidate
Posts: 222
Joined: Fri Mar 11, 2011 11:21 am
Location: Czech Republic

Re: Significant improvement for wireless Nv2 PtMP

Sat Apr 21, 2018 8:41 am

not everyone. :-(
 
mistry7
Forum Guru
Forum Guru
Posts: 1280
Joined: Tue Oct 13, 2009 11:57 am
Location: Germany

Re: Significant improvement for wireless Nv2 PtMP

Sat Apr 21, 2018 8:59 am

the ping time went crazy, super jittery with a lot of timeouts

We saw the same on RB922, not possible for voice service, to much jitter
We go back to 6.41.4 and everything fine
 
human1982
newbie
Posts: 29
Joined: Thu Aug 13, 2015 2:36 am

Re: Significant improvement for wireless Nv2 PtMP

Sat Apr 21, 2018 10:41 am

Add me to the list of disasters with the 6.42. I also have an OmniTik 5HnD. With 6.42 running nv2 with about 15 SXT5 lite clients, the ping time went crazy, super jittery with a lot of timeouts, plus I couldn't maintain a winbox connection to the SXTs, winbox file transfers kept failing and overall throughput fell significantly.

I ended up needing to use nstreme to get the network stable again. Downgrading back to 6.41.4 nv2 would have been an option too. I tried tdma timeout 2ms and auto, tried dynamic and fixed, tried adaptive noise immunity on and off, no change. I do have radar nearby and tried multiple channels, all with similar results.

Are we starting to see a pattern with OmniTik not working right under 6.42 nv2? Anyone with an OmniTik PtMP get the expected success and improvement with 6.42?
Try period auto mcs auto hw-retries 10 dynamic downlink cell 10 Guard long. If u also upgraded stations check noise floor on them. Some 711 (random and in 802.11 work fine!) noise floor need to be set manually to -105 -100... Re
 
WirelessRudy
Forum Guru
Forum Guru
Posts: 3082
Joined: Tue Aug 08, 2006 5:54 pm
Location: Spain

Re: Significant improvement for wireless Nv2 PtMP

Sun Apr 22, 2018 9:10 pm

AP side; NetMetal on 24dBi Jirious. Full 30dBm power
Client side; LHG-5acXL Full 27dBm power. ROS v6.42rc29

Link is 6km and signal on the AP is -50/-51dBm
Bandwidth of the channel is 40Mhz wide and we've set the rates fixed for MCS7 (ac) and on each protocol and each setting we have a stable 270Mbps rate with 90% or higher CCQ.

First we decide which protocol is the best. On each protocol we tried several setting in that protocol (ANI, RTS/CTS, Framer policy, tdma period size et.) to get the best setting in the protocol.

We run the bandwidt test from the LHG-ac
(With its powerful 720Mhz CPU it only uses 15% of its capacity)
We run the MT bandwidth test 'from' a CCR that sits behinde the NetMetal. The MT-bandwidth test is run as 'download' towards the LHG and we use single stream tcp.
On the Netmetal we run a small package ping with timeout of 500ms towards an Omnitik that sits behind the LHG (Thus 'through' the LHG).

In any ROS version, and in any test 802.11ac gives by far the best result in throughput.
In NV2 the ping is stabel and low (1-5ms with little variation) where nstreme give pings anywhere between 20 and 80ms. 8021.11 gives ping times that fluctuate heavily, but within a band of 5-30ms.

We tried ROSv 6.40.5, 6.40.7, 6.41.3 and last 6.42

In 6.40.5 we tried all the different protocols and their settings, but 802.11 is winner by far. some 50% faster then NV2 and some 60% faster then nstreme.
IN 6.40.7 and 6.41.3 we only test with the 802.11 protocol and in fact the throughput went down by a couple of MBs after each upgrade. But only 1-2% of the previous tests. (After each upgrade we lost another 2-4Mbps on average. But this could have been withing a fault maring due variable atmospheric influences. I don't know)

Were 6.40.5 had speedtrest running for 10-15 mins without a single drop, all other versions showed drops each 8 - 5 - 3 minutes depending protocol. In 'dropping' I mean for some seconds no traffic was passed.

When finally the NetMetal was upgraded to 6.42 again (+ firmware) we did again the test with all 3 protocols.
But no change here. Still 802.11ac is twice as fast as NV2! (nstreme is still worse then NV2)
The only 'good' thing is we can now set up- and downlink ratio. But we would have to set 100% download (towards LHG) to hope even to get in the neigborhood of the 802.11ac speeds....... I din't even bother to try.....

The only real good thing of the NV2 protocol is the nice low and stable ping times. 2-5ms all the time.

I am shocked to find that the plain 802.11ac protocol is so much better then the Mikrotik NV2. We are talking 100% better here! That is double the speed....
If latency and jitter is not 100% the most important, I would use 802.11ac since the better latency/jitter for our network doesn't weigh up to the immense los in throughput.

I have already some other shorter back hauls were after lengthily tests we decided the 802.11ac gave us the best throughput.
I have also one 33 client P2MP 'n' network where we have almost 30-50% more capacity to single clients as in NV2. (Not a lot of average consumer use. In heavy use P2MP NV2 might still proof better.)
In some other P2MP we still use the NV2 protocol and after the upgrade to 6.42 we set download ratio to 80% and it does give better results for the clients.
In these networks we didn't test for 802.11 protocol since all units have to be prepared to switch seamlessly from NV2 to 802.11ac and vice versa.
We only have two small (<15 clients) P2MP network with all 'ac' units. Here the NV2 protocol works fine, but actually we didn't test 802.11ac.

Most of our backhauls already run either with Airfibre-5X or Mimosa B3 or IgniteNet's 60Ghz solution. The last ones still running on Mikrotik NV2 are now up for a closer look to see if we not better move away from NV2.....
Show your appreciation of this post by giving me Karma! Thanks.

Rudy R. Puister

WISP operator based on MT routerboard & ROS.
 
ste
Forum Guru
Forum Guru
Posts: 1795
Joined: Sun Feb 13, 2005 11:21 pm

Re: Significant improvement for wireless Nv2 PtMP

Sun Apr 22, 2018 9:49 pm

AP side; NetMetal on 24dBi Jirious. Full 30dBm power
Client side; LHG-5acXL Full 27dBm power. ROS v6.42rc29

Link is 6km and signal on the AP is -50/-51dBm
Bandwidth of the channel is 40Mhz wide and we've set the rates fixed for MCS7 (ac) and on each protocol and each setting we have a stable 270Mbps rate with 90% or higher CCQ.

First we decide which protocol is the best. On each protocol we tried several setting in that protocol (ANI, RTS/CTS, Framer policy, tdma period size et.) to get the best setting in the protocol.

We run the bandwidt test from the LHG-ac
(With its powerful 720Mhz CPU it only uses 15% of its capacity)
We run the MT bandwidth test 'from' a CCR that sits behinde the NetMetal. The MT-bandwidth test is run as 'download' towards the LHG and we use single stream tcp.
On the Netmetal we run a small package ping with timeout of 500ms towards an Omnitik that sits behind the LHG (Thus 'through' the LHG).

In any ROS version, and in any test 802.11ac gives by far the best result in throughput.
In NV2 the ping is stabel and low (1-5ms with little variation) where nstreme give pings anywhere between 20 and 80ms. 8021.11 gives ping times that fluctuate heavily, but within a band of 5-30ms.

We tried ROSv 6.40.5, 6.40.7, 6.41.3 and last 6.42

In 6.40.5 we tried all the different protocols and their settings, but 802.11 is winner by far. some 50% faster then NV2 and some 60% faster then nstreme.
IN 6.40.7 and 6.41.3 we only test with the 802.11 protocol and in fact the throughput went down by a couple of MBs after each upgrade. But only 1-2% of the previous tests. (After each upgrade we lost another 2-4Mbps on average. But this could have been withing a fault maring due variable atmospheric influences. I don't know)

Were 6.40.5 had speedtrest running for 10-15 mins without a single drop, all other versions showed drops each 8 - 5 - 3 minutes depending protocol. In 'dropping' I mean for some seconds no traffic was passed.

When finally the NetMetal was upgraded to 6.42 again (+ firmware) we did again the test with all 3 protocols.
But no change here. Still 802.11ac is twice as fast as NV2! (nstreme is still worse then NV2)
The only 'good' thing is we can now set up- and downlink ratio. But we would have to set 100% download (towards LHG) to hope even to get in the neigborhood of the 802.11ac speeds....... I din't even bother to try.....

The only real good thing of the NV2 protocol is the nice low and stable ping times. 2-5ms all the time.

I am shocked to find that the plain 802.11ac protocol is so much better then the Mikrotik NV2. We are talking 100% better here! That is double the speed....
If latency and jitter is not 100% the most important, I would use 802.11ac since the better latency/jitter for our network doesn't weigh up to the immense los in throughput.

I have already some other shorter back hauls were after lengthily tests we decided the 802.11ac gave us the best throughput.
I have also one 33 client P2MP 'n' network where we have almost 30-50% more capacity to single clients as in NV2. (Not a lot of average consumer use. In heavy use P2MP NV2 might still proof better.)
In some other P2MP we still use the NV2 protocol and after the upgrade to 6.42 we set download ratio to 80% and it does give better results for the clients.
In these networks we didn't test for 802.11 protocol since all units have to be prepared to switch seamlessly from NV2 to 802.11ac and vice versa.
We only have two small (<15 clients) P2MP network with all 'ac' units. Here the NV2 protocol works fine, but actually we didn't test 802.11ac.

Most of our backhauls already run either with Airfibre-5X or Mimosa B3 or IgniteNet's 60Ghz solution. The last ones still running on Mikrotik NV2 are now up for a closer look to see if we not better move away from NV2.....
You are kidding. You have 5X hangin and do this fiddling around with nv2 :-o. I've our first 5XHD hanging so 5X is already old stuff. There is no way I waste a second longer on trying to squeeze nv2 to get a poor link at best. We stay with MT routing and might use the upcoming switches. But wireless ... ages behind !
Just updates some CPEs and learned that I forgot that since a specific ROS Version CPEs only try 2 APs with same SSID. So if they see more they just dont try the other and do not connect. So update means disconnect for some of the CPEs.... I am so bored with this buggy crap eating my time like bread ... Each of this cpes is replaced immediately with working stuff to keep this customer.
 
WirelessRudy
Forum Guru
Forum Guru
Posts: 3082
Joined: Tue Aug 08, 2006 5:54 pm
Location: Spain

Re: Significant improvement for wireless Nv2 PtMP

Mon Apr 23, 2018 11:36 am

You are kidding. You have 5X hangin and do this fiddling around with nv2 :-o. I've our first 5XHD hanging so 5X is already old stuff. There is no way I waste a second longer on trying to squeeze nv2 to get a poor link at best. We stay with MT routing and might use the upcoming switches. But wireless ... ages behind !
The 5X's we have do their job. So budget we have is not spend to replace them. As long as they give us enough bandwidth they are fine...
But we have plenty of smaller backhauls; 1 - 4 km's that need to transport up to 100Mbps. Since all our towers are full and our budget is very limited we'd rather squeeze the max out of Mikrotiks then just buy more Airfibre-X5's. If we'd had the money we'd probably do. (And these units seem to disrupt spectrum more than other solution in and around their working band. A lot of energy is thrown out.)

If I have a backhaul to serve 50 clients that at max. consume 100Mb it simply makes no economics to spend a 1000€ on Airfibers to bridge 2km where NetMetals can do the job for a fraction of the costs.

Just updates some CPEs and learned that I forgot that since a specific ROS Version CPEs only try 2 APs with same SSID. So if they see more they just dont try the other and do not connect. So update means disconnect for some of the CPEs.... I am so bored with this buggy crap eating my time like bread ... Each of this cpes is replaced immediately with working stuff to keep this customer.
Why would you have several CPE's with the same SSID? Every CPE from us is tuned to its AP with its own specific SSID. It also makes it easy to find other AP's in the region if you'd run a scan So it only looks for that SSID only that we know is the nearest or that the scan shows gives the strongest signal. Only in some rare case I set in 'connect list' a second AP with its SSID. So this CPE could go to another easy when the first is overloaded for instance But in reality this is not ideal. That 2nd AP's signal is always worse since we pick the best to tune the CPE at.
I agree that since some versions ago, the first line of the 'connect list' is decisive. Where in the past CPE's could freely pick any AP from the list, now it only searches for the top one. Even if that AP is down, the CPE will make no attempt to connect to the second in the list. I agree that in that respect (and more 'small' issues) ROS definitely didn't bring progress. On the contrary!)
Show your appreciation of this post by giving me Karma! Thanks.

Rudy R. Puister

WISP operator based on MT routerboard & ROS.
 
ste
Forum Guru
Forum Guru
Posts: 1795
Joined: Sun Feb 13, 2005 11:21 pm

Re: Significant improvement for wireless Nv2 PtMP

Mon Apr 23, 2018 11:56 am

You are kidding. You have 5X hangin and do this fiddling around with nv2 :-o. I've our first 5XHD hanging so 5X is already old stuff. There is no way I waste a second longer on trying to squeeze nv2 to get a poor link at best. We stay with MT routing and might use the upcoming switches. But wireless ... ages behind !
The 5X's we have do their job. So budget we have is not spend to replace them. As long as they give us enough bandwidth they are fine...
But we have plenty of smaller backhauls; 1 - 4 km's that need to transport up to 100Mbps. Since all our towers are full and our budget is very limited we'd rather squeeze the max out of Mikrotiks then just buy more Airfibre-X5's. If we'd had the money we'd probably do. (And these units seem to disrupt spectrum more than other solution in and around their working band. A lot of energy is thrown out.)

If I have a backhaul to serve 50 clients that at max. consume 100Mb it simply makes no economics to spend a 1000€ on Airfibers to bridge 2km where NetMetals can do the job for a fraction of the costs.

Just updates some CPEs and learned that I forgot that since a specific ROS Version CPEs only try 2 APs with same SSID. So if they see more they just dont try the other and do not connect. So update means disconnect for some of the CPEs.... I am so bored with this buggy crap eating my time like bread ... Each of this cpes is replaced immediately with working stuff to keep this customer.
Why would you have several CPE's with the same SSID? Every CPE from us is tuned to its AP with its own specific SSID. It also makes it easy to find other AP's in the region if you'd run a scan So it only looks for that SSID only that we know is the nearest or that the scan shows gives the strongest signal. Only in some rare case I set in 'connect list' a second AP with its SSID. So this CPE could go to another easy when the first is overloaded for instance But in reality this is not ideal. That 2nd AP's signal is always worse since we pick the best to tune the CPE at.
I agree that since some versions ago, the first line of the 'connect list' is decisive. Where in the past CPE's could freely pick any AP from the list, now it only searches for the top one. Even if that AP is down, the CPE will make no attempt to connect to the second in the list. I agree that in that respect (and more 'small' issues) ROS definitely didn't bring progress. On the contrary!)
Esp with full towers the limited (expensive) resource is spectrum. So squezing >100MBit out of a 10MHz Channel and reusing the same freq is worth the money. Dont forget your working time to fiddle around. Spending 1000€ to a Networking expert gives not much time to play.
 
uldis
MikroTik Support
MikroTik Support
Topic Author
Posts: 3424
Joined: Mon May 31, 2004 2:55 pm

Re: Significant improvement for wireless Nv2 PtMP

Mon Apr 23, 2018 2:44 pm

Add me to the list of disasters with the 6.42. I also have an OmniTik 5HnD. With 6.42 running nv2 with about 15 SXT5 lite clients, the ping time went crazy, super jittery with a lot of timeouts, plus I couldn't maintain a winbox connection to the SXTs, winbox file transfers kept failing and overall throughput fell significantly.

I ended up needing to use nstreme to get the network stable again. Downgrading back to 6.41.4 nv2 would have been an option too. I tried tdma timeout 2ms and auto, tried dynamic and fixed, tried adaptive noise immunity on and off, no change. I do have radar nearby and tried multiple channels, all with similar results.

Are we starting to see a pattern with OmniTik not working right under 6.42 nv2? Anyone with an OmniTik PtMP get the expected success and improvement with 6.42?
Could you tell us more detailed info on your setup? What is the distance from the SXTs to the OmniTik? Does all the clients suffer from this or only few? which exact SXT models you have as CPEs?
 
WirelessRudy
Forum Guru
Forum Guru
Posts: 3082
Joined: Tue Aug 08, 2006 5:54 pm
Location: Spain

Re: Significant improvement for wireless Nv2 PtMP

Mon Apr 23, 2018 5:48 pm

Esp with full towers the limited (expensive) resource is spectrum. So squezing >100MBit out of a 10MHz Channel and reusing the same freq is worth the money.
Are you talking bits per second or bytes?
I am referring to 100Mbps. That would equal to only 12,5Mega Bits per second (KB/s)

Would be interesting to see someone getting more then 100Mbps real traffic out of a 10Mhz channel. The highest modulation on a dual polarized radio is MCS15 which gives a PHY rate of only 72,2Mbps. Best you could hope for is some 30-35Mbps. That ain't going to work.... For a 20Mhz link this is already almost impossible.

No, we live in a 20km range valley with some 60+ different Wifi transmitting towers. It depends per tower and in which directions antenas are pointed where which frequency gives best results.
For back hauls we use high gain antenas, lots of shielding if possible and basically best antenas we can find for their use. But it is still a daunting task since the competition is also extending and re-arranging their use of frequencies. For P2MP we are still Mikrotik base and all we can do it to bring the signals up to -50dBm levels at least to get reasonable to good S/N ratios.

Just to change towards UBNT (or any other) for our complete network would drain our resources for the next year(s) plus we don't have the manpower to do so. For 80% of the network we are basically 'married' to Mikrotik and a divorce would bring pain and lots of misery. We probably won't survive it.....
Hence we just keep rowing with the oars we have and try to get the best speed out of the Mikrotik boat without changing it. (After all, who says the competition is so much better with their stuff? We still get clients coming from them out of grief over their poor internet......)

And if I can get 150-180Mbps tcp throughput out of a Netmetal + LHG link in 40Mhz channel over 6km in 802.11ac mode on a link that for now only needs half of that, why should I spend that 1000€. It will be used somewhere else....

After my 'playing' with mimosa I learned that 802.11ac can be very good indeed taken the finetuning is done properly and distances are not too far. Up to 150-180Mbps per single connected client I have done....
With these lessons in my back of my head I have now a Netmetal running on a 12dBi dual polarized antena with all SXT's ('n) in a 500 meter range and I could already push towards the 100Mbps per client....
So now we are changing these for 'ac' models and I have to see how that will go. If I can 'push' way through the 100Mbps limits and an overal AP throughput of 200Mbps+ then I would be very happy.
Compared to Mimosa I would then save a couple of thousands euros and only get 20% less then what I can achieve with them... (but much better then my ubnt competition!!)
Show your appreciation of this post by giving me Karma! Thanks.

Rudy R. Puister

WISP operator based on MT routerboard & ROS.
 
jonmansey
Frequent Visitor
Frequent Visitor
Posts: 69
Joined: Sat Sep 18, 2004 3:43 am

Re: Significant improvement for wireless Nv2 PtMP

Mon Apr 23, 2018 6:39 pm

Replying to Uldis,

What is the distance from the SXTs to the OmniTik? All under 1km

Does all the clients suffer from this or only few? All

which exact SXT models you have as CPEs? mixture of SXT 5HPnD, 5HnD, 5nD r2, running various 6.40, 6.41 and 6.42

it seems the CPEs lose connectivity for a few seconds, up to 6 or 10 seconds sometimes
 
ste
Forum Guru
Forum Guru
Posts: 1795
Joined: Sun Feb 13, 2005 11:21 pm

Re: Significant improvement for wireless Nv2 PtMP

Mon Apr 23, 2018 11:55 pm

Esp with full towers the limited (expensive) resource is spectrum. So squezing >100MBit out of a 10MHz Channel and reusing the same freq is worth the money.
Are you talking bits per second or bytes?
I am referring to 100Mbps. That would equal to only 12,5Mega Bits per second (KB/s)

Would be interesting to see someone getting more then 100Mbps real traffic out of a 10Mhz channel. The highest modulation on a dual polarized radio is MCS15 which gives a PHY rate of only 72,2Mbps. Best you could hope for is some 30-35Mbps. That ain't going to work.... For a 20Mhz link this is already almost impossible.
My testlink runs 100Mbps UDP (real traffic) aggregated over a 10MHz Channel. MCS15 is a wifi thing ...
40MHz gives 460Mbps.
 
jonmansey
Frequent Visitor
Frequent Visitor
Posts: 69
Joined: Sat Sep 18, 2004 3:43 am

Re: Significant improvement for wireless Nv2 PtMP

Tue Apr 24, 2018 5:24 am

Further testing reveals the problem is caused by any station with ar7240 chipset connecting to omnitik AP running nv2 and 6.42 causes the problem. I noticed in the AP registration table that some stations TX rate was dropping to 6.5Mbps randomly, typically all stations show over 100Mbps tx-rate constantly. I found that all the ones that did this had in common that they were 5HnD or 5HPnD with ar7240 chips. If I move all the ar7240 stations to another sector, the jitter suddenly drops to nice low value, pings to all stations settle at less than 10ms, like nv2 _should_ be working. As soon as I add back one of the ar7240 stations, the jitter gets bad again. I think every time one of these stations has the TX rate drop to 6.5M, it causes disruption to the whole AP affecting all stations.

Odd that the OmniTik itself has a ar7240 chip as the AP, but v6.42 doesn't like ar7240 stations it seems. Hopefully this finding helps fix the issue.
 
hapi
Member Candidate
Member Candidate
Posts: 222
Joined: Fri Mar 11, 2011 11:21 am
Location: Czech Republic

Re: Significant improvement for wireless Nv2 PtMP

Tue Apr 24, 2018 7:40 am

Further testing reveals the problem is caused by any station with ar7240 chipset connecting to omnitik AP running nv2 and 6.42 causes the problem. I noticed in the AP registration table that some stations TX rate was dropping to 6.5Mbps randomly, typically all stations show over 100Mbps tx-rate constantly. I found that all the ones that did this had in common that they were 5HnD or 5HPnD with ar7240 chips. If I move all the ar7240 stations to another sector, the jitter suddenly drops to nice low value, pings to all stations settle at less than 10ms, like nv2 _should_ be working. As soon as I add back one of the ar7240 stations, the jitter gets bad again. I think every time one of these stations has the TX rate drop to 6.5M, it causes disruption to the whole AP affecting all stations.

Odd that the OmniTik itself has a ar7240 chip as the AP, but v6.42 doesn't like ar7240 stations it seems. Hopefully this finding helps fix the issue.

viewtopic.php?f=21&t=132181&start=100#p653489
deja vu?
 
hapi
Member Candidate
Member Candidate
Posts: 222
Joined: Fri Mar 11, 2011 11:21 am
Location: Czech Republic

Re: Significant improvement for wireless Nv2 PtMP

Tue Apr 24, 2018 7:42 am

Replying to Uldis,

What is the distance from the SXTs to the OmniTik? All under 1km

Does all the clients suffer from this or only few? All

which exact SXT models you have as CPEs? mixture of SXT 5HPnD, 5HnD, 5nD r2, running various 6.40, 6.41 and 6.42

it seems the CPEs lose connectivity for a few seconds, up to 6 or 10 seconds sometimes

viewtopic.php?f=21&t=132181&p=656604#p653516
deja vu?
 
jonmansey
Frequent Visitor
Frequent Visitor
Posts: 69
Joined: Sat Sep 18, 2004 3:43 am

Re: Significant improvement for wireless Nv2 PtMP

Tue Apr 24, 2018 7:13 pm

@hapi, I see a couple of ar7240 devices in your registration table there, the ones with 00:0C:42 Mac addresses, try blocking them with access list and see if nv2 clears up.
 
draguzet
Frequent Visitor
Frequent Visitor
Posts: 74
Joined: Fri Jul 01, 2011 10:28 am

Re: Significant improvement for wireless Nv2 PtMP

Wed Apr 25, 2018 12:04 am

What is final conclusion for best practice setup after this update ?
TDMA Period: fiksed 2-3-4 ms or Auto ?
Fixed or Dynamic downlink ?
 
WirelessRudy
Forum Guru
Forum Guru
Posts: 3082
Joined: Tue Aug 08, 2006 5:54 pm
Location: Spain

Re: Significant improvement for wireless Nv2 PtMP

Wed Apr 25, 2018 12:10 am

What is final conclusion for best practice setup after this update ?
TDMA Period: fiksed 2-3-4 ms or Auto ?
Fixed or Dynamic downlink ?
On the networks I tested dynamic download worked best. But tdma period is still not conclusive by me. I tend to use 2ms but don't see a lot of difference between 'auto' or 1 or 2. Higher then 3 brings throughput down...
Show your appreciation of this post by giving me Karma! Thanks.

Rudy R. Puister

WISP operator based on MT routerboard & ROS.
 
WirelessRudy
Forum Guru
Forum Guru
Posts: 3082
Joined: Tue Aug 08, 2006 5:54 pm
Location: Spain

Re: Significant improvement for wireless Nv2 PtMP

Thu Apr 26, 2018 9:06 pm

Just done a test on a NetMetal 5 (921UAGS-5SHPacD) with 28 clients associated that runs on v.6.42.1 and latest firmware.
AP radio is on 'only-N', 20/40MHz Ce, NV2 protocol, some fixed MCS rates, Hw. Retries = 3, 75% dynamic downlink mode and tdma 2ms period size.

I have one client with SEXTANT (v6.41.3) and signal Tx/Rx -52/-50 (from AP; Tx =download) that for hours is downloading with its maximum queue (at remote device) which means 10-25Mbps.

If I try to run a MT throughput test (tcp) from another client that has an LHG-'n' (v6.42.1) and Tx/Rx -55/-60 (read in AP) it starts high with over 15Mbps but drops almost immediate back to 3-5Mbps... and stays there...
When I throw the SEXTANT from the AP by its access list the speed of the LHG immediate jumps back to almost 20Mbps! Do I allow the SEXTANT to associate again and after a while the download runs again the speed of the LHG drops back to the previous 3-56Mbps.

Total throughput of the NetMetal during all the time is 20-35Mbps. I can run a bw test from this AP to remote gateway on single tcp stream and get 150Mbps..... So plenty of capacity available.

As I previously confirmed that the 'significant improvement in NV2' claim by MT was true, now it shows it ain't..... One client prevents others from getting higher speed.
(And this is not because some chipset 'don't like the 6.42 software, since this SEXTANT runs 6.41.3..)

Would be nice if any can confirm similar or have any comments...
Show your appreciation of this post by giving me Karma! Thanks.

Rudy R. Puister

WISP operator based on MT routerboard & ROS.
 
taduikis
Member
Member
Posts: 423
Joined: Sat Jul 07, 2007 12:09 pm

Re: Significant improvement for wireless Nv2 PtMP

Fri Apr 27, 2018 12:06 am

Is that SEXTANT of older generation by chance? I mean 5nD or something..

I've noticed that older gen chipsets perform poorly and also drag down whole AP a little. Also older chipsets don't support Short GI on 20MHz channels. I rotate and replace old 5nD and 5HPnD devices and upgrade to newer ones when possible. Got boxes full of waste 5nD's lying around..
 
0ldman
Forum Guru
Forum Guru
Posts: 1445
Joined: Thu Jul 27, 2006 5:01 am

Re: Significant improvement for wireless Nv2 PtMP

Fri Apr 27, 2018 12:36 am

What is final conclusion for best practice setup after this update ?
TDMA Period: fiksed 2-3-4 ms or Auto ?
Fixed or Dynamic downlink ?
On the networks I tested dynamic download worked best. But tdma period is still not conclusive by me. I tend to use 2ms but don't see a lot of difference between 'auto' or 1 or 2. Higher then 3 brings throughput down...
So far auto seems to work best in my situation.

I have one tower where setting it to 10ms knocks it out of the park. Below that we have issues.

Nstreme and nv2 both seem to be best tuned for each location. There doesn't seem to be a "best practice" aside from tuning each location.
 
WirelessRudy
Forum Guru
Forum Guru
Posts: 3082
Joined: Tue Aug 08, 2006 5:54 pm
Location: Spain

Re: Significant improvement for wireless Nv2 PtMP

Fri Apr 27, 2018 2:14 am

Is that SEXTANT of older generation by chance? I mean 5nD or something..

I've noticed that older gen chipsets perform poorly and also drag down whole AP a little. Also older chipsets don't support Short GI on 20MHz channels. I rotate and replace old 5nD and 5HPnD devices and upgrade to newer ones when possible. Got boxes full of waste 5nD's lying around..
These SEXTANTS are indeed rb911G-5HPnd units.
There are actually 4 of these in that specific network only! And two rb911G-5HnD and two rbSXT 5HPnD and one rbSXT 5HPnD

Are you telling me now I have to replace these all? This AP performs indeed very poor. I have several other P2MP networks were we find similar units.

We are indeed upgrading our networks, but we can only do some 5% per month. So priority was given to units with low signals to higher gain ones so we could increase average levels and thus throughput. But now I should adjust that policy and first start on the 5HPnD and 5PnD models? pffff....
Show your appreciation of this post by giving me Karma! Thanks.

Rudy R. Puister

WISP operator based on MT routerboard & ROS.
 
taduikis
Member
Member
Posts: 423
Joined: Sat Jul 07, 2007 12:09 pm

Re: Significant improvement for wireless Nv2 PtMP

Fri Apr 27, 2018 9:17 am

Well, I cannot guarantee that it’ll do a lot, but at least short GI gives additional capacity by reaching higher datarates on 20MHz. I’ve witnessed performance and user experience/happyness increase numerous times after replacing these 5HnD’s to Lite5, etc. I don’t know how it’s related, but even CCQs are better on newer units (where I got 60-70 with 5HnD, easily >92 on Lite5).

911G-5HnD are indeed good units. They operate very well in SEXTANT-G’s, QRT5’s (non-ac). It might be coincidence, but I really notice that AP’s with all Lite5 CPEs perform better than mixed ones. Might have something to do with airtime wasted on lower datarates..

I don’t suggest you to buy new units for existing clients. We deploy fiber to our clients so get plenty of used Lite5’s to reuse. And slowly replacing old devices with them. We also considered to replace some more quality sensitive network segments to other vendor, so that way even more Lite’s would get freed for reuse..
 
Ginsu
newbie
Posts: 38
Joined: Sat Apr 04, 2009 12:11 am

Re: Significant improvement for wireless Nv2 PtMP

Mon Apr 30, 2018 10:32 pm

The NV2 Improvement is remarkable. The Upload of the clients was crap before 6.42, something that people usally don't understand when you say to them that this affect directly the download of the clients also, because of how TCP connections works (ACK and windows sizing).

Now that upload speeds are correct, and that the use of TDMA period size MEAN something (obtaining more upload at the cost of few ms in latency) we where able to convert almost unusable access points with 30 or 40 clients in something that works ok.

I'm adding a possible failure in the new implementation. The latency goes up when no traffic is passing.. the rates keep up but something wierd happens with latency. I'm afraid that small packets that will generate a small throughput that will not force the link such as gaming or voice chat get higher latency (attached photos) hope you guys could reproduce this and tell my is this is an implementation issue or somehting that you guys don't saw

Congratulations for this improve, I hope you keep going with wireless implementations, this is something that you abandoned for some time.
You do not have the required permissions to view the files attached to this post.
 
n21roadie
Forum Guru
Forum Guru
Posts: 1887
Joined: Fri Aug 07, 2009 10:36 pm
Location: Limerick,Ireland

Re: Significant improvement for wireless Nv2 PtMP

Mon Apr 30, 2018 11:01 pm

.........................

I've noticed that older gen chipsets perform poorly and also drag down whole AP a little. Also older chipsets don't support Short GI on 20MHz channels. I rotate and replace old 5nD and 5HPnD devices and upgrade to newer ones when possible. Got boxes full of waste 5nD's lying around..
This is very interesting comment!
I just wonder when I checked a few boards that the firmware which has factory default of say 3.02 but can be updated, would this improve performance!
RB433AH - ar7100 - 2.23
711-5Hn - ar7240 - 3.02
711-5Hn-MMCX - ar7240 - 2.28
711-5Hn-u.FL - ar7240 - 2.37
911-5Hn - ar9344L - 3.22

Also where can I locate information on guard interval support for each chipset,
 
jonmansey
Frequent Visitor
Frequent Visitor
Posts: 69
Joined: Sat Sep 18, 2004 3:43 am

Re: Significant improvement for wireless Nv2 PtMP

Tue May 01, 2018 4:26 am

@Uldis, so can we expect any kind of fix for this poor station performance under nv2 on ar7240 chips in a future firmware release? Or are we SOL?
 
WirelessRudy
Forum Guru
Forum Guru
Posts: 3082
Joined: Tue Aug 08, 2006 5:54 pm
Location: Spain

Re: Significant improvement for wireless Nv2 PtMP

Tue May 01, 2018 12:49 pm

Well, I cannot guarantee that it’ll do a lot, but at least short GI gives additional capacity by reaching higher datarates on 20MHz.
Off course it will. It reduces some overhead traffic which will payout if you are trying to squeeze the max out of a connection. But if the link has difficult spectral circumstances ( (self-)interference, noise etc.) you will have higher package losses. In the last year we decided to change all P2MP networks from short GI into long to get more stable networks. The CCQ's went up indeed overall. And if the modulation rates are still high enough to deliver the client the speed he is contracted to it's a win-win situation. But on back hauls that just need high throughput we decided to pick the guard interfal to what we thought was best for that specific link.

I’ve witnessed performance and user experience/happyness increase numerous times after replacing these 5HnD’s to Lite5, etc. I don’t know how it’s related, but even CCQs are better on newer units (where I got 60-70 with 5HnD, easily >92 on Lite5).
Could this not also be because newer chipsets have usually better sensitivity, higher CPU speed (=higher capacity to modulate and de-modulate data) and not seldom just better antenas? It's the combination of all I would think.....?

911G-5HnD are indeed good units. They operate very well in SEXTANT-G’s, QRT5’s (non-ac). It might be coincidence, but I really notice that AP’s with all Lite5 CPEs perform better than mixed ones. Might have something to do with airtime wasted on lower datarates..
Well, if the newer antena has better sensitivity and better antena design automatically you get better signal and thus better S/N rates that in return give the radios the option to use higher MCS rates and thus they perform better....
I also must say in this relation that I found many radios/boards already in the field for some years that get replaced by exactly the same unit, but new, give better results too.... Like boards degrade.....

I don’t suggest you to buy new units for existing clients. We deploy fiber to our clients so get plenty of used Lite5’s to reuse. And slowly replacing old devices with them. We also considered to replace some more quality sensitive network segments to other vendor, so that way even more Lite’s would get freed for reuse..
Well, we have to compete in some parts at fiber. We just don't have the resources to start using fiber to our clients, even if it's in the street. But with Mimosa or now the new 60Ghz units of Mikrotik we'd manage to keep our clients and even gain where we lost less then 1 % to the fiber alternative. And they are fanatic in their promotions!
Show your appreciation of this post by giving me Karma! Thanks.

Rudy R. Puister

WISP operator based on MT routerboard & ROS.
 
WirelessRudy
Forum Guru
Forum Guru
Posts: 3082
Joined: Tue Aug 08, 2006 5:54 pm
Location: Spain

Re: Significant improvement for wireless Nv2 PtMP

Tue May 01, 2018 12:52 pm

.........................

I've noticed that older gen chipsets perform poorly and also drag down whole AP a little. Also older chipsets don't support Short GI on 20MHz channels. I rotate and replace old 5nD and 5HPnD devices and upgrade to newer ones when possible. Got boxes full of waste 5nD's lying around..
This is very interesting comment!
I just wonder when I checked a few boards that the firmware which has factory default of say 3.02 but can be updated, would this improve performance!
RB433AH - ar7100 - 2.23
711-5Hn - ar7240 - 3.02
711-5Hn-MMCX - ar7240 - 2.28
711-5Hn-u.FL - ar7240 - 2.37
911-5Hn - ar9344L - 3.22

Also where can I locate information on guard interval support for each chipset,
I always upgrade the fw as well when performing ROS upgrades.... but if it helps. I tend to think it does but have no hard evidence. I also must say the issues of the poor effect of the use of these boards to P2MP networks I'd notice but not to the same extend as other wrote here..... So who knows. At least I don't think it hurts....
Show your appreciation of this post by giving me Karma! Thanks.

Rudy R. Puister

WISP operator based on MT routerboard & ROS.
 
taduikis
Member
Member
Posts: 423
Joined: Sat Jul 07, 2007 12:09 pm

Re: Significant improvement for wireless Nv2 PtMP

Tue May 01, 2018 11:01 pm

Firmware:
As for firmware upgrades, I haven’t noticed any difference in wireless performance. What you call firmware here, to my understanding is a RouterBOOT bootloader, which has nothing to do with device performance after it boots to OS. But MT staff could verify if it has any effect or not.

Older vs newer devices:
I’m not sure, but antenna design is pretty much the same for 5HnD vs Lite5? So newer chipset has definitely got some improvements that affect performance. Regarding CPU - everyone keeps telling that faster CPU yelds better performance. While that might be true for AP, but for CPE 400MHz vs 600MHz wouldn’t make signifcant difference, especially when CPU utilization stays low during even heavy data transfers. Correct me if I’m wrong.

I also can confirm board degradarion theory. I’ve witnessed numerous occasions when poorly performing old 5HnD’s (SEXTANT’s or SXT’s) were replaced with identical unit (but somewhat less worn) immediately performed as before with obvious boost in CCQ and modulation stability. But in my earlier mentioned case it’s not new device vs used. It’s older generation vs newer chipset that gives this significant difference.

Short GI vs Long GI:
Interesting theory there. I’ve never noticed better performance with longer guard intervals. But this actually makes sense, because longer GI should be less prone to interference just as lower modulations are. ROS itself switches to long GI when RF environment gets worse. But I don’t know if manually pinning GI is better than allowing frequent jumping between Long vs. Short.

Nevertheless, I’ll continue replacing old units whatever the reason of this performance improvement is (aging, chipset features, antenna design, etc). In my opinion MT CPEs are quite good and quality units. All we need now is some magic at AP side, which is surely possible as other vendors clearly demonstrated, even with MT CPEs..
 
WirelessRudy
Forum Guru
Forum Guru
Posts: 3082
Joined: Tue Aug 08, 2006 5:54 pm
Location: Spain

Re: Significant improvement for wireless Nv2 PtMP

Wed May 02, 2018 12:48 am

Firmware:
As for firmware upgrades, I haven’t noticed any difference in wireless performance. What you call firmware here, to my understanding is a RouterBOOT bootloader, which has nothing to do with device performance after it boots to OS. But MT staff could verify if it has any effect or not.
To my understanding Firmware (/sys rout ) is 'drivers'. At least that is what has been xplained to me once by some MT guy. It is needed to have all kinds of hardware working with the software. And in writing new drivers the older drivers get updated too. That always has been my understanding but correct me if I am wrong.

Older vs newer devices:
I’m not sure, but antenna design is pretty much the same for 5HnD vs Lite5? So newer chipset has definitely got some improvements that affect performance. Regarding CPU - everyone keeps telling that faster CPU yelds better performance. While that might be true for AP, but for CPE 400MHz vs 600MHz wouldn’t make signifcant difference, especially when CPU utilization stays low during even heavy data transfers. Correct me if I’m wrong.
Well, If I upload a file (for instance a new upgrade ROS) to a new 720Mhz unit or to a 400Mhz device, even if they have the same conn. rate and signal, in the 720Mhz it goes way faster. And this is only a big package of data that has to be written in memory. I am not talking the actual upgrade process. (Or is ti because the newer memory is much faster?)
Also; if you run a bandwidth test 'over' and old 400Mhz device or a new 720Mhz device, the latter shows less cpu usage.
Which would make sense, the radio continuously has to make decisions on the conn. rate and choose 'up' or 'down' one, has to check the checksum of the packages so it was transported 'intact' and ask for a 'resend' if corrupted, receive and proces tdma time stamps and send/receive windows and encrypt or decrypt the data that is send over the wireless link. That's all work to be done each data frame again, over and over.

And since we have the CPE perform the NAT routing it also needs to store all connections ('tracking¡) and replaces src and dst IP all the time for all packages.
For all this work the CPU speed is a factor of importance. 'The faster, the better'.
Data over the wire or wireless is transported with the speed of light. The reason our 'real' data is slowed down considerably compared to the speed of light is the fact it is processed by repeaters, by routers, by radio's etc. So the faster they all work, the less delays we have.
Could this not be the reason 'old' units slow down a NV2 P2MP network if it is test to the max? Would be nice it the MT wizz kids would have some info to share....

Short GI vs Long GI:
Interesting theory there. I’ve never noticed better performance with longer guard intervals. But this actually makes sense, because longer GI should be less prone to interference just as lower modulations are. ROS itself switches to long GI when RF environment gets worse. But I don’t know if manually pinning GI is better than allowing frequent jumping between Long vs. Short.
At least the CPU doesn't have to make that decision anymore. Each and every time GI is changed traffic is halted for a split (m)second. If my modulation rate is high enough for the capacity that is needed, it gives me better CCQ and thus lower latency.

Nevertheless, I’ll continue replacing old units whatever the reason of this performance improvement is (aging, chipset features, antenna design, etc). In my opinion MT CPEs are quite good and quality units. All we need now is some magic at AP side, which is surely possible as other vendors clearly demonstrated, even with MT CPEs..
I can nothing more then to fully agree on this. Apart maybe from the noise shielding* (which in my opinion is better if the transceiver would be placed in the focus of a metal sphere (like ubnt does) these little SXT's, SXT-sq's, SEXTANT's, LHG's and now the DISC's are nice little units that with its versatile ROS can be fine tuned to levels other makers can only dream of. And for a very competitive price!

*Shielding. Once this has been heavily debated here in this forum. Soon after they came with the SXT-SA-ac models that where coated on the inside with anti shielding material. Imho this should be done on ALL SXT's (and other CPE units)
I never understood why they only choose to do the AP's units. If there are interference issues this is prone to be from the tower that has more AP's This usually is within the operator's own capacity to control (relocating units of channels).
CPE's on the other end are out in the field where sometime signals from competitors do more harm. It is not always an option to change a working channel for a P2MP setup only because one or some CPE's are hammered by some competitors AP......I would rather have better shielding here. (Or any other way of noise rejection.)
Mimosa's C5's for instance are shielded and perform so much better in the same area where we previously had SXT's. S/N levels are just higher...
Show your appreciation of this post by giving me Karma! Thanks.

Rudy R. Puister

WISP operator based on MT routerboard & ROS.
 
taduikis
Member
Member
Posts: 423
Joined: Sat Jul 07, 2007 12:09 pm

Re: Significant improvement for wireless Nv2 PtMP

Wed May 02, 2018 9:09 am

I can’t deny nor confirm that RouterBOOT is ‘drivers’. The FWF files were ~40KB in size and had chipset name in filename. Don’t really have an opinion if 40KB is too much for bootcode only. Maybe some experts would shed some more light on this. I’d really like to know, because recently I saved the hassle and skipped firmware upgrades. Especially on CPEs.

Faster uploads to ROS device are more because of different upgrade mechanism they use now. Since introduction of devices with small storage (16M flash) your uploads are going to RAM, not flash. It’s then unpacked, processed and rewritten to permanent storage. Some devices contain flash folder that is used for permanent storage and anything that’s placed outside this folder is in RAM-drive. Otherwise, the reason for faster file uploads are faster flash chip. Faster CPU also contributes to storage speed, IMHO. But I’m not sure if faster CPU is doing anything so special for wireless performance in this case. If some 20-30mbps are passing through the device, with all management, NAT, firewall, etc CPU never gets past 50%. So to my understanding - plenty of resources left? Or this CPU utilization figure doesn’t show all the picture here?

I’ve expressed my opinion on CPE shielding here on this forum long time ago. Indeed SXTs are very far from having ideal antennas. To my opinion beamwidth of 25deg is a little too much, and lack of rear shielding is bad for at least a couple of reasons: picking up unneccessary signals from around (thus lowering SNR) and bleeding noise to rear and sides when this could be avoided. Hundred SXTs in some given area and you have polluted RF environment by yourself however good you plan your AP deployment. Fortunately I comfort myself that other vendors aren’t much better in this matter and since upload with recent tdd feature got somewhat even more limited, self-bleeding isn’t as much of an issue anymore. Lack of shield-spray is probably a cost saving. But I believe only by $1 or so.. It would be interesting to compare ordinary SXT with SXT internals planted to SXT SAs shielded case. Might be we only imagine this shielding would do miracles..

What I’d like to see now is some new RB932UAGS-5HPacD with adjacent channel filtering, MU-MIMO, etc. All other features are possible through ROS upgrades: better nv2 performance, better rate selection algorythms, GPS sync support (USB GPS dongles). I’ve expressed this some time ago and I’m happy some rocks got moved - nv2 got some attention, TDD was introduced, limited sync support (I believe GPS precision timing would help even more). So all possibilities are still here. Only effort is needed now. I did offer some ideas to MT of what can be improved to gain some more speed out of existing equipment. Let’s hope they listen and are willing at least to try..
 
uldis
MikroTik Support
MikroTik Support
Topic Author
Posts: 3424
Joined: Mon May 31, 2004 2:55 pm

Re: Significant improvement for wireless Nv2 PtMP

Wed May 02, 2018 11:40 am

@Uldis, so can we expect any kind of fix for this poor station performance under nv2 on ar7240 chips in a future firmware release? Or are we SOL?
We are still trying to reproduce your setup and at the moment we are unable to do that - it works ok in a room setup.
Maybe you have a test site where the problem is happening then we could do dome remote debugging to understand what setup needs to be made locally to reproduce that problem?
 
n21roadie
Forum Guru
Forum Guru
Posts: 1887
Joined: Fri Aug 07, 2009 10:36 pm
Location: Limerick,Ireland

Re: Significant improvement for wireless Nv2 PtMP

Wed May 02, 2018 12:16 pm

.......................... If some 20-30mbps are passing through the device, with all management, NAT, firewall, etc CPU never gets past 50%. So to my understanding - plenty of resources left? Or this CPU utilization figure doesn’t show all the picture here?
..............................
You maybe correct and a faster CPU is simply processing quicker all the "other stuff" which is running on ROS!
 
HaQs
Member Candidate
Member Candidate
Posts: 153
Joined: Sat Oct 20, 2007 3:26 pm
Location: POLAND

Re: Significant improvement for wireless Nv2 PtMP

Wed May 02, 2018 12:24 pm

nv2 improvments BUG:

Hello i upgraded 300AP :) to ROS 6.42.1 with this package and NV2 improvment have BUG:

Tested on few ap when on ap have 5 to 25 clients:

when traffic is low then ping to all clients is ok / no packet loos.
But when any connected to ap client do start download , then always one or two packet loos on other clients.

example in real:
Traffic on ap is 1-2Mbps , and ping on all clients is ok, jitter ok .
When 1 or more client start download example 10mbps, then other clients loose 1 or 2 packets.

example syntetic:
Traffic on ap is 1-2Mbps , and ping on all clients is ok, jitter ok .
When start bandwitch test to 1 client then when its start then other clients 1 or 2 packet loos.
Always when do start on bandwitchtest always packet loos. (loos only when start, after start packet not loos)

Transfers on clients with this improvments is better but , AP is unusable because clients have freezes in internet games, when any other client on ap start downloading.

when downgraded to 6.40.8 then problem not exist.
 
Ginsu
newbie
Posts: 38
Joined: Sat Apr 04, 2009 12:11 am

Re: Significant improvement for wireless Nv2 PtMP

Wed May 02, 2018 2:55 pm

nv2 improvments BUG:

Hello i upgraded 300AP :) to ROS 6.42.1 with this package and NV2 improvment have BUG:

Tested on few ap when on ap have 5 to 25 clients:

when traffic is low then ping to all clients is ok / no packet loos.
But when any connected to ap client do start download , then always one or two packet loos on other clients.

example in real:
Traffic on ap is 1-2Mbps , and ping on all clients is ok, jitter ok .
When 1 or more client start download example 10mbps, then other clients loose 1 or 2 packets.

example syntetic:
Traffic on ap is 1-2Mbps , and ping on all clients is ok, jitter ok .
When start bandwitch test to 1 client then when its start then other clients 1 or 2 packet loos.
Always when do start on bandwitchtest always packet loos. (loos only when start, after start packet not loos)

Transfers on clients with this improvments is better but , AP is unusable because clients have freezes in internet games, when any other client on ap start downloading.

when downgraded to 6.40.8 then problem not exist.
I Can confirm that upgrading only the AP (That's what i do to begin testing) i can't reproduce this BUG. When i start a bandwith test or some client start a download the other clients doesn't loss any packet.
The only thing that i can reproduce is what i post before, that latency changes if the client is with traffic (better) and without heavy traffic (worst)
 
HaQs
Member Candidate
Member Candidate
Posts: 153
Joined: Sat Oct 20, 2007 3:26 pm
Location: POLAND

Re: Significant improvement for wireless Nv2 PtMP

Wed May 02, 2018 4:44 pm

check carefully again.

eg by loading a 20mbit udp transfer via bandwitch test of one client and giving a few quick start/stop in ROS bandwitch test.
and see if there is a timeout in pings to other clients.

I have checked it in many configurations, in all it behaves the same.

However, I have additional information on this matter:
The customer who makes the download must be on a lower modulation,
When modulation is increased on this client, for example, we pass the transfer test to a higher speed than modulation allows, then when the AP increases modulation there is a loss (not always but often).

The problem manifests itself the more the more the area is noisy (lower modulations - more frequent attempt to lift to higher)

---------------------------------------------------------------
UPDATE:
On ROS 6.43rc6 :
*) wireless - improved Nv2 PtMP performance;
And this version solve this bug. Actually any packet loos. :-)

To the full happiness was to improve yet jitter

Thanks MT.
 
hapi
Member Candidate
Member Candidate
Posts: 222
Joined: Fri Mar 11, 2011 11:21 am
Location: Czech Republic

Re: Significant improvement for wireless Nv2 PtMP

Sun May 06, 2018 12:48 pm

v6.43rc6

RB921G AC to SXTsq AC
in left - 802.11 - 20MHz 2x2 AC - 100Mbit stable
in right - NV2 TDMA 2ms or 3ms - 20MHz 2x2 AC - 10-80Mbit extreme unstable

this is not funy. Add to 802.11 CSMA disable and let it go. NV2 is bad. We no longer have the quality of wireless.

Image
 
mistry7
Forum Guru
Forum Guru
Posts: 1280
Joined: Tue Oct 13, 2009 11:57 am
Location: Germany

Re: Significant improvement for wireless Nv2 PtMP

Sun May 06, 2018 4:07 pm

Please test latency to Sxtsq ac too......
 
lomayani
just joined
Posts: 18
Joined: Sat Jun 17, 2017 7:21 am

Re: Significant improvement for wireless Nv2 PtMP

Sun May 06, 2018 6:07 pm

v6.43rc6

RB921G AC to SXTsq AC
in left - 802.11 - 20MHz 2x2 AC - 100Mbit stable
in right - NV2 TDMA 2ms or 3ms - 20MHz 2x2 AC - 10-80Mbit extreme unstable

this is not funy. Add to 802.11 CSMA disable and let it go. NV2 is bad. We no longer have the quality of wireless.

Image
Am see poor performance too on 6.43. last version(6.42.1) is working very fine for me. Hardily getting stable 50mbps capacity on 6.43rc6.
 
uldis
MikroTik Support
MikroTik Support
Topic Author
Posts: 3424
Joined: Mon May 31, 2004 2:55 pm

Re: Significant improvement for wireless Nv2 PtMP

Mon May 07, 2018 10:02 am

v6.43rc6

RB921G AC to SXTsq AC
in left - 802.11 - 20MHz 2x2 AC - 100Mbit stable
in right - NV2 TDMA 2ms or 3ms - 20MHz 2x2 AC - 10-80Mbit extreme unstable

this is not funy. Add to 802.11 CSMA disable and let it go. NV2 is bad. We no longer have the quality of wireless.

Image
Am see poor performance too on 6.43. last version(6.42.1) is working very fine for me. Hardily getting stable 50mbps capacity on 6.43rc6.
Could you both share the exact setup and configurations and also how you are doing the speed tests so we could try to reproduce your problem?
 
lomayani
just joined
Posts: 18
Joined: Sat Jun 17, 2017 7:21 am

Re: Significant improvement for wireless Nv2 PtMP

Mon May 07, 2018 10:47 am

v6.43rc6

RB921G AC to SXTsq AC
in left - 802.11 - 20MHz 2x2 AC - 100Mbit stable
in right - NV2 TDMA 2ms or 3ms - 20MHz 2x2 AC - 10-80Mbit extreme unstable

this is not funy. Add to 802.11 CSMA disable and let it go. NV2 is bad. We no longer have the quality of wireless.

Image
Am see poor performance too on 6.43. last version(6.42.1) is working very fine for me. Hardily getting stable 50mbps capacity on 6.43rc6.
Could you both share the exact setup and configurations and also how you are doing the speed tests so we could try to reproduce your problem?
I have done similar tests few minutes ago. Ap configuration is below

/interface wireless
set [ find default-name=wlan1 ] band=5ghz-a/n/ac basic-rates-a/g=\
12Mbps,18Mbps,24Mbps,36Mbps,48Mbps,54Mbps disabled=no frequency=5260 \
frequency-mode=superchannel mode=ap-bridge name=wlan1-gateway \
nv2-downlink-ratio=65 radio-name="xxxx" rx-chains=0,1 ssid=xxxx \
supported-rates-a/g=12Mbps,18Mbps,24Mbps,36Mbps,48Mbps,54Mbps \
tdma-period-size=auto tx-chains=0,1 wds-default-bridge=bridge1 wds-mode=\
dynamic wireless-protocol=nv2

You can see for the same client hardily going to 50mbps with 6.43rc6 installed in the AP but am getting 100Mbps on the same client on 6.42.1. this AP has 32 clients connected
You do not have the required permissions to view the files attached to this post.
 
uldis
MikroTik Support
MikroTik Support
Topic Author
Posts: 3424
Joined: Mon May 31, 2004 2:55 pm

Re: Significant improvement for wireless Nv2 PtMP

Mon May 07, 2018 12:10 pm

that speed test is going to one client or to all clients together?
 
lomayani
just joined
Posts: 18
Joined: Sat Jun 17, 2017 7:21 am

Re: Significant improvement for wireless Nv2 PtMP

Mon May 07, 2018 1:07 pm

that speed test is going to one client or to all clients together?
Am doing test from one client to our CCR1036-12G-4S in our office. Other clients are connected and doing normal browsing. I know doing test like this to one client slow other clients
I know with 6.43rc6 possibility of one client to kill performance of the other clients is minimum according to test i did but overall throughput is very low. Hardly goes beyond 50mbps with 20Mhz channel.
With 6.42.1 overall throughput is very good only issue am seeing is one client can kill performance of other clients if is doing heavy downloads. In our case we are limiting each client to a certain speed so no possibility of client to affect others. Overall speed of 6.42.1 is twice of 6.43rc6.

the structure of setup is client radio(dynadish ac)-AP(NetMetal 5 )-rb1100-fiber link-CCR1036-12G-4S.
 
human1982
newbie
Posts: 29
Joined: Thu Aug 13, 2015 2:36 am

Re: Significant improvement for wireless Nv2 PtMP

Mon May 07, 2018 5:36 pm

that speed test is going to one client or to all clients together?
To 2 clients getting 80mbit 1x1 auto tdma ccq 70 and 85 so i think is`t getting better. Work on latency in overhead situation please.
 
ricake24
just joined
Posts: 4
Joined: Tue May 08, 2018 7:50 am

Re: Significant improvement for wireless Nv2 PtMP

Tue May 08, 2018 7:54 am

I use that open speed test all the time!
 
viesturs
MikroTik Support
MikroTik Support
Posts: 5
Joined: Tue Nov 29, 2016 11:16 am
Location: Riga, Latvia

Re: Significant improvement for wireless Nv2 PtMP

Tue May 08, 2018 9:45 am

We were not able to recreate the issue locally with your written configuration with the exact devices. Would it be possible to grant remote access so we could observe the issue on your network?
that speed test is going to one client or to all clients together?
Am doing test from one client to our CCR1036-12G-4S in our office. Other clients are connected and doing normal browsing. I know doing test like this to one client slow other clients
I know with 6.43rc6 possibility of one client to kill performance of the other clients is minimum according to test i did but overall throughput is very low. Hardly goes beyond 50mbps with 20Mhz channel.
With 6.42.1 overall throughput is very good only issue am seeing is one client can kill performance of other clients if is doing heavy downloads. In our case we are limiting each client to a certain speed so no possibility of client to affect others. Overall speed of 6.42.1 is twice of 6.43rc6.

the structure of setup is client radio(dynadish ac)-AP(NetMetal 5 )-rb1100-fiber link-CCR1036-12G-4S.
 
lomayani
just joined
Posts: 18
Joined: Sat Jun 17, 2017 7:21 am

Re: Significant improvement for wireless Nv2 PtMP

Tue May 08, 2018 10:42 am

We were not able to recreate the issue locally with your written configuration with the exact devices. Would it be possible to grant remote access so we could observe the issue on your network?
that speed test is going to one client or to all clients together?
Am doing test from one client to our CCR1036-12G-4S in our office. Other clients are connected and doing normal browsing. I know doing test like this to one client slow other clients
I know with 6.43rc6 possibility of one client to kill performance of the other clients is minimum according to test i did but overall throughput is very low. Hardly goes beyond 50mbps with 20Mhz channel.
With 6.42.1 overall throughput is very good only issue am seeing is one client can kill performance of other clients if is doing heavy downloads. In our case we are limiting each client to a certain speed so no possibility of client to affect others. Overall speed of 6.42.1 is twice of 6.43rc6.

the structure of setup is client radio(dynadish ac)-AP(NetMetal 5 )-rb1100-fiber link-CCR1036-12G-4S.
Send me an email. I can give teamviewer access to one of our testing virtual machine and you can access the AP and client radio.
 
hapi
Member Candidate
Member Candidate
Posts: 222
Joined: Fri Mar 11, 2011 11:21 am
Location: Czech Republic

Re: Significant improvement for wireless Nv2 PtMP

Tue May 08, 2018 11:23 am

v6.43rc6

RB921G AC to SXTsq AC
in left - 802.11 - 20MHz 2x2 AC - 100Mbit stable
in right - NV2 TDMA 2ms or 3ms - 20MHz 2x2 AC - 10-80Mbit extreme unstable

this is not funy. Add to 802.11 CSMA disable and let it go. NV2 is bad. We no longer have the quality of wireless.
Am see poor performance too on 6.43. last version(6.42.1) is working very fine for me. Hardily getting stable 50mbps capacity on 6.43rc6.
Could you both share the exact setup and configurations and also how you are doing the speed tests so we could try to reproduce your problem?
AP: mANTBox 15s
/interface wireless
set [ find default-name=wlan1 ] adaptive-noise-immunity=ap-and-client-mode band=5ghz-a/n basic-rates-a/g=54Mbps comment=5360 \
    country="czech republic" disable-running-check=yes disabled=no distance=1 frequency-mode=superchannel \
    hw-retries=15 mode=ap-bridge multicast-helper=full nv2-cell-radius=10 nv2-downlink-ratio=75 scan-list=5000-6000 \
    tdma-period-size=3 wireless-protocol=802.11 wps-mode=disabled
CPE: SXTsq 5 AC
/interface wireless
set [ find default-name=wlan1 ] band=5ghz-a/n/ac country="czech republic" \
    disable-running-check=yes disabled=no frame-lifetime=10 frequency-mode=\
    superchannel hw-retries=15 radio-name="SXTsq 5 ac" scan-list=default,full
BTEST between unit, 1 tcp connection.
 
n21roadie
Forum Guru
Forum Guru
Posts: 1887
Joined: Fri Aug 07, 2009 10:36 pm
Location: Limerick,Ireland

Re: Significant improvement for wireless Nv2 PtMP

Tue May 08, 2018 9:01 pm


AP: mANTBox 15s
/interface wireless
set [ find default-name=wlan1 ] adaptive-noise-immunity=ap-and-client-mode band=5ghz-a/n basic-rates-a/g=54Mbps comment=5360 \
    country="czech republic" disable-running-check=yes disabled=no distance=1 frequency-mode=superchannel \
    hw-retries=15 mode=ap-bridge multicast-helper=full nv2-cell-radius=10 nv2-downlink-ratio=75 scan-list=5000-6000 \
    tdma-period-size=3 wireless-protocol=802.11 wps-mode=disabled
CPE: SXTsq 5 AC
/interface wireless
set [ find default-name=wlan1 ] band=5ghz-a/n/ac country="czech republic" \
    disable-running-check=yes disabled=no frame-lifetime=10 frequency-mode=\
    superchannel hw-retries=15 radio-name="SXTsq 5 ac" scan-list=default,full
BTEST between unit, 1 tcp connection.
Just curious why you have set the scan-list=5000-6000 as this results in the AP to listen to all frequencies between 5-6GHz - we when using 20Mhz channels set our AP's -/+ 20Mhz above and below the AP frequency, so for AP freq=5360 scan-list=5340-5480, just to add further we also set hw-retries=5, multicast-helper=disabled, band=5ghz-onlyn,

HT MCS supported and basic have equal setting, we are perhaps over conservative at present on this ! but would rather have a slower more stable connection to the CPE's than data rates varing on very regular basis which customers have complained about?
 
WirelessRudy
Forum Guru
Forum Guru
Posts: 3082
Joined: Tue Aug 08, 2006 5:54 pm
Location: Spain

Re: Significant improvement for wireless Nv2 PtMP

Tue May 08, 2018 10:29 pm

Just curious why you have set the scan-list=5000-6000 as this results in the AP to listen to all frequencies between 5-6GHz - we when using 20Mhz channels set our AP's -/+ 20Mhz above and below the AP frequency, so for AP freq=5360 scan-list=5340-5480, just to add further we also set hw-retries=5, multicast-helper=disabled, band=5ghz-onlyn,
We set the scan-list in the band we work. Like 5450-5750 so the scan 'sees' al available 'low noise' areas as well other AP's close to our working frequency. we do this since we'd pretty regurlarly need to swap working frequency if yet again somebody decided to work on ours......

Since 6.41.xx the scan seems to be slower, and if we set a scan time higher then 59 seconds it comes back in terminal to disappear before we could even read some of it. Secondly, setting it to anything less doesn't give us the whole range in scan anymore. I have to sort of cut it 'in two' (twice a scan, both with a part of the range in the scan-list). This performance was much better in 6.40.x and before. Very irritating, the more since we already lost the spectral scan/history in the 'ac' units.
While spectrum scanning becomes more and more important the tool itself works worse every new ROS family... :(
HT MCS supported and basic have equal setting, we are perhaps over conservative at present on this ! but would rather have a slower more stable connection to the CPE's than data rates varing on very regular basis which customers have complained about?
Conn. rate settings; good mentioning. I only set one, low (6 or 12Mbps) basic rate and then one supported rate that would give me a 'subribers' speed if only one stream connects and then 2 or 3 MCS rates that will give me at least the client's subscribers speeds and 1 or 2 higher. (In 'subscribers speed' I mean that if a client has a 25Mbps contract het at least needs mcs 11 to get it happening, or mcs 5 for the single chain.)
Show your appreciation of this post by giving me Karma! Thanks.

Rudy R. Puister

WISP operator based on MT routerboard & ROS.
 
networkfudge
Trainer
Trainer
Posts: 130
Joined: Mon May 20, 2013 2:47 pm

Re: Significant improvement for wireless Nv2 PtMP

Tue May 08, 2018 10:34 pm

Are you certain about this? I had always thought that scan-list has no effect in AP modes?

[/quote]
Just curious why you have set the scan-list=5000-6000 as this results in the AP to listen to all frequencies between 5-6GHz - we when using 20Mhz channels set our AP's -/+ 20Mhz above and below the AP frequency, so for AP freq=5360 scan-list=5340-5480, just to add further we also set hw-retries=5, multicast-helper=disabled, band=5ghz-onlyn,
[/quote]
MTCNA MTCWE MTCRE MTCINE MTCTCE UWBS UWBA
 
Redmor
Member Candidate
Member Candidate
Posts: 248
Joined: Wed May 31, 2017 7:40 pm
Location: Italy

Re: Significant improvement for wireless Nv2 PtMP

Tue May 08, 2018 11:54 pm

Just done a test on a NetMetal 5 (921UAGS-5SHPacD) with 28 clients associated that runs on v.6.42.1 and latest firmware.
AP radio is on 'only-N', 20/40MHz Ce, NV2 protocol, some fixed MCS rates, Hw. Retries = 3, 75% dynamic downlink mode and tdma 2ms period size.

I have one client with SEXTANT (v6.41.3) and signal Tx/Rx -52/-50 (from AP; Tx =download) that for hours is downloading with its maximum queue (at remote device) which means 10-25Mbps.

If I try to run a MT throughput test (tcp) from another client that has an LHG-'n' (v6.42.1) and Tx/Rx -55/-60 (read in AP) it starts high with over 15Mbps but drops almost immediate back to 3-5Mbps... and stays there...
When I throw the SEXTANT from the AP by its access list the speed of the LHG immediate jumps back to almost 20Mbps! Do I allow the SEXTANT to associate again and after a while the download runs again the speed of the LHG drops back to the previous 3-56Mbps.

Total throughput of the NetMetal during all the time is 20-35Mbps. I can run a bw test from this AP to remote gateway on single tcp stream and get 150Mbps..... So plenty of capacity available.

As I previously confirmed that the 'significant improvement in NV2' claim by MT was true, now it shows it ain't..... One client prevents others from getting higher speed.
(And this is not because some chipset 'don't like the 6.42 software, since this SEXTANT runs 6.41.3..)

Would be nice if any can confirm similar or have any comments...
Improvements can be seen with 10+ CPEs.
As MK support said to me in a support e-mail, with these "improvements" CPEs with lower signals don't slower other CPEs.
I haven't fully tested improvements and I can't say what are these improvements, but I can tell you that CPEs throughput has been increased after I've updated to 6.42.1, and I'm updating all my APs.
I didn't do 10+ bandwidth tests, but on CPEs that had 2Mbps DL, after 6.42.1 they've reached 10+Mbps, without changing settings or frequencies.
ImageImage
 
Redmor
Member Candidate
Member Candidate
Posts: 248
Joined: Wed May 31, 2017 7:40 pm
Location: Italy

Re: Significant improvement for wireless Nv2 PtMP

Tue May 08, 2018 11:57 pm

Are you certain about this? I had always thought that scan-list has no effect in AP modes?
Just curious why you have set the scan-list=5000-6000 as this results in the AP to listen to all frequencies between 5-6GHz - we when using 20Mhz channels set our AP's -/+ 20Mhz above and below the AP frequency, so for AP freq=5360 scan-list=5340-5480, just to add further we also set hw-retries=5, multicast-helper=disabled, band=5ghz-onlyn,
[/quote]
[/quote]

Scan list for APs is used only to scan for frequencies usage/noise etc.
If you set a non-default frequency on AP with default scan list, clients connect.
ImageImage
 
n21roadie
Forum Guru
Forum Guru
Posts: 1887
Joined: Fri Aug 07, 2009 10:36 pm
Location: Limerick,Ireland

Re: Significant improvement for wireless Nv2 PtMP

Tue May 08, 2018 11:57 pm

Are you certain about this? I had always thought that scan-list has no effect in AP modes?
Just curious why you have set the scan-list=5000-6000 as this results in the AP to listen to all frequencies between 5-6GHz - we when using 20Mhz channels set our AP's -/+ 20Mhz above and below the AP frequency, so for AP freq=5360 scan-list=5340-5480, just to add further we also set hw-retries=5, multicast-helper=disabled, band=5ghz-onlyn,
[/quote]
[/quote]
After a reboot we have noticed a much faster clients wireless registration when scan list it reduced, if it's set to Default or in the above example it will take longer.
 
networkfudge
Trainer
Trainer
Posts: 130
Joined: Mon May 20, 2013 2:47 pm

Re: Significant improvement for wireless Nv2 PtMP

Wed May 09, 2018 12:08 am

Narrowing the scan-list on the CPE will reproduce what you are describing, on the AP it shouldn't have any effect whatsoever.
After a reboot we have noticed a much faster clients wireless registration when scan list it reduced, if it's set to Default or in the above example it will take longer.
MTCNA MTCWE MTCRE MTCINE MTCTCE UWBS UWBA
 
WirelessRudy
Forum Guru
Forum Guru
Posts: 3082
Joined: Tue Aug 08, 2006 5:54 pm
Location: Spain

Re: Significant improvement for wireless Nv2 PtMP

Wed May 09, 2018 12:45 am

Narrowing the scan-list on the CPE will reproduce what you are describing, on the AP it shouldn't have any effect whatsoever.
After a reboot we have noticed a much faster clients wireless registration when scan list it reduced, if it's set to Default or in the above example it will take longer.
That's my experience too. If you set the scan-list on the CPE to the working frequency a client re-connects pretty fast after any kind of edit in the config. Long enough to have the winbox session not break (not if all 40 clients of an AP disconnected, then some stay alive, some still take too long to re-connect. But that is more due NV2 timing/slots)

But setting scan list in the AP has no influence on how fast clients connect to it after a dislodge of all clients for whatever reason.
It would be nice though if it would word as a bandfilter that would filter everything away that is not of need to be heard by the receiver! Like on a 20Mhz 5600 working frequency the receiver could eliminate every signals hitting that is outside the 5585-5615 (=30Mhz) band. These 'foreign' signals won't bleed into the receiver any longer.
But I think this is a bit too much asked from MT technicians. I know eCambium4000 is doing something like this.

Setting scan-list parameters in Mikrotik AP has no effects as far as I am aware. (We only set it to make a quick scan at time to 'see' if we don't have other AP's hammering our working frequency.)
Show your appreciation of this post by giving me Karma! Thanks.

Rudy R. Puister

WISP operator based on MT routerboard & ROS.
 
WirelessRudy
Forum Guru
Forum Guru
Posts: 3082
Joined: Tue Aug 08, 2006 5:54 pm
Location: Spain

Re: Significant improvement for wireless Nv2 PtMP

Wed May 09, 2018 12:52 am

Just done a test on a NetMetal 5 (921UAGS-5SHPacD) with 28 clients associated that runs on v.6.42.1 and latest firmware.
AP radio is on 'only-N', 20/40MHz Ce, NV2 protocol, some fixed MCS rates, Hw. Retries = 3, 75% dynamic downlink mode and tdma 2ms period size.

I have one client with SEXTANT (v6.41.3) and signal Tx/Rx -52/-50 (from AP; Tx =download) that for hours is downloading with its maximum queue (at remote device) which means 10-25Mbps.

If I try to run a MT throughput test (tcp) from another client that has an LHG-'n' (v6.42.1) and Tx/Rx -55/-60 (read in AP) it starts high with over 15Mbps but drops almost immediate back to 3-5Mbps... and stays there...
When I throw the SEXTANT from the AP by its access list the speed of the LHG immediate jumps back to almost 20Mbps! Do I allow the SEXTANT to associate again and after a while the download runs again the speed of the LHG drops back to the previous 3-56Mbps.

Total throughput of the NetMetal during all the time is 20-35Mbps. I can run a bw test from this AP to remote gateway on single tcp stream and get 150Mbps..... So plenty of capacity available.

As I previously confirmed that the 'significant improvement in NV2' claim by MT was true, now it shows it ain't..... One client prevents others from getting higher speed.
(And this is not because some chipset 'don't like the 6.42 software, since this SEXTANT runs 6.41.3..)

Would be nice if any can confirm similar or have any comments...
Improvements can be seen with 10+ CPEs.
As MK support said to me in a support e-mail, with these "improvements" CPEs with lower signals don't slower other CPEs.
I haven't fully tested improvements and I can't say what are these improvements, but I can tell you that CPEs throughput has been increased after I've updated to 6.42.1, and I'm updating all my APs.
I didn't do 10+ bandwidth tests, but on CPEs that had 2Mbps DL, after 6.42.1 they've reached 10+Mbps, without changing settings or frequencies.
It is very erratic. Yesterday I 'fought' with a 3 (!) client AP and the 6.42.1 NV2 is crap.... set it to 802.11 and everything works twice as fast and more consistent.
I have some 30+ AP's that I tested with 6.42.1 and yes, I did see improvement and no dragging down a whole network by one poor client. (Test done with 5 clients while the rest of the clients were still 'online')
But I also have some 30+ AP's where the opposite happened. Crappy speeds, very irregular and yes, a poor client drags the whole network down.

So the new promoted improvements "CAN" indeed improve the NV2, but to hours horror we found it also "CAN" drag your whole network down! So be careful in setting it on all AP's. We learned that is a strategy of doom...... you have to test each AP separate.... hire some technicians!
Show your appreciation of this post by giving me Karma! Thanks.

Rudy R. Puister

WISP operator based on MT routerboard & ROS.
 
lomayani
just joined
Posts: 18
Joined: Sat Jun 17, 2017 7:21 am

Re: Significant improvement for wireless Nv2 PtMP

Wed May 09, 2018 9:34 am

Just done a test on a NetMetal 5 (921UAGS-5SHPacD) with 28 clients associated that runs on v.6.42.1 and latest firmware.
AP radio is on 'only-N', 20/40MHz Ce, NV2 protocol, some fixed MCS rates, Hw. Retries = 3, 75% dynamic downlink mode and tdma 2ms period size.

I have one client with SEXTANT (v6.41.3) and signal Tx/Rx -52/-50 (from AP; Tx =download) that for hours is downloading with its maximum queue (at remote device) which means 10-25Mbps.

If I try to run a MT throughput test (tcp) from another client that has an LHG-'n' (v6.42.1) and Tx/Rx -55/-60 (read in AP) it starts high with over 15Mbps but drops almost immediate back to 3-5Mbps... and stays there...
When I throw the SEXTANT from the AP by its access list the speed of the LHG immediate jumps back to almost 20Mbps! Do I allow the SEXTANT to associate again and after a while the download runs again the speed of the LHG drops back to the previous 3-56Mbps.

Total throughput of the NetMetal during all the time is 20-35Mbps. I can run a bw test from this AP to remote gateway on single tcp stream and get 150Mbps..... So plenty of capacity available.

As I previously confirmed that the 'significant improvement in NV2' claim by MT was true, now it shows it ain't..... One client prevents others from getting higher speed.
(And this is not because some chipset 'don't like the 6.42 software, since this SEXTANT runs 6.41.3..)

Would be nice if any can confirm similar or have any comments...
Improvements can be seen with 10+ CPEs.
As MK support said to me in a support e-mail, with these "improvements" CPEs with lower signals don't slower other CPEs.
I haven't fully tested improvements and I can't say what are these improvements, but I can tell you that CPEs throughput has been increased after I've updated to 6.42.1, and I'm updating all my APs.
I didn't do 10+ bandwidth tests, but on CPEs that had 2Mbps DL, after 6.42.1 they've reached 10+Mbps, without changing settings or frequencies.
It is very erratic. Yesterday I 'fought' with a 3 (!) client AP and the 6.42.1 NV2 is crap.... set it to 802.11 and everything works twice as fast and more consistent.
I have some 30+ AP's that I tested with 6.42.1 and yes, I did see improvement and no dragging down a whole network by one poor client. (Test done with 5 clients while the rest of the clients were still 'online')
But I also have some 30+ AP's where the opposite happened. Crappy speeds, very irregular and yes, a poor client drags the whole network down.

So the new promoted improvements "CAN" indeed improve the NV2, but to hours horror we found it also "CAN" drag your whole network down! So be careful in setting it on all AP's. We learned that is a strategy of doom...... you have to test each AP separate.... hire some technicians!
Am not seeing this issue on my network over 50+ APs in 6.42.1. For clients running AC am getting up to 100Mbps under 20Mhz channel. I found tdma period size=auto give few more Mbps than 3msec or 2msec size . I had few issue with few APs being slow. After long troubleshooting I came to realize that noise has big impact. I decided to set adaptive-noise-immunity=ap-and-client-mode and fixed my issue on those APs
 
viesturs
MikroTik Support
MikroTik Support
Posts: 5
Joined: Tue Nov 29, 2016 11:16 am
Location: Riga, Latvia

Re: Significant improvement for wireless Nv2 PtMP

Wed May 09, 2018 2:12 pm

You wrote that you have to test each AP separate, because the in different sectors the performance may differ. How you observed any patterns or AP/CPE combinations on which the issue repeats more often? This would give us valuable info to work with and improve the performance and stability.
Just done a test on a NetMetal 5 (921UAGS-5SHPacD) with 28 clients associated that runs on v.6.42.1 and latest firmware.
AP radio is on 'only-N', 20/40MHz Ce, NV2 protocol, some fixed MCS rates, Hw. Retries = 3, 75% dynamic downlink mode and tdma 2ms period size.

I have one client with SEXTANT (v6.41.3) and signal Tx/Rx -52/-50 (from AP; Tx =download) that for hours is downloading with its maximum queue (at remote device) which means 10-25Mbps.

If I try to run a MT throughput test (tcp) from another client that has an LHG-'n' (v6.42.1) and Tx/Rx -55/-60 (read in AP) it starts high with over 15Mbps but drops almost immediate back to 3-5Mbps... and stays there...
When I throw the SEXTANT from the AP by its access list the speed of the LHG immediate jumps back to almost 20Mbps! Do I allow the SEXTANT to associate again and after a while the download runs again the speed of the LHG drops back to the previous 3-56Mbps.

Total throughput of the NetMetal during all the time is 20-35Mbps. I can run a bw test from this AP to remote gateway on single tcp stream and get 150Mbps..... So plenty of capacity available.

As I previously confirmed that the 'significant improvement in NV2' claim by MT was true, now it shows it ain't..... One client prevents others from getting higher speed.
(And this is not because some chipset 'don't like the 6.42 software, since this SEXTANT runs 6.41.3..)

Would be nice if any can confirm similar or have any comments...
Improvements can be seen with 10+ CPEs.
As MK support said to me in a support e-mail, with these "improvements" CPEs with lower signals don't slower other CPEs.
I haven't fully tested improvements and I can't say what are these improvements, but I can tell you that CPEs throughput has been increased after I've updated to 6.42.1, and I'm updating all my APs.
I didn't do 10+ bandwidth tests, but on CPEs that had 2Mbps DL, after 6.42.1 they've reached 10+Mbps, without changing settings or frequencies.
It is very erratic. Yesterday I 'fought' with a 3 (!) client AP and the 6.42.1 NV2 is crap.... set it to 802.11 and everything works twice as fast and more consistent.
I have some 30+ AP's that I tested with 6.42.1 and yes, I did see improvement and no dragging down a whole network by one poor client. (Test done with 5 clients while the rest of the clients were still 'online')
But I also have some 30+ AP's where the opposite happened. Crappy speeds, very irregular and yes, a poor client drags the whole network down.

So the new promoted improvements "CAN" indeed improve the NV2, but to hours horror we found it also "CAN" drag your whole network down! So be careful in setting it on all AP's. We learned that is a strategy of doom...... you have to test each AP separate.... hire some technicians!
 
WirelessRudy
Forum Guru
Forum Guru
Posts: 3082
Joined: Tue Aug 08, 2006 5:54 pm
Location: Spain

Re: Significant improvement for wireless Nv2 PtMP

Wed May 09, 2018 2:59 pm

You wrote that you have to test each AP separate, because the in different sectors the performance may differ. How you observed any patterns or AP/CPE combinations on which the issue repeats more often? This would give us valuable info to work with and improve the performance and stability.
Well, to be honest I'd lack the time to invest this all. I have 40 or so AP's but each AP has a lot of variables to work with:
- full 'n' network or 'ac'
- NV2 network or 802.11
- v.6.40.3 or 6.41.1 or newer
- some networks all clients have better then -55dB signal, others have clients up to -70dB. Make a big difference
- some clients have been given new 'arm' devices to work with 'ac' and with its high capacity CPU (Since we try to get signals close or better, then -50dB we are replacing a lot of 'n'-SXT's for the new DISC's or LHG-5ac's). We do PPoE on the antena but found that any ROS lower then 6.41.x is not supporting PPPoE. So networks with 'arm' devices are not the same as networks where we don't have such devices running yet....

Then in either NV2 or 802.11 we still have several variables to work with in these specific protocol setting. Special the NV2 leaves us with the question to what TDMA perriod Size to use; auto/1ms/2ms or 3ms. We have to try dynamic versus fixed downlink and the ratio.

Also we first need to find out if the AP is hammered by interference from another station. And then we have to find the same for the clients that have issues.

Since nowadays each and every single change in either the AP's or CPE's config makes the station of the change to drop all associations we then need to wait to the connections again, start the bandwidth test again and read the parameters.
Basically we can only do this over night not to disturb the clients. But overnight there is little traffic so the situation doesn't reflect 'busy hours' which are usually the times performances are hammered by the heavy usage of the network.

So our policy is only to work on AP's that give reports from customers about poor performance of if we do occasional tests ourselves and find things bad.
For now we decided to leave some of our still v6.40.3 running networks untouched not to run in even more helpdesk calls.

Two days ago I'd spend 5 hours on one AP with 3 clients only to find the best setting => 802.11. I went to bed at 4am only to find out something went wrong and we had to fix some routing protocols I'd accidentally removed because my eyes where half open!

I always thought too one setting would serve all P2MP networks but to my horror I'd see now huge differences in performance with the same settings depending on the actual networks....
Show your appreciation of this post by giving me Karma! Thanks.

Rudy R. Puister

WISP operator based on MT routerboard & ROS.
 
taduikis
Member
Member
Posts: 423
Joined: Sat Jul 07, 2007 12:09 pm

Re: Significant improvement for wireless Nv2 PtMP

Thu May 10, 2018 12:36 am

I was just about to say that I understand MikroTik's frustration: one user claims performance has improved, other tells horror stories, etc.. And you can't really know if it's because of noob incompetence or because of some valid natural reasons like RF environment or some special equipment combination. But I can confirm that it's true about different performance on different ROS versions. I've had plenty of those. Also I don't use plain 802.11 (don't know why, just haven't given it a chance. ever), but where nv2 doesn't give required bandwidth or CCQs are low, and RF isn't the issue, nstreme seems to fix it for me. I do have ~20% APs running on nstreme, all others are nv2. And in most cases I haven't really taken very thorough investigation which protocol works better, I just assumed nv2 is best for PTMP (since it should be constantly improved, developed and was made for PTMP) and just used it by default. Only tried changing on APs that asked attention. During all these years my observations suggest that nv2 is more resistant to interference, but hardly ever outperformed nstreme on total sector capacity, per user speed and especially latency. Which shouldn't be that way. Latest and most developed proprietary protocol must be superior to former versions and plain 802.11. But somehow lots of users here report contrarily.

And now I'm a lot on WirelessRudy's side about experimenting on live network. I hardly ever see APs idling, there's always considerable amount of traffic going and you can't really tell if that's Facebook or just unimportant background transfers, even late at night. User tolerance levels on network outages are now so low that I'm literally afraid to touch anything in search of higher capacity until we get complaints from subscribers. And nowadays they have so many options that sometimes they simply jump the boat and doesn't even bother to inform you that their connection is struggling.

What I'm trying to say here, we shouldn't be spending our time and client's patience by trying nstreme vs nv2. Or especially plain 802. Latest protocol version must provide best results and performance. It's not possible you say? Well, I'd like to see how many ubnt or epmp users are using plain 802.11 when all CPEs are of same vendor and say it works better than proprietary TDMA protocol. Testing should be done on laboratories and special test-setups, not on production networks. And 802.11 mode must be for cross-vendor compatibility and to check that proprietary protocol really outperforms it. But anyhow, it's nice to see nv2 is getting attention it really needed for long time. I can only hope it'll muddle out.

Some other observations and suggestions from my side:
  • if it's key point here - don't bother trying to make nv2 perform on obsolete equipment with very old chipsets;
  • clearly give suggestions on how to tune up our networks (hardware and software wise):
    • which ROS versions to use on AP and CPE;
    • which boards work the best on AP side (for example does later generation AC boards work better or the difference is negligible);
    • which protocols to set for single/mixed mode setups (N/AC);
    • do we need some specific NV2 settings: period-size, d/u ratio, etc;
    • you can actually post detailed scenarios and configs you've tested and achieved good performance. For example RB921 as AP, Lite5ac's as clients, so we could compare these setups and perhaps consider replacing few remaining old equipment to gain considerable boost in throughput;
  • don't be afraid to communicate with users here on forum, email and don't be afraid to read other forums.

What majority of us want here is simply more throughput per user (to meet ever-growing user traffic demand) and more total sector capacity and for all it to work stable. We already know it can be done. Because it has been done. Unfortunately not where we want.
 
taduikis
Member
Member
Posts: 423
Joined: Sat Jul 07, 2007 12:09 pm

Re: Significant improvement for wireless Nv2 PtMP

Thu May 10, 2018 1:34 am

Well this discussion about scan-list here got a little off-topic and shouldn't steer away our discussion from the main topic which is about Nv2 improvements and performance.
To be clear one last time: scan-list is only in effect on CPEs or AP while in scan mode. It's just that - a list of frequencies radio can tune in (wherever it's for joining the network or doing site-survey). So on APs it basically does nothing. Only when you wish to scan the air to see what's around. Having shorter scan-list lets you rejoin the AP faster. I'm not sure if it's already being done, but CPE could remember the channel it was connected on and to try it first upon reconnects. This would speed up reconnecting to APs working on frequencies that at the end of scan-list.

Since my post also adds to off-topic I'll snatch in by commenting further.

For WirelessRudy:
Remember you can do scan's with minimal downtime by temporarily switching to 802.11 and doing 'background-scan'.


It would be nice though if it would word as a bandfilter that would filter everything away that is not of need to be heard by the receiver! Like on a 20Mhz 5600 working frequency the receiver could eliminate every signals hitting that is outside the 5585-5615 (=30Mhz) band. These 'foreign' signals won't bleed into the receiver any longer.
But I think this is a bit too much asked from MT technicians. I know eCambium4000 is doing something like this.
Yes, that in fact would be nice. But you wouldn't need to specify anything for it to work. For this you need some clever and sophisticated circuitry that can adapt the filter according to set frequency and cancel out everything outside your selected frequency+channel width. This indeed gives quite a lot of improvement on link quality, especially on heavily co-located towers as it raises SNR on uplink. But it's highly unlikely we'll see this on some RouterBoard anytime soon, since RBs are built from off-shelf parts and this filtering technology isn't what's easily available on the market, everyone holds a grip on it heavily. What MT actually could do is to update their rate-selection algorithm to support asymmetric downlink/uplink rates to allow lower modulations to be used for uplink to APs, while allowing higher ones for downlink. This is done and recommended even on other vendor equipment that does have the neighbor channel filtering.

And if by some miracle MT would introduce channel filtering on their boards, I hope they'll retain current or at least similar format of PCB so it could be somehow easily replaced in our current setups without pain. Meanwhile you can also filter out unwanted RF noise by using fixed-freq filters. They're available for purchase and would actually make sense if you hold the specific frequency and don't change it much.
 
draguzet
Frequent Visitor
Frequent Visitor
Posts: 74
Joined: Fri Jul 01, 2011 10:28 am

Re: Significant improvement for wireless Nv2 PtMP

Thu May 10, 2018 10:33 am

Thumb up for that review...we are WISP and working only on NV2, as the post above says, logically that NV2 has to give the best results, so please MT let us know the recommendations of the settings as described below:
Some other observations and suggestions from my side:
  • if it's key point here - don't bother trying to make nv2 perform on obsolete equipment with very old chipsets;
  • clearly give suggestions on how to tune up our networks (hardware and software wise):
    • which ROS versions to use on AP and CPE;
    • which boards work the best on AP side (for example does later generation AC boards work better or the difference is negligible);
    • which protocols to set for single/mixed mode setups (N/AC);
    • do we need some specific NV2 settings: period-size, d/u ratio, etc;
    • you can actually post detailed scenarios and configs you've tested and achieved good performance. For example RB921 as AP, Lite5ac's as clients, so we could compare these setups and perhaps consider replacing few remaining old equipment to gain considerable boost in throughput;
 
WirelessRudy
Forum Guru
Forum Guru
Posts: 3082
Joined: Tue Aug 08, 2006 5:54 pm
Location: Spain

Re: Significant improvement for wireless Nv2 PtMP

Thu May 10, 2018 11:33 am

Usage of 802.11 versus NV2 is not only a matter of 'TDMA is newer developed and thus should be better'.
In fact the new 802.11ac protocol has several improvements over 802.11-n which makes it a very good protocol if it is used in combination with rts/cts setting and a 'many' station P2MP network relatively has low usage.

TDMA should bring advantages when many clients fight for airtime of the AP and thus the time division takes care of a proper and orderly balanced time distribution over all stations that really need to send and receive data. And with smart algorithms it could also reserve more time for downloads as for upload like the latest NV2 updates is said to have brought us...

802.11ac on the other hand is very good when it comes to P2MP networks that although it has many clients associated only few stations really ask for airtime.
In a tdma environment each client (plus the possible new one) always gets time slots reserved but if the client in fact doesn't need to send or receive anything this is wasted time. The more clients associated, the more airtime is wasted.
In 802.11ac when only few clients need airtime they basically get all time available. And since tdma also incorporates some extra overhead the net throughput on a 802.11ac P2MP can be higher for few clients in a many station associated network. There is simply less time wasted.

The 802.11ac + rts/cts is a well developed by a broad industry platform where tdma is a development of each vendor itself. It's cleat that the smaller companies (Mikrotik is "small" in wireless compared to the mastodonts we all know who they are) don't have the resources to resource, develop, test, correct, test again, correct again, test again etc. etc. etc. in the lab first and then in the field.
I think the latter is the reason Mikrotik is running behind in NV2 developments and in fact in certain circumstances it can well be the standard 802.11ac (+rts/cts) is better then their tdma.

I can only hope these remarks, comments and criticisms make Mikrotik works harder/invest more in their wireless/NV2 developments. Because as other vendors proved, a good performing tdma network can do much better then we see now with Mikrotik.
Show your appreciation of this post by giving me Karma! Thanks.

Rudy R. Puister

WISP operator based on MT routerboard & ROS.
 
taduikis
Member
Member
Posts: 423
Joined: Sat Jul 07, 2007 12:09 pm

Re: Significant improvement for wireless Nv2 PtMP

Thu May 10, 2018 2:15 pm

Sure, 802.11ac is better than 11n. It must be. But other manufacturers (we all know which ones) still use some implementation of TDMA instead of saving the costs and using industry developed mainstream protocol. Even some LTE networks use TDD based TDMA. So one way or another it seems TDMA is the way to go.

By the way, are there any evident advantages of using AC boards on NV2 APs when clients are 11n or mixed n/ac?
 
mkx
Forum Guru
Forum Guru
Posts: 2797
Joined: Thu Mar 03, 2016 10:23 pm

Re: Significant improvement for wireless Nv2 PtMP

Thu May 10, 2018 5:46 pm

Even some LTE networks use TDD based TDMA.
Which LTE networks?

Please bear in mind that OFDMA as used in LTE is partly TDMA (probably OFDMA in 802.11ac as well, I don't know the details). Partly in a sense that block of orthogonal frequencies is assigned to single client device at a time and assignment is done in regular intervals (in LTE interval length is 1 ms) thus same frequency block can be assigned to different client devices at different times.
The big difference between "proper" TDMA systems and OFDMA is that in TDMA all resources (if this was OFDM, then whole set of orthogonal frequencies spanning while carrier) is assigned to single client device while in OFDMA many client devices can get assigned part of orthogonal frequencies at the same time (of course one block can be assigned to single device). Surely if number of devices needing air-time is low, then it can happen that single client device gets assigned resources in certain time interval thus OFDMA can really look like TDMA.
In uplink LTE uses slightly different technology, called SC-OFDMA .. SC meaning Single Carrier, where each client device gets assigned contigous block of frequencies while in "straight" OFDMA, assigned blocks of frequencies can be sparsely distributed across whole carrier.
.
In a tdma environment each client (plus the possible new one) always gets time slots reserved but if the client in fact doesn't need to send or receive anything this is wasted time.
This describes very badly designed TDMA. The last time such TDMA was used in mobile networks, was in GSM/PCS for voice calls - so called circuit-switched services (including 9.6kbps/14.4kbps data transfer modes). GPRS/EDGE works on top of TDMA but it doesn't really reserve so much air-time for inactive users. There's state transition (idle/dedicated) happening with idle timeout with magnitude of 1 second. When client is idle, no resources are reserved for it and when data transfer is about to resume, special signalling procedure takes place (and time ;-) ). When client is in dedicated mode, then resources are indeed reserved for it (but dynamically).

I have hard time to believe that NV2 would be implemented in GSM way (and not in GPRS way).
BR,
Metod
 
WirelessRudy
Forum Guru
Forum Guru
Posts: 3082
Joined: Tue Aug 08, 2006 5:54 pm
Location: Spain

Re: Significant improvement for wireless Nv2 PtMP

Thu May 10, 2018 6:01 pm

Sure, 802.11ac is better than 11n. It must be. But other manufacturers (we all know which ones) still use some implementation of TDMA instead of saving the costs and using industry developed mainstream protocol. Even some LTE networks use TDD based TDMA. So one way or another it seems TDMA is the way to go.

By the way, are there any evident advantages of using AC boards on NV2 APs when clients are 11n or mixed n/ac?
Because TDMA is used by most main stream vendors doesn't inherently mean it is the best. Many of us know the history of the video standard used by Betamax versus VHS versus V2000 (Philips) of the last century. The most popular system wins, not the best.
There are vendors using 5Ghz wifi systems that use 10Mhz wide (!) channels ans still seem to be able to deliver 30Mbps to clients in an area where I with my Mikrotik netmetals in a 20Mhz won't be able to do the same..... no matter what protocol I'd use. I am not fully aware how they do it, but they do....

Usually the advantage of 'ac' radio's over'n' radios are;
- Two 'ac' AP radio's can share the same 80Mhz (or 160Mhz) band if there s/n difference at each other is 25/30dB and both use the 'pilot' band different as the other. For instance one AP has the upper channel as its 'pilot' channel whereas the other uses the lower. (Like one AP has eeeC and the other has Ceee but both have the same 80Mhz range.
Clients that can pick up both signals can work without interference. If the full 80Mhz signal has enough s/n ratio both CPE and AP work in the full band. If the CPE notices in the designated band the 'not to be associated to' AP interferes for that CPE only the 40Mhz part of the channel will be used that is the pilot on its 'to be associated' AP.
Basically it means that two 80Mhz channel working AP's that have different 'pilot' channel don't interfere with each other at the expense of switching back to a 40Mhz channel, only for that CPE!
It's a sort of interference avoiding capability that comes with 802.11ac (and I believe doesn't work in 40Mhz wide channels)

- Apart from that, 'ac' chipsets are 1 to 2dB more powerful then its 'n' counterparts. See the specs of MT radios. (An SXT-5Lite has 22dBm at MCS7 where the SXT-5acLite has 25dBm. An Omnitik has 26dBm at MCS7 but the Omnitik-ac has 27dBm.

- Newer chipsets (like the 'ac' chipset) usually also have better sensitivity and thus need less signal to get to the same modulation rate. (The MCS7 for the Omnitik-ac works already with -77dBm where the Omnitik-n needs -75dBm.)

- The CPU that comes with 'ac' devices is usually also much faster, so more power under the hood! (650Mhz versus 600/400Mhz for the SXT or 720Mhz versus 600Mhz for the Omnitiks.

- 'ac' radios that have good enough signal have two extra (256QAM) modulations available and can thus get higher speeds, which in a busy network means faster dealing with clients. (So the capacity of the AP increases since traffic to that 'ac' client gets send or received faster.)
Show your appreciation of this post by giving me Karma! Thanks.

Rudy R. Puister

WISP operator based on MT routerboard & ROS.
 
mkx
Forum Guru
Forum Guru
Posts: 2797
Joined: Thu Mar 03, 2016 10:23 pm

Re: Significant improvement for wireless Nv2 PtMP

Thu May 10, 2018 6:23 pm

- Apart from that, 'ac' chipsets are 1 to 2dB more powerful then its 'n' counterparts. See the specs of MT radios. (An SXT-5Lite has 22dBm at MCS7 where the SXT-5acLite has 25dBm. An Omnitik has 26dBm at MCS7 but the Omnitik-ac has 27dBm.

- Newer chipsets (like the 'ac' chipset) usually also have better sensitivity and thus need less signal to get to the same modulation rate. (The MCS7 for the Omnitik-ac works already with -77dBm where the Omnitik-n needs -75dBm.)
.
You need to keep in mind, that 'n' uses frequency channels wide up to 40MHz while 'ac' uses up to 160MHz wide channels. Meaning that TX power is dispersed over 6 dB wider frequency band and if total TX power was the same, ratio Watt-per-Hertz would be 6dB lower for wide-band 'ac'. Higher TX power and better RX sensitivity of 'ac' combined give 3dB gain over 'n' ... when using same frequency band-width (e.g. 40MHz). When using maximum supported 'ac' frequency bandwidth then whole path budget is still 3 dB lower in 'ac' so perhaps it'll occasionally use lower MCS than 'n' would have ... but still benefit because of using so much wider frequency band.
BR,
Metod
 
WirelessRudy
Forum Guru
Forum Guru
Posts: 3082
Joined: Tue Aug 08, 2006 5:54 pm
Location: Spain

Re: Significant improvement for wireless Nv2 PtMP

Thu May 10, 2018 7:56 pm

- Apart from that, 'ac' chipsets are 1 to 2dB more powerful then its 'n' counterparts. See the specs of MT radios. (An SXT-5Lite has 22dBm at MCS7 where the SXT-5acLite has 25dBm. An Omnitik has 26dBm at MCS7 but the Omnitik-ac has 27dBm.

- Newer chipsets (like the 'ac' chipset) usually also have better sensitivity and thus need less signal to get to the same modulation rate. (The MCS7 for the Omnitik-ac works already with -77dBm where the Omnitik-n needs -75dBm.)
.
You need to keep in mind, that 'n' uses frequency channels wide up to 40MHz while 'ac' uses up to 160MHz wide channels. Meaning that TX power is dispersed over 6 dB wider frequency band and if total TX power was the same, ratio Watt-per-Hertz would be 6dB lower for wide-band 'ac'. Higher TX power and better RX sensitivity of 'ac' combined give 3dB gain over 'n' ... when using same frequency band-width (e.g. 40MHz). When using maximum supported 'ac' frequency bandwidth then whole path budget is still 3 dB lower in 'ac' so perhaps it'll occasionally use lower MCS than 'n' would have ... but still benefit because of using so much wider frequency band.
True. But important! Just by changing our normal OmniTiks into the new Omnitik 'ac's and also replacing SXT's by the SXT-ac's we gained 3-4dB per client in the same channel and same bandwidth. This improvement of +/-3dB (double de signal!) gained just because of that one or two mcs rates! The average capacity of the P2MP network increased just by the replacements only!
Now this network still runs in 'n' mode since not all clients are changed yet, but when the last one is done we will switch to full 'ac' and see what we get then.... :-) )
Show your appreciation of this post by giving me Karma! Thanks.

Rudy R. Puister

WISP operator based on MT routerboard & ROS.
 
mkx
Forum Guru
Forum Guru
Posts: 2797
Joined: Thu Mar 03, 2016 10:23 pm

Re: Significant improvement for wireless Nv2 PtMP

Thu May 10, 2018 11:02 pm

@WirelessRudy: indeed if you only replace equipment and keep the wireless parameters the same, you get better performance. What I was trying to show is that it's only normal that 'ac' has better performance because that's simply necessary for 'ac' modus operandi. Without it, 'ac' performance would be less than great.
BR,
Metod
 
n21roadie
Forum Guru
Forum Guru
Posts: 1887
Joined: Fri Aug 07, 2009 10:36 pm
Location: Limerick,Ireland

Re: Significant improvement for wireless Nv2 PtMP

Fri May 11, 2018 12:10 am

.................................

Some other observations and suggestions from my side:
  • if it's key point here - don't bother trying to make nv2 perform on obsolete equipment with very old chipsets;
  • clearly give suggestions on how to tune up our networks (hardware and software wise):
    • which ROS versions to use on AP and CPE;
    • which boards work the best on AP side (for example does later generation AC boards work better or the difference is negligible);
    • which protocols to set for single/mixed mode setups (N/AC);
    • do we need some specific NV2 settings: period-size, d/u ratio, etc;
    • you can actually post detailed scenarios and configs you've tested and achieved good performance. For example RB921 as AP, Lite5ac's as clients, so we could compare these setups and perhaps consider replacing few remaining old equipment to gain considerable boost in throughput;
  • don't be afraid to communicate with users here on forum, email and don't be afraid to read other forums.

What majority of us want here is simply more throughput per user (to meet ever-growing user traffic demand) and more total sector capacity and for all it to work stable. We already know it can be done. Because it has been done. Unfortunately not where we want.
I would add to this list but no sure its important or required but TDMA is Time-division multiple access, we have set all our CPE's and AP's in fact every router to sync to NTP pools,
this for accurate time on logs and maybe this has helped our AP's and CPE's !

Also does ROS with all it's **extra's** built in, result in "Bloatware" for wireless but OK for non wireless functions ?
 
WirelessRudy
Forum Guru
Forum Guru
Posts: 3082
Joined: Tue Aug 08, 2006 5:54 pm
Location: Spain

Re: Significant improvement for wireless Nv2 PtMP

Fri May 11, 2018 12:32 am

I would add to this list but no sure its important or required but TDMA is Time-division multiple access, we have set all our CPE's and AP's in fact every router to sync to NTP pools,
this for accurate time on logs and maybe this has helped our AP's and CPE's
Imho: No, it doesn't mean anything to the TDMA protocol.
In TDMA the AP divides the available time for sending and receiving for each station in an timely 'order' by giving each device a 'time slot'. 'One by one' to say so. This can be deviated into upload and download slots and devices that need to send more data get more slots then other that don't.
But the order and length is depicted by the AP to the station in the dataframe that it sends to the station. Eacht time the AP 'runs' the cycle among its associated clients its tell them it's time "0" again and when it's each specific stations time to act. That is in fact completely independent to the actual clock.

The fact the ROS clock's are syncd yes or not with a NTP server has no influence on the working of the TDMA. (As I'd understand well. Correct me if I am wrong)

Some vendors though use GPS to sync the TDMA in each associated station to get a better sync of the TDMA. This because during each cycle of the AP's P2MP network clocks of each associated device can already run out of sync with each other. The GPS clock timing now makes sure that the clocks are much more precise then what the build in software clock of ROS can achieve. But this is usually not seen in typical CPE devices or it must be some high end vendors. It is used on backhaul devices like Mimosa B5's, AirFibers and probably other vendor's hardware.
And when this GPS sync is there to sync the link, it can also be used to sync several devices on the same tower. But still one device needs to tell all others that take part in that specific syncronized clock when it's hour "0"
But MT doesn't use this way of sync so setting the clock's to NTP only serve to get syncd log over your devices.
(Yet again, please correct me if I am wrong but that is what my understanding is.)
Show your appreciation of this post by giving me Karma! Thanks.

Rudy R. Puister

WISP operator based on MT routerboard & ROS.
 
draguzet
Frequent Visitor
Frequent Visitor
Posts: 74
Joined: Fri Jul 01, 2011 10:28 am

Re: Significant improvement for wireless Nv2 PtMP

Fri May 11, 2018 12:37 am

What with NV2 sync ?
Is someone use in production NV2 sync (master-slave) and reuse same frequency on "behind" sectors on the same tower ?
Are this function work OK or not ?
 
WirelessRudy
Forum Guru
Forum Guru
Posts: 3082
Joined: Tue Aug 08, 2006 5:54 pm
Location: Spain

Re: Significant improvement for wireless Nv2 PtMP

Fri May 11, 2018 1:18 am

What with NV2 sync ?
Is someone use in production NV2 sync (master-slave) and reuse same frequency on "behind" sectors on the same tower ?
Are this function work OK or not ?
We tried it, as well as others. Unless you have full 100% isolation for participating AP's it doesn't. So far haven't heard hard evidence from anyone that it really worked for them....
Show your appreciation of this post by giving me Karma! Thanks.

Rudy R. Puister

WISP operator based on MT routerboard & ROS.
 
Redmor
Member Candidate
Member Candidate
Posts: 248
Joined: Wed May 31, 2017 7:40 pm
Location: Italy

Re: Significant improvement for wireless Nv2 PtMP

Fri May 11, 2018 11:02 am

What with NV2 sync ?
Is someone use in production NV2 sync (master-slave) and reuse same frequency on "behind" sectors on the same tower ?
Are this function work OK or not ?
As I stated before, if a client sees two or more AP in sync, it will go bad.
I have some clients that can see 4 of them because they're 300 meters far.
Nv2 sync should be made on a RB in my opinion, not on an AP.
ImageImage
 
taduikis
Member
Member
Posts: 423
Joined: Sat Jul 07, 2007 12:09 pm

Re: Significant improvement for wireless Nv2 PtMP

Fri May 11, 2018 11:14 am

You mean clients of Sector A should not see clients of Sector B?
If so, that's fair enough. And it's achievable with quality antennas with good F/B ratios. But sync is advantageous only on ABAB or ABCD setups.
I wonder how MT sync implementation compares with GPS based syncing..
What with NV2 sync ?
Is someone use in production NV2 sync (master-slave) and reuse same frequency on "behind" sectors on the same tower ?
Are this function work OK or not ?
We tried it, as well as others. Unless you have full 100% isolation for participating AP's it doesn't. So far haven't heard hard evidence from anyone that it really worked for them....
 
Redmor
Member Candidate
Member Candidate
Posts: 248
Joined: Wed May 31, 2017 7:40 pm
Location: Italy

Re: Significant improvement for wireless Nv2 PtMP

Fri May 11, 2018 11:44 am

You mean clients of Sector A should not see clients of Sector B?
If so, that's fair enough. And it's achievable with quality antennas with good F/B ratios. But sync is advantageous only on ABAB or ABCD setups.
I wonder how MT sync implementation compares with GPS based syncing..
What with NV2 sync ?
Is someone use in production NV2 sync (master-slave) and reuse same frequency on "behind" sectors on the same tower ?
Are this function work OK or not ?
We tried it, as well as others. Unless you have full 100% isolation for participating AP's it doesn't. So far haven't heard hard evidence from anyone that it really worked for them....
In setup AAAA or AABB if a client sees both A the throughtput is really low.
You can use ABAB for sync, with first A covering from 0° to 90°, first B 90° to 180°, second A 180° to 270° and the last 270° to 360°.
In that case sync should work with no problem, if you don't have -30 tx to a client.
I don't know if ABCD on two towers would be useful.
ImageImage
 
WirelessRudy
Forum Guru
Forum Guru
Posts: 3082
Joined: Tue Aug 08, 2006 5:54 pm
Location: Spain

Re: Significant improvement for wireless Nv2 PtMP

Fri May 11, 2018 12:27 pm

You mean clients of Sector A should not see clients of Sector B?
If so, that's fair enough. And it's achievable with quality antennas with good F/B ratios. But sync is advantageous only on ABAB or ABCD setups.
Only then it works. But in that case non syncd networks also works.....
The sync makes only sense if AP's that work in the same proximity where their CPE's can 'hear' both work in sync. As long as the CPE's then have sufficient signal difference between the two AP's both AP's can work with same frequency and client only associate with the strongest without beeing hammered by the other.
This works with our Mimosa setup. The only thing you have to be aware of is that CPE's that 'see' AP-A are not picking up signal from AP-B at almost the same strength. Then it doesn't work.

We have two Omni directional (4 single chain sectors) only some 200 meters apart with close proximity (<250 meters) clients that both work in a syncd. environment with a 80Mhz wide channel. Both AP's have the same frequency but different SSID. On the clients we set the SSID to associate to and make sure the working beam of the CPE antenna is not 'seeing' the other AP. If it does the link collapse.
The Mimosa CPE's are shielded, have power control from the AP and the AP in its turn has a signal level cut-off.
Meaning that if all CPE's of AP-A connect with -40 to -55 dB range where these same CPE's would show a signal level at the AP-B of -60 or worse, we set the working signal range of the AP-B to -60dB and all signals that 'hit' AP-B with -60 or less are filtered out. Off course on AP-A we do the same so it filters out all stations that come in with -60 or less signal.
That system works fine and I have no problems to deliver 200Mbps or more tcp traffic to clients.
We also have a third Omni directional AP working in the same 80Mhz band but the 'pilot' channel is on the other side of the band as AP-A and B. Because several CPE's will see either A, B or C no matter what we do. (All CPE's are in a 300 meter radius). By changing the pilot channel the 'ac' protocol take care of possible interference between the signals of different AP's and will start using only that 40Mhz signal of the designated AP while the 40Mhz of the 'interfering AP' will be omitted. Off course instead of 80Mhz we now only have a 40Mhz channel but with the high MCS rates we still have PHY rate of 300 to 450Mbps which is good enough to deliver 150Mbps peak speeds to our clients..
And to be honest, most of our CPE's have PHY rate well over this....


With two Mikrotik Netmetals that are on a tower with both good (not the best!) f/b ratio sectors working in opposite directions while both their clients are hundreds of meters away (minimal!) on the lower plains from the small hill that has the tower (so the clients of AP-A have no way of 'seeing' in a LOS or even NLOS the sector of AP-B and vice versa) the CCQ's dropped on all clients and with it the throughput. It just doesn't work. The test is done twice on two different towers and both saw no improvement at best.
(Probably because 100% f/b ratio separation doesn't exist. Even with RF-Element cone antennas opposite radio's on the same tower 'see' each other. The signal might be well less than AP's clients, but still. And one way or another, the MT sync still has flaws..)

I think the theory behind MT's sync might look promising, at least is did for us. But in reality we can't get it to work and I've seen similar experiences from others too. MT has some work to do here...
Show your appreciation of this post by giving me Karma! Thanks.

Rudy R. Puister

WISP operator based on MT routerboard & ROS.
 
ste
Forum Guru
Forum Guru
Posts: 1795
Joined: Sun Feb 13, 2005 11:21 pm

Re: Significant improvement for wireless Nv2 PtMP

Fri May 11, 2018 2:16 pm

You mean clients of Sector A should not see clients of Sector B?
If so, that's fair enough. And it's achievable with quality antennas with good F/B ratios. But sync is advantageous only on ABAB or ABCD setups.
Only then it works. But in that case non syncd networks also works.....
The sync makes only sense if AP's that work in the same proximity where their CPE's can 'hear' both work in sync. As long as the CPE's then have sufficient signal difference between the two AP's both AP's can work with same frequency and client only associate with the strongest without beeing hammered by the other.
This works with our Mimosa setup. The only thing you have to be aware of is that CPE's that 'see' AP-A are not picking up signal from AP-B at almost the same strength. Then it doesn't work.

We have two Omni directional (4 single chain sectors) only some 200 meters apart with close proximity (<250 meters) clients that both work in a syncd. environment with a 80Mhz wide channel. Both AP's have the same frequency but different SSID. On the clients we set the SSID to associate to and make sure the working beam of the CPE antenna is not 'seeing' the other AP. If it does the link collapse.
The Mimosa CPE's are shielded, have power control from the AP and the AP in its turn has a signal level cut-off.
Meaning that if all CPE's of AP-A connect with -40 to -55 dB range where these same CPE's would show a signal level at the AP-B of -60 or worse, we set the working signal range of the AP-B to -60dB and all signals that 'hit' AP-B with -60 or less are filtered out. Off course on AP-A we do the same so it filters out all stations that come in with -60 or less signal.
That system works fine and I have no problems to deliver 200Mbps or more tcp traffic to clients.
We also have a third Omni directional AP working in the same 80Mhz band but the 'pilot' channel is on the other side of the band as AP-A and B. Because several CPE's will see either A, B or C no matter what we do. (All CPE's are in a 300 meter radius). By changing the pilot channel the 'ac' protocol take care of possible interference between the signals of different AP's and will start using only that 40Mhz signal of the designated AP while the 40Mhz of the 'interfering AP' will be omitted. Off course instead of 80Mhz we now only have a 40Mhz channel but with the high MCS rates we still have PHY rate of 300 to 450Mbps which is good enough to deliver 150Mbps peak speeds to our clients..
And to be honest, most of our CPE's have PHY rate well over this....


With two Mikrotik Netmetals that are on a tower with both good (not the best!) f/b ratio sectors working in opposite directions while both their clients are hundreds of meters away (minimal!) on the lower plains from the small hill that has the tower (so the clients of AP-A have no way of 'seeing' in a LOS or even NLOS the sector of AP-B and vice versa) the CCQ's dropped on all clients and with it the throughput. It just doesn't work. The test is done twice on two different towers and both saw no improvement at best.
(Probably because 100% f/b ratio separation doesn't exist. Even with RF-Element cone antennas opposite radio's on the same tower 'see' each other. The signal might be well less than AP's clients, but still. And one way or another, the MT sync still has flaws..)

I think the theory behind MT's sync might look promising, at least is did for us. But in reality we can't get it to work and I've seen similar experiences from others too. MT has some work to do here...
Sync also makes sense where APs hear each other in the same band. As APs are placed high it is very likely your APs hear each other even not beeing on the same tower. And they interfere even with some MHz between the used channels. So GPS-sync is a must have for wisps in 2018. It is available. It works. Why use gear which cant do it. MT needs to do it or WISPs shop elsewhere. Non wisps might live with it as they dont suffer from selfinterference.
 
taduikis
Member
Member
Posts: 423
Joined: Sat Jul 07, 2007 12:09 pm

Re: Significant improvement for wireless Nv2 PtMP

Fri May 11, 2018 3:00 pm

Well, almost all MT boards suitable for APs have USB port. And ROS have GPS package as I remember. Does this mean it's possible to take advantage of that?
MT: Update NV2 to support GPS sync and sell USB GPS modules. Additional profit.
You mean clients of Sector A should not see clients of Sector B?
If so, that's fair enough. And it's achievable with quality antennas with good F/B ratios. But sync is advantageous only on ABAB or ABCD setups.
Only then it works. But in that case non syncd networks also works.....
The sync makes only sense if AP's that work in the same proximity where their CPE's can 'hear' both work in sync. As long as the CPE's then have sufficient signal difference between the two AP's both AP's can work with same frequency and client only associate with the strongest without beeing hammered by the other.
This works with our Mimosa setup. The only thing you have to be aware of is that CPE's that 'see' AP-A are not picking up signal from AP-B at almost the same strength. Then it doesn't work.

We have two Omni directional (4 single chain sectors) only some 200 meters apart with close proximity (<250 meters) clients that both work in a syncd. environment with a 80Mhz wide channel. Both AP's have the same frequency but different SSID. On the clients we set the SSID to associate to and make sure the working beam of the CPE antenna is not 'seeing' the other AP. If it does the link collapse.
The Mimosa CPE's are shielded, have power control from the AP and the AP in its turn has a signal level cut-off.
Meaning that if all CPE's of AP-A connect with -40 to -55 dB range where these same CPE's would show a signal level at the AP-B of -60 or worse, we set the working signal range of the AP-B to -60dB and all signals that 'hit' AP-B with -60 or less are filtered out. Off course on AP-A we do the same so it filters out all stations that come in with -60 or less signal.
That system works fine and I have no problems to deliver 200Mbps or more tcp traffic to clients.
We also have a third Omni directional AP working in the same 80Mhz band but the 'pilot' channel is on the other side of the band as AP-A and B. Because several CPE's will see either A, B or C no matter what we do. (All CPE's are in a 300 meter radius). By changing the pilot channel the 'ac' protocol take care of possible interference between the signals of different AP's and will start using only that 40Mhz signal of the designated AP while the 40Mhz of the 'interfering AP' will be omitted. Off course instead of 80Mhz we now only have a 40Mhz channel but with the high MCS rates we still have PHY rate of 300 to 450Mbps which is good enough to deliver 150Mbps peak speeds to our clients..
And to be honest, most of our CPE's have PHY rate well over this....


With two Mikrotik Netmetals that are on a tower with both good (not the best!) f/b ratio sectors working in opposite directions while both their clients are hundreds of meters away (minimal!) on the lower plains from the small hill that has the tower (so the clients of AP-A have no way of 'seeing' in a LOS or even NLOS the sector of AP-B and vice versa) the CCQ's dropped on all clients and with it the throughput. It just doesn't work. The test is done twice on two different towers and both saw no improvement at best.
(Probably because 100% f/b ratio separation doesn't exist. Even with RF-Element cone antennas opposite radio's on the same tower 'see' each other. The signal might be well less than AP's clients, but still. And one way or another, the MT sync still has flaws..)

I think the theory behind MT's sync might look promising, at least is did for us. But in reality we can't get it to work and I've seen similar experiences from others too. MT has some work to do here...
Sync also makes sense where APs hear each other in the same band. As APs are placed high it is very likely your APs hear each other even not beeing on the same tower. And they interfere even with some MHz between the used channels. So GPS-sync is a must have for wisps in 2018. It is available. It works. Why use gear which cant do it. MT needs to do it or WISPs shop elsewhere. Non wisps might live with it as they dont suffer from selfinterference.
 
hapi
Member Candidate
Member Candidate
Posts: 222
Joined: Fri Mar 11, 2011 11:21 am
Location: Czech Republic

Re: Significant improvement for wireless Nv2 PtMP

Fri May 11, 2018 3:25 pm

Keep a Topic. I do not care about GPS. Currently NV2 itself does not work properly. NV2 needs to be addressed in particular.
 
WirelessRudy
Forum Guru
Forum Guru
Posts: 3082
Joined: Tue Aug 08, 2006 5:54 pm
Location: Spain

Re: Significant improvement for wireless Nv2 PtMP

Fri May 11, 2018 5:30 pm

Keep a Topic. I do not care about GPS. Currently NV2 itself does not work properly. NV2 needs to be addressed in particular.
Right.. and True"
Show your appreciation of this post by giving me Karma! Thanks.

Rudy R. Puister

WISP operator based on MT routerboard & ROS.
 
n21roadie
Forum Guru
Forum Guru
Posts: 1887
Joined: Fri Aug 07, 2009 10:36 pm
Location: Limerick,Ireland

Re: Significant improvement for wireless Nv2 PtMP

Fri May 11, 2018 5:54 pm

I would like to test a "barebones" version of ROS as I am beginning to think that its the amount of software used on ROS maybe part of the reason why NV2 is not the best wireless protocol currently available.
 
hapi
Member Candidate
Member Candidate
Posts: 222
Joined: Fri Mar 11, 2011 11:21 am
Location: Czech Republic

Re: Significant improvement for wireless Nv2 PtMP

Fri May 11, 2018 5:59 pm

Of course he is not. Watch.

2x2 AC 20MHz. Btest 1 TCP. For Mikrotik is impossible. 145Mbit in 1 TCP !!

Only MCS 8 !!
Image
 
sefirot127
just joined
Posts: 15
Joined: Thu Feb 18, 2010 8:12 pm

Re: Significant improvement for wireless Nv2 PtMP

Thu May 17, 2018 12:05 pm

Hi, first of all I'm sorry that my English is not very good

I have updated to version 6.42.1 around 20 APs and since I updated them there are clients that disconnect and stay reconnecting
Some take minutes to connect and others have taken hours
This did not happen to me before.

In all my APs the clients are connected to less than 1Km and always with direct vision.
Coverages are between -50 and -60
The signal to noise is in all customers over 60
The Aps has between 10 and 20 clients
Security is active

The Nv2 configurations are like this:
tdma-period-size = auto
cell-radius = 30
Mode = Dynamic downlink

Should I change some configuration?

I hope you can help me
 
WirelessRudy
Forum Guru
Forum Guru
Posts: 3082
Joined: Tue Aug 08, 2006 5:54 pm
Location: Spain

Re: Significant improvement for wireless Nv2 PtMP

Thu May 17, 2018 7:14 pm

Hi, first of all I'm sorry that my English is not very good

I have updated to version 6.42.1 around 20 APs and since I updated them there are clients that disconnect and stay reconnecting
Some take minutes to connect and others have taken hours
This did not happen to me before.

In all my APs the clients are connected to less than 1Km and always with direct vision.
Coverages are between -50 and -60
The signal to noise is in all customers over 60
The Aps has between 10 and 20 clients
Security is active

The Nv2 configurations are like this:
tdma-period-size = auto
cell-radius = 30
Mode = Dynamic downlink

Should I change some configuration?

I hope you can help me
If all your clients are less then 1km away I would start to set cell-radius to 10 (=smallest). That will already improve latency.

We have found now on several AP's that in fact the new NV2 is much worse then plain 802.11 or nstreme. That was never the case but we are already in the process of changing (it needs to prepare the clients since they are all configured for NV2 only)
With 802.11/nstreme we more then double the client AND AP throughput in several P2MP networks. But not all though.... and so far we cannot put our finger on the issue.......

All we know that the introduction of NV2 PtMP improvement is not only bringing improvements. Sometime yes, sometimes definitely no....
Show your appreciation of this post by giving me Karma! Thanks.

Rudy R. Puister

WISP operator based on MT routerboard & ROS.
 
jonmansey
Frequent Visitor
Frequent Visitor
Posts: 69
Joined: Sat Sep 18, 2004 3:43 am

Re: Significant improvement for wireless Nv2 PtMP

Thu May 17, 2018 8:47 pm

Have you eliminated all the ar7240 stations and still having problems? that was the cause of the new nv2 instability for me.
 
framer99
just joined
Posts: 9
Joined: Fri Dec 06, 2013 3:52 pm

Re: Significant improvement for wireless Nv2 PtMP

Sun May 20, 2018 9:14 pm

I have a 23km PtP link with netmetal5's i am using to play with A/N/AC/"only" and NV2 settings today. I stay connected to both ends of the hop when the link is down, so I can trying everything possible. I updated both ends to the latest RC routeros and firmware before i started (6.43rc14)

I'm leaving a UDP send-only Btest running on the side that is the "internet", and a ping test from the remote end, with 500ms timeout setting to watch the effects on latency. I saw a good youtube video where someone did this comparing NV2 802.11 etc.

So far.... 1ms NV2 period size will usually not even connect, it does seem to be related to the fixed/dynamic download mode and % setting when I do get it to connect at 1ms.

Anyway, I am still in the beginning of my testing but I did notice something odd and very repeatable:
  • 2ms TDMA Period size, with fixed downlink with 80% causes every other ping to be high latency. I saw this in "Auto" TDMA Period size as well.... apparently when the auto selected size is 2ms?
Image
http://imgur.com/tLhgte9


If i change fixed downlink % to 75, or TDMA Period Size to 3ms or higher, then it's all smooth and stable latency of pings.

It's not a big deal, but maybe it's why some people see 75% as the best setting vs some preferring 80%
 
WirelessRudy
Forum Guru
Forum Guru
Posts: 3082
Joined: Tue Aug 08, 2006 5:54 pm
Location: Spain

Re: Significant improvement for wireless Nv2 PtMP

Mon May 21, 2018 7:06 pm

Have you eliminated all the ar7240 stations and still having problems? that was the cause of the new nv2 instability for me.
I have tested it now on 4-5 P2MP networks. One Omnitk-5ac that has only 3 SXT's (2 x rb sXT 5nD r2 and one rb DISCG-5acD), so all relative 'new' devices and still the difference between 802.11/nstreme is considerable. NV2 to nstreme is almost double the speeds for the latter....
Show your appreciation of this post by giving me Karma! Thanks.

Rudy R. Puister

WISP operator based on MT routerboard & ROS.
 
sefirot127
just joined
Posts: 15
Joined: Thu Feb 18, 2010 8:12 pm

Re: Significant improvement for wireless Nv2 PtMP

Wed May 23, 2018 11:29 am

I tried to change cell radius to 10km and I still have reconnections, the only thing I can say is that in version 6.40.8 bugfix this does not happen.

The overall capacity has increased a bit but the reconnections take too long and I'll have to go back to version 6.40.8.

Has anyone had the same problem and been able to fix it?
 
Raumaster
newbie
Posts: 31
Joined: Fri Sep 28, 2012 2:18 am

Re: Significant improvement for wireless Nv2 PtMP

Wed May 23, 2018 3:35 pm

I've been testing 6.42.1 for a while now in all of my Sectors with Basebox 5 and SXT SA5, all clients are SXT lite5 and sq and the results are a bit better then before when throughput is the only thing in mind, but ping times are not good and jitter seems to be even worse then before ping times go all over the place even if the traffic on the sector AP is very low. And for the first time after years using Mikrotik and NV2 and hearing lots of people saying nstream is bad for ptmp, that's not what I saw after 10 hours I changed one sector to Nstream. I also changed another sector to 802.11 and everything seems to be better, througput, ping times are consistent and very low! I've always used NV2, but now seeing the results of the other protocols... The only thing I think I might mis is if I get one client with bad signal ruinning the whole sector...

One other thing I notice on two sectors, when I remove the clients bandwidth control so I can make an Internal bandwitdth test to them, If i set the test to udp, when the throughput reaches the maximum speed, all the other clients starts dropping its pppoe session as if one client only overloads the AP and none of the others can pass any data.
 
WirelessRudy
Forum Guru
Forum Guru
Posts: 3082
Joined: Tue Aug 08, 2006 5:54 pm
Location: Spain

Re: Significant improvement for wireless Nv2 PtMP

Wed May 23, 2018 6:04 pm

So we now have several users that confirm indeed NV2 has issues and in several occasions 802.11 or nstreme actually works better....

Last night spend two hours to read the 6.43.rc changelog and related forum tread and after several version it seems some changes (they call it 'improvements') are made. So we actually should test them.
But after several bad experiences in the past with rc version on production networks I am a bit hesitating to do so.
Also new rc's are still been made on ample days times so when 6.43 will be stable heavens only know....

In the meantime we'd suffer from bad networks and the competition is expanding in our backgarden..... :(
Show your appreciation of this post by giving me Karma! Thanks.

Rudy R. Puister

WISP operator based on MT routerboard & ROS.
 
lomayani
just joined
Posts: 18
Joined: Sat Jun 17, 2017 7:21 am

Re: Significant improvement for wireless Nv2 PtMP

Thu May 24, 2018 11:11 am

I've been testing 6.42.1 for a while now in all of my Sectors with Basebox 5 and SXT SA5, all clients are SXT lite5 and sq and the results are a bit better then before when throughput is the only thing in mind, but ping times are not good and jitter seems to be even worse then before ping times go all over the place even if the traffic on the sector AP is very low. And for the first time after years using Mikrotik and NV2 and hearing lots of people saying nstream is bad for ptmp, that's not what I saw after 10 hours I changed one sector to Nstream. I also changed another sector to 802.11 and everything seems to be better, througput, ping times are consistent and very low! I've always used NV2, but now seeing the results of the other protocols... The only thing I think I might mis is if I get one client with bad signal ruinning the whole sector...

One other thing I notice on two sectors, when I remove the clients bandwidth control so I can make an Internal bandwitdth test to them, If i set the test to udp, when the throughput reaches the maximum speed, all the other clients starts dropping its pppoe session as if one client only overloads the AP and none of the others can pass any data.
Yes i have seen this issue one client can overload AP when have high download and cause other clients to go slow. If you are limiting clients to a certain speed then you dont need to worry of this.
When i did tests with 6.43rc fixes the possibility of one client to overload the AP but overall throughput of the AP is low in 6.43rc. One client can go to 100mbps in 6.42 but in 6.43rc hardly going to 60mbps
 
WirelessRudy
Forum Guru
Forum Guru
Posts: 3082
Joined: Tue Aug 08, 2006 5:54 pm
Location: Spain

Re: Significant improvement for wireless Nv2 PtMP

Thu May 24, 2018 12:07 pm

When i did tests with 6.43rc fixes the possibility of one client to overload the AP but overall throughput of the AP is low in 6.43rc. One client can go to 100mbps in 6.42 but in 6.43rc hardly going to 60mbps
What rc version did you actually test? If this is the latest then MT needs to go back to the drawing board with its NV2.
Show your appreciation of this post by giving me Karma! Thanks.

Rudy R. Puister

WISP operator based on MT routerboard & ROS.
 
lomayani
just joined
Posts: 18
Joined: Sat Jun 17, 2017 7:21 am

Re: Significant improvement for wireless Nv2 PtMP

Thu May 24, 2018 3:43 pm

When i did tests with 6.43rc fixes the possibility of one client to overload the AP but overall throughput of the AP is low in 6.43rc. One client can go to 100mbps in 6.42 but in 6.43rc hardly going to 60mbps
What rc version did you actually test? If this is the latest then MT needs to go back to the drawing board with its NV2.
I tested 6.43rc14. I have not worked with latest version. the sharing between clients is much better in 6.43 but overall throughput is less. So far 6.42.2 is working fine for me in terms of throughput. I can hit 100Mbps under 20Mhz channel which is very ok
 
mohamads
just joined
Posts: 5
Joined: Mon Oct 09, 2017 5:38 pm

Re: Significant improvement for wireless Nv2 PtMP

Sat May 26, 2018 12:39 am

I also didn't notice any significant increase or improvement. The performance even dropped a little. I'd like to know some more info of exactly what this NV2 improvement do and what problems under what circumstances it should solve.
Yep same here send was 11Mbps now 7 to 8 Mbps with 20Mhz but when using 20/40Mhz Ce it goes to 18 or 20 Mbps that doesn't seem to be a fix my mistake was I didn't test it with 40 Mhz before upgrading both AP and Station ( note: station isn't AC).

I was really excited loosing three Mbps is pain in the ... ;) get it
 
jonmansey
Frequent Visitor
Frequent Visitor
Posts: 69
Joined: Sat Sep 18, 2004 3:43 am

Re: Significant improvement for wireless Nv2 PtMP

Tue May 29, 2018 6:51 am

Early results look promising for v6.42.3 fixing this nv2 issue with ar7240 stations, today I installed on an OmniTik and a mixture of SXT5 Lite and SXT5HnD stations, and I no longer get the TX Rate dropping to 6Mbps and the terrible jitter and pauses seen with 6.42.1.
 
Raumaster
newbie
Posts: 31
Joined: Fri Sep 28, 2012 2:18 am

Re: Significant improvement for wireless Nv2 PtMP

Mon Jun 04, 2018 10:11 pm

Yes, I can confirm jitter seems to be lower in version 6.42.3.
 
User avatar
NathanA
Forum Veteran
Forum Veteran
Posts: 793
Joined: Tue Aug 03, 2004 9:01 am

Re: Significant improvement for wireless Nv2 PtMP

Fri Jun 15, 2018 4:03 pm

Even some LTE networks use TDD based TDMA.
Which LTE networks?
Seriously?

https://en.wikipedia.org/wiki/LTE_(tele ... of_LTE-TDD

Each LTE "band" is designated by definition to be either FDD or TDD: https://en.wikipedia.org/wiki/LTE_frequency_bands

We run a LTE-TDD Band 43 network in our little corner of the United States. Equipment supplied by these guys. And, actually...it's pretty awesome.

I've been trying to advocate for MT to build a fixed-install TDD Band 43 CPE not unlike SXT LTE (and hopefully at a similar pricepoint!) but so far they haven't indicated they have any interest. :-(

-- Nathan
 
InoX
Forum Guru
Forum Guru
Posts: 1962
Joined: Tue Jan 09, 2007 6:44 pm

Re: Significant improvement for wireless Nv2 PtMP

Fri Jun 15, 2018 8:08 pm

“Telrad provides a software-defined solution. We don’t have to send anyone up the towers to replace equipment when there is an upgrade or change; we simply do a software upload – which is huge cost savings for the city,” added Joyce.

Now that's really really funny.
So they have invented software upload...
 
User avatar
NathanA
Forum Veteran
Forum Veteran
Posts: 793
Joined: Tue Aug 03, 2004 9:01 am

Re: Significant improvement for wireless Nv2 PtMP

Fri Jun 15, 2018 9:02 pm

Now that's really really funny.
So they have invented software upload...
Hah, I'm not sure where you pulled that quote from, but what they were undoubtedly referring to was the fact that it's an FPGA-based radio head ("software-defined radio"). So to use an example that you could relate to, this would be more like if you had an AP hardware platform that could go from being 802.11n to 802.11ac with just a software load and without any hardware changes. It actually started out life as a WiMAX product, and once it was clear that was a dead-end, they pivoted and released an LTE software load for the existing platform...

-- Nathan
 
solelunauno
Member Candidate
Member Candidate
Posts: 107
Joined: Mon Jul 16, 2012 7:00 pm
Location: Roseto Capo Spulico CS Italy
Contact:

Re: Significant improvement for wireless Nv2 PtMP

Mon Jul 02, 2018 9:43 pm

There is a very unbearable issue with Routeros 6.42 and NV2 wireless wds network. I attached a screenshot and a simple diagram to show what I mean.
I've a simple NV2 WDS network with one WDS AP bridge and some wds stations; If I put a dhcp client on the wds bridge interface in a station, I obtain the message:
"wlan1: bridge port received packet with own address as source address (mac address), probably loop" and the interface will be often blocked.
The same happens if I've the dhcp client on a VLAN in the same bridge.
With previous Routeros (for example I tested on a NV2 network with 6.37.1) this issue is not present.
So I broke some networks after 6.42.X update and I temporarily solved switching to Nstreme.
Does anyone else noticed the same serious issue?
Thanks
You do not have the required permissions to view the files attached to this post.
SL1 Systems srl MTCNA MTCRE
 
Redmor
Member Candidate
Member Candidate
Posts: 248
Joined: Wed May 31, 2017 7:40 pm
Location: Italy

Re: Significant improvement for wireless Nv2 PtMP

Thu Jul 12, 2018 8:53 am

I want more details in changelog, I can't upgrade all my APs everytime I see "Nv2 improvements".
ImageImage
 
solelunauno
Member Candidate
Member Candidate
Posts: 107
Joined: Mon Jul 16, 2012 7:00 pm
Location: Roseto Capo Spulico CS Italy
Contact:

Re: Significant improvement for wireless Nv2 PtMP

Wed Jul 18, 2018 5:07 pm

I want more details in changelog, I can't upgrade all my APs everytime I see "Nv2 improvements".
Do not upgrade if you use WDS.
SL1 Systems srl MTCNA MTCRE
 
Redmor
Member Candidate
Member Candidate
Posts: 248
Joined: Wed May 31, 2017 7:40 pm
Location: Italy

Re: Significant improvement for wireless Nv2 PtMP

Sun Aug 05, 2018 10:21 am

I want more details in changelog, I can't upgrade all my APs everytime I see "Nv2 improvements".
Do not upgrade if you use WDS.
I'm not using WDS, but I would like to see an improvement in Nv2 sync too.
Support said that if a client sees two APs in sync, throughput will be terrible.
How am I supposed to make a client see only one AP on each tower? If I have a client facing the tower north-west, it will see north AP and also west one.
And after upgrading I didn't saw so much improvement, Nv2 isn't acting as a very powerful TDMA.
ImageImage
 
User avatar
fiberwave
just joined
Posts: 8
Joined: Mon Feb 10, 2014 6:20 pm
Location: Nyíregyháza, Hungary
Contact:

Re: Significant improvement for wireless Nv2 PtMP

Sat Oct 06, 2018 6:27 pm

We're using NV2 for 4years now (all APs and CPs), and it's enough.
We had enough of this kind of "business model".

Now we're deploying Cambium epmp2000s that worth every penny, with perfect support.

Cheers
 
mistry7
Forum Guru
Forum Guru
Posts: 1280
Joined: Tue Oct 13, 2009 11:57 am
Location: Germany

Re: Significant improvement for wireless Nv2 PtMP

Sat Oct 06, 2018 9:59 pm

the try out series of about 20 possible hotfixes in the last 10 month for ARM NV2, shows only that it either does not work (hardware problem), or issue is not found.

No matter, you can not satisfy a WISP with try an error, we rebuild cells and use the old cpe for customers in areas that we not Upgrade anymore, because the new CPEs (ARM) are not useable in our network. And we do not going back to 802.11n
 
steen
Member
Member
Posts: 469
Joined: Sat Oct 23, 2010 2:15 am
Location: Sweden
Contact:

Re: Significant improvement for wireless Nv2 PtMP

Fri Nov 02, 2018 12:36 pm

the try out series of about 20 possible hotfixes in the last 10 month for ARM NV2, shows only that it either does not work (hardware problem), or issue is not found.

No matter, you can not satisfy a WISP with try an error, we rebuild cells and use the old cpe for customers in areas that we not Upgrade anymore, because the new CPEs (ARM) are not useable in our network. And we do not going back to 802.11n
Same story here... we have used NV2 since it came out, before that nstreme and prior to that 802.11.
The latter become completely useless in our environment.
Nstreme suffered from cyclic latency problems and connection losses.
NV2 has been _rock solid_ till now. We are cycling out old cpe:s and basestations but it will take years to complete. So upgrading is freezed till further.
 
leonix
newbie
Posts: 26
Joined: Fri Nov 26, 2010 4:13 pm

Re: Significant improvement for wireless Nv2 PtMP

Wed Nov 14, 2018 9:37 am

For my experiences the new NV2-Modes "dynamic downlink" are making the PtMP-Links more sensitive in case one of the clients is weak.
After installing 6.40.9 (before 6.36.2) I was wondering about the loss on the weaker link. Ping looks like below (in case there is some MBit traffic on the other better clients of the accesspoint). Accesspoint is a QRT with N-Hardware, not AC-Hardware:

Code: Select all

12 192.168.23.xx 56 64 4ms
13 192.168.23.xx 56 64 33ms
14 192.168.23.xx 56 64 669ms
15 192.168.23.xx 56 64 5ms
16 192.168.23.xx 56 64 4ms
17 192.168.23.xx 56 64 4ms
18 192.168.23.xx timeout
19 192.168.23.xx 56 64 128ms
sent=20 received=19 packet-loss=5% min-rtt=2ms avg-rtt=50ms max-rtt=669ms
After changing the NV2-mode form the default "dynamic downlink" to "fixed downlink" and ratio 50, and setting TDMA period size from 1ms (or auto) to 3ms it was like before with the 6.36.2.

It saves trouble not to have weak links (mine hast SNR: 45, compared to >55dB on the other clients), but sometimes you do not have an option ;-).
Other useful setting for this scenario (of some weak clients) are:
- set data rate to "configured"
- reduce the connect rate to e.g. 120Mbps by disabling "HT supported MCS" MCS4-MCS7, MCS12-MCS15, MCS16-MCS19, all other must be enabled

Image
With this settings the clients will connect with 120MBps or lower and never higher, resulting in >90% CCQ and lower packet jitter

Image
Here you see: only connect-rates up to 120MBps and good CCQ>90, (however at least for the downlink (TX)).

Just my thoughs,

Leo.
 
n21roadie
Forum Guru
Forum Guru
Posts: 1887
Joined: Fri Aug 07, 2009 10:36 pm
Location: Limerick,Ireland

Re: Significant improvement for wireless Nv2 PtMP

Wed Nov 14, 2018 8:47 pm

@leonix - Not sure why HT supported MCS rates 16-19 are enabled when they require 3 spatial streams and QRT is dual chain?
 
WirelessRudy
Forum Guru
Forum Guru
Posts: 3082
Joined: Tue Aug 08, 2006 5:54 pm
Location: Spain

Re: Significant improvement for wireless Nv2 PtMP

Fri Jan 25, 2019 11:31 am

@leonix; What speeds do you get? I made now extensive tests on at least 6 different P2MP networks of mine (all Mikrotik, some 'ac' only, other mixed. All have mipsbe and arm devices mixed, AP's are either NetMetal or SXT-SA device. Some work in 20Mhz and some in 40Mhz band. Some have data rates fixed, some 'auto'. )
In each and every case I can put twice as much speed to clients and total thoughput on either nstreame or 802.11 as in NV2.

What are your typical NV2 settings? I tried virtually all possible setting to no avail in each of the networks. Everytime NV2 looses big time.....
So it would be interesting to learn about your settings and environment. We always have many other AP's working in the region so interference or high noise levels are common.
Show your appreciation of this post by giving me Karma! Thanks.

Rudy R. Puister

WISP operator based on MT routerboard & ROS.

Who is online

Users browsing this forum: No registered users and 5 guests