Sorry about this double post (the other post is in the Mikrotik Announcements section)
I think this post is important good news that all Mikrotik Admins should be aware of re v6.40

If as a Mikrotik admin you manage any Mikrotik nv2 links - you need to read below:

Re: Nv2-downlink-ratio

Whooo Ahhhh !!!
Wow !!!!!
Great !!!!

I just tested Nv2-downlink-ratio (in v6.40) on one of my nv2 APs. I did NOT upgrade any clients. (Only the AP was v6.40 nv2)
I then performed some btests

#1 with the default Nv2-downlink-ratio = 50
btest UDP both --- I get about 100 meg down to the client and 100 meg up from the client (symmetric up & down results during wireless saturation). This was the same result prior to upgrading the nv2 AP to v6.40

#2 with the default Nv2-downlink-ratio = 80 (this favors more bandwidth sent to clients at the cost of client slower uploads --- during AP wireless saturation)
btest UDP both --- I get about 180 meg down to the client and 27 meg up from the client (non symmetric up & down results during wireless saturation).

#3 with the default Nv2-downlink-ratio = 20 (this favors more bandwidth from to clients at the cost of client slower downloads --- during AP wireless saturation)
btest UDP both --- I get about 27 meg down to the client and 180 meg up from the client (non symmetric up & down results during wireless saturation).

#4 with the default Nv2-downlink-ratio = anything from 80-to-20 (((This test is performed when the AP is NOT wireless saturated)))
all speed tests results are normal bandwidth as previously experienced prior to v6.40 upgrade ((( When the AP in NOT wireless saturated )))

My conclusions:
A - Most normal NV2 APs to clients using the Internet average about-near-around 80 percent of all wireless traffic is from AP to clients.
In this scenario, setting the v6.40 AP Nv2-downlink-ratio setting to 80 can result in a whopping 80 percent more wireless bandwidth to customers during peak wireless saturation periods.
During peak-usage-periods when the nv2 AP is wireless saturated, you can sustain greater bandwidth from the AP to customers (+ 80 percent faster) at the expense of customer upload speeds (80 percent slower) during during peak-usage-periods when the nv2 AP is wireless saturated.

B - When the nv2 AP is not wireless saturated during lite-low wireless usage periods, the Nv2-downlink-ratio setting will not deliver any noticeable differences in wireless bandwidth to or from nv2 wireless customers.

C - I am guessing on this one --- Saturated WDS/PTP links should also benefit using the Nv2-downlink-ratio on v6.40 nv2 links.
If the nv2 WDS/PTP AP is sending more traffic than receiving, then set the nv2 AP Nv2-downlink-ratio to 80 (to improve peak saturation bandwidth)
If the nv2 WDS/PTP AP is receiving more traffic than receiving, then set the nv2 AP Nv2-downlink-ratio to 20 (to improve peak saturation bandwidth)

D - Although ROS prior to v6.40 did not have a Nv2-downlink-ratio setting available - it behaves as if a Nv2-downlink-ratio is set to 50

E - If you want to maintain a symmetric wireless bandwidth for up & down during nv2 AP wireless saturation periods, then set the Nv2-downlink-ratio to 50


Summary:
This new Nv2-downlink-ratio setting in v6.40 is a super wonderful feature than should be able to much better handle nv2 AP wireless peak saturation bandwidths. This setting gives control to the Mikrotik admin to flavor/prefer/enhance/increase the wireless nv2 AP traffic during wireless saturation periods by allowing the Mikrotik admin to prefer up or down bandwidth when his nv2 APs are saturated during peak periods of the day.

Thank you Mikrotik

Note: I am also going to double-post this post into the wireless section of these forums. There may be many Mikrotik admins that do not follow this side of Mikrotik anouncements re this v6.40 topic

North Idaho Tom Jones

again - Thank you Mikrotik

Additional info:

In testing the new v6.40 Nv2-downlink-ratio on a test nv2 AP , I also discovered the following:

With Nv2-downlink-ratio already set to 80
I changed my TDMA Period Size from 2 to 3

I found some very favorable results on my very busy saturated nv2 AP (all tests performed on a saturated nv2 AP with 40+ distant connected clients

A test client customer connected was bandwidth testing prior to TDMA Period Size = 2 & Nv2-downlink-ratio = 80 at the following:
btest both udp 10s Tx 18-21 meg Rx 2.5 meg
btest send udp Tx 16 meg
btest receive udp Rx 8.2 meg

A test client customer connected was bandwidth testing with TDMA Period Size = 3 & Nv2-downlink-ratio = 80 now tests at the following:
btest both udp 10s Tx 76 meg Rx 11 meg
btest send udp Tx 58-87 meg
btest receive udp Rx 37-83 meg

By changing my nv2 v6.40 AP
from; TDMA Period Size = 2 & Nv2-downlink-ratio = 80
to; TDMA Period Size = 3 & Nv2-downlink-ratio = 80
I achieved btest speeds from the AP to the client at almost 400 percent faster throughput!!!

Question: Would somebody please check my results on their system and confirm or deny my results ? If this is confirmed, the average WISP might have the ability to increase average peak-usage/saturated wireless network speeds to customers anywhere from 100 percent to 400 percent.

North Idaho Tom Jones

another update:

Testing again - with over 70 distant clients with distance km ranges from 2k to 4k and testing to a 3k client
with the nv2 AP saturated with wireless traffic
I was able to btest at 10 to 40 meg to the test customer (during full saturation). (10 to 40 meg to the customer and about 5 to 15 from the customer) - using 3ms with 80 percent on the nv2 settings.

Now I know that anytime you run a btest on a wireless network, that you are effecting everybody on nv2 wireless network - and that everybody will suffer - however - 10 to 40 meg to the customer is pretty darn good with 70 distant customers on a nv2 wireless saturated AP.

North Idaho Tom Jones

Please make the test in tcp/ip

thank you Giuseppe

Please make the test in tcp/ip

thank you Giuseppe

OK I just performed the same btest using TCP (not UDP this time).
Same customer I have been testing to - however this time we now at entering peak-usage times of the day

btest TCP send to customer 20-second average 21.4 Meg
btest TCP receive from customer 20-second average 15 Meg
btest UDP send to customer 20-second average 48 Meg
btest UDP receive from customer 20-second average 19 Meg

Prior to the v6.40 AP changes, this test customer was barely able to hit 10 UDP during peak usage periods (with 50 to 75 other clients on the AP at the same time)

I will learn more this weekend. I graph all traffic so that I can come back and compare/look at any 5-minutes/hour/day/week/month/year

There is a probability that I may need to change from 50/50 now 80/20 to something like 75/25 or 70/30 or 65/35 or 60/40 or 55/45 --- Some testing will be needed

North Idaho Tom Jones

Hi Tom,

Thank you for doing this testing and publishing your results.

Hi TomjNorthIdaho,

first of all thanks for sharing your experience with us. and i see that you are testing point to multi point links, what about point to point links ? i test a little and see that nv2 higher ping then nstreme. do you have any experience about latency?

Thanks

Thanks for sharing your findings Tom! Cannot wait to do some testing.

Hi friends, could you tell me if the tests were done with dynamic or fixed downlink / uplink ratio. Thank you

Hi friends, could you tell me if the tests were done with dynamic or fixed downlink / uplink ratio. Thank you

fixed downlink

I've tested on Omnitik AC (set on A/N Ce channel) (15 SXT Clients connected, signals 45-60)
when fixed mode selected Ratio=60,70,80% throughput is worst than ever, I got better throughput with dynamic-downlink selected, but not as good as nv2 in v6.37.1
This one I could not understand why I have far better throughput with nstreeme, its like 100% better than nv2 (P2MP scenarios), what really sucks using 802.11 I got better throughput than nv2
I've also made test SXT SA sector, 10 clients connected I can tell you nstreeme can give up to 80-90mbits, nv2 max 30-40mbits TCP

In the last update only on P2P scenario fixed mode=80% NV2 Period Size=3 I got 15-20% increase of throughput from v6.37.1,

I really don't know why nv2 protocol is such a disaster for me (speaking from my experience ), we use also ubq, airmax do what its suppose to do and don't get me wrong I love mikrotik

its almost 4 years when nv2 come out but still almost on all P2MP AP-towers nstreeme protocol is selected....

@Lakis Same here NV2 & TCP speed test & streams = disaster , Nstreme & pure 802.11N Much much better.
New 6.40 ROS & NV2 fixed ratio 80/20 ratio worse than dynamic.
Cambium same hardware @ 170mbit/s DOWNLOAD TCP & UPLOAD 20mbit/s !..... from sector antenna p2mp 50 CPE @ 40mhz.

I tested on few nv2 sectors ROS v6.40
nv2 ratio 80 fixed vs 50 dynamic .
And all test is this some .

I not confirm downlink speed increase on this mode.

maybe in 40mhz channels ? (i use always only 20mhz )

Idaho Tom are your AP's 802.11n or 802.11ac? I've personally noticed that NV2 performs HORRIBLE with AC protocol, have to use Nstreme but this new "fixed downlink" is only available in NV2 correct?

Idaho Tom are your AP's 802.11n or 802.11ac? I've personally noticed that NV2 performs HORRIBLE with AC protocol, have to use Nstreme but this new "fixed downlink" is only available in NV2 correct?

Most of my nv2 APs are N (N-only) 1x1
I only tested Nv2-downlink-ratio on N-only nv2 networks (with 24 to 65 client connections) all distant clients

I did test on an AC 2x2, but I do not remember the results.

I have not gone back to re-verify my results - yet.

FYI - if you can set your cell radius to 10 (or as low as possible), I find this often helps.
Also - I overclock my APs to the second-to-fastest cpu speed setting if they are not factory default at the fastest speed setting. I find this often help.
FYI - my nv2 APs are all strictly a WAN-to-vlan (wan-to-Ethernet) bridge. My aps are not doing NAT - not doing IP-dhcp - not doing firewalling - only AP and WAN of AP on a bridge.


North Idaho Tom Jones

dynamic downlink ratio 75% appears to working best so far but NV2 AP and NV2 PTP ( tried Nstreme but link kept disconnecting ) may not be ideal for PPPoE clients

dynamic downlink ratio 75% appears to working best so far but NV2 AP and NV2 PTP ( tried Nstreme but link kept disconnecting ) may not be ideal for PPPoE clients

What dynamic downlink ratio settings have you tried and what was the aprox difference in down/up speeds ?

I have not tested 75 yet.

North Idaho Tom Jones

Interesting information

Last week the day after v6.40 came out, I changed all of my nv2 dynamic downlink ratio settings on all of my APs

Today I was looking at a specific Cacti bandwidth graph servers which graphs a v6.40 client that makes a WDS nv2 link to my v6.40 AP.
This local wds client uploads to bandwidth to a remote AP tower I have which has 8 other nv2 APs for customers to connect to.
The remote tower wds AP has the "DownLink Ratio" set to 30 (I want to prefer traffic from the WDS client to the WDS AP.
I happened to notice the average CPU load on the WDS client dropped some after v6.40 and downlink radio settings and average bandwidth went up.. When I zoom in on my Cacti graph, it looks like pre-v6.40 CPU load was peak hitting 18 and now CPU peak load is hitting less than 12. This is measured at my busiest peak period of the day.

Interesting

EDIT: I also noticed the graphed heat sensor on the wds nv2 client dropped a little (and we have been experiencing hotter than normal days the last few days - I would of expected it to be hotter with the last few 100+ degree days)

North Idaho Tom Jones

TomjNorthIdaho less 5% CPU load is almost noting
in v6.40 Changelog
*) wireless - reduced load on CPU for high speed wireless links;

yes with nv2 downlink settings there is increase of throughput but only I can see benefit on P2P
on P2MP its awful.
I have made tests on 19km link (BaseBox5 Jurlios Antena A/N Ce channel signals 56/56)
When nstreeme protocol selected I got rock solid 115-120 mbit TCP (btest 5 connections)
8011.2 protocol 70-80mbits (btest 5 connections)
nv2 protocol downlink 75% period size=3 I got 60-126 mbit TCP, throughput always go up and down average is 75-85mbit (also made tests of all variants period size 2,3,4,5,6...auto, downlink 60-80%)
(btest 5-20 connections)

n21roadie@: when nstreeme selected please make btest only receive and only send see the difference. (Disconnect is possible one side collocation interference)

dynamic downlink ratio 75% appears to working best so far but NV2 AP and NV2 PTP ( tried Nstreme but link kept disconnecting ) may not be ideal for PPPoE clients

What dynamic downlink ratio settings have you tried and what was the aprox difference in down/up speeds ?

I have not tested 75 yet.

North Idaho Tom Jones

I try to minimize downtime for clients when attempting to tweak the network, the very basic tests will be check ping times and speedtest.net this is what customers use so must look at those results first with reference to a service package the test CPE is authenticated to, in other words if the package was 5/2 down/up - during peak usage hours what is the down/up speeds and ping times using PPPoE authentication, I also experiment with custom queue's

n21roadie@: when nstreeme selected please make btest only receive and only send see the difference. (Disconnect is possible one side collocation interference)

It must be co-location interference as the disconnections occur during the first few mins after wireless registration as the data rates between PTP AP / Station sides are being negotiated, so the link is not active long enough for any type of a btest .

n21roadie - re speed testing

FYI - how I perform speed testing - thought you might like to know.

I have two in-house btest servers I use to test to remote customer Mikrotiks.

One btest server to/from customer Mikrotiks goes through all of the bandwidth limitations each unique customer has purchased.
All customer purchased speeds use the following formula for "Customer-Account-Purchased-Speed":
- ( Customer-Account-Purchased-Speed x 1.05 ) = Customer-Download-Speed-Setting
- (( Customer-Account-Purchased-Speed x .2 ) x 1.05 ) = Customer-Upload-Speed-Setting
Thus a customer 25 meg account, should actually measure at 25 meg down and 5 meg up when the customer performs a speedtest
My #1 One btest server is able to measure this pretty closely to what a customer is paying for and actually getting.

Note: the 1.05 is added to the speed to allow for TCP/IP overhead. Many customers do not understand that a 25 meg account can almost never dead-on hit 25 meg (due to overhead). Thus by adding the additional .05 percent to the bandwidth settings, a 25 meg customer can normally speedtest to 25 meg (and this makes the customer happy).

My Second btest server I use to test to customers bypasses all customer speed/bandwidth settings. This Second btest server is able to measure the maximum bandwidth capability that we actually have to the customer.

FYI - I also have a mini-speedtest server at my NOC - but that requires interacting with customers to http to my speedtest server.

When I measured the nv2-downlink-ratio performance settings, I use my Second btest server and I used it during peak saturation hours of the day.

Still - measuring performance throughput on a busy network is pretty difficult to detect minor speed differences because the network is never the same between tests - on a busy wireless network with 20 to 50 clients, somebody is always doing something different every second.

North Idaho Tom Jones

n21roadie@: when nstreeme selected please make btest only receive and only send see the difference. (Disconnect is possible one side collocation interference)[/quote]
It must be co-location interference as the disconnections occur during the first few mins after wireless registration as the data rates between PTP AP / Station sides are being negotiated, so the link is not active long enough for any type of a btest .[/quote]

n21roadie collocation problem dude this shape of antenna is the real stuff try it

n21roadie@: when nstreeme selected please make btest only receive and only send see the difference. (Disconnect is possible one side collocation interference)

It must be co-location interference as the disconnections occur during the first few mins after wireless registration as the data rates between PTP AP / Station sides are being negotiated, so the link is not active long enough for any type of a btest .[/quote]

n21roadie collocation problem dude this shape of antenna
jirous.jpg
is the real stuff try it

@Lakis many thanks for your Antenna suggestion which I must try, but one site to site is only 5KMs apart so i will use RF Elements horn with Mikrotik adapter

@TomjNorthIdaho - so if I am correct in my calculations - advertised service of 25 / 5 is setup as 26.25 / 5.25! - must edit my services to allow for the TCP/IP overhead,

On a ongoing issue we have noticed that customers will get exactly the advertised bandwidth numbers off peak but this drops considerably as AP bandwidth demand increases and its not backhaul limitations but my suspicion is that its a shortcoming in Mikrotik having almost everything done in software and not a combination of both hardware / SW.

For what reason does changing the parameters of nv2-mode / nv2-downlink-ratio cause reconnection of wireless clients?
It is possible to implement so that commands: did not cause reconnection of wireless clients to the AP?

In our usage pattern, "dynamic-downlink" in working time and "fixed-downlink " in the evening are more appropriate.

@Lakis many thanks for your Antenna suggestion which I must try, but one site to site is only 5KMs apart so i will use RF Elements horn with Mikrotik adapter

Those are intended for sectors... for a PTP either a UltraHorn TP or UltraDish TP would be better

UltraHorn TP


UltraDishTM TP 400


Coupled either with a simper 5n radio


or a
TwistPortTM Shielded Adaptor V2 for RouterBoard + routerboard if AC is desired.

Those are the most clever and apparently most carefully engineered while still not so expensive shielded antenna systems to avoid co-location interference I've found... have had them in my hands but each time I tried to source them, no one had all the required components in stock.

Nv2 got better in terms of interference on AC chipsets, but still, it makes a night and day difference in Nv2 performance and stability, so investing on shielded ones pays quickly.

Anyone tried them?

@Lakis many thanks for your Antenna suggestion which I must try, but one site to site is only 5KMs apart so i will use RF Elements horn with Mikrotik adapter

Those are intended for sectors... for a PTP either a UltraHorn TP or UltraDish TP would be better

Those are the most clever and apparently most carefully engineered while still not so expensive shielded antenna systems to avoid co-location interference I've found... have had them in my hands but each time I tried to source them, no one had all the required components in stock.

Nv2 got better in terms of interference on AC chipsets, but still, it makes a night and day difference in Nv2 performance and stability, so investing on shielded ones pays quickly.

Anyone tried them?

As I have used them already and the distance for PTP is 5KMs, the 30 degree sector (?) is my first choice as they behave exactly like a dish the radiation beam is not H + V as we know it but strictly conical and elliptical with distance of 8Kms + higher frequency gives a lot more ERP ?

@TomjNorthIdaho - so if I am correct in my calculations - advertised service of 25 / 5 is setup as 26.25 / 5.25! - must edit my services to allow for the TCP/IP overhead,

On a ongoing issue we have noticed that customers will get exactly the advertised bandwidth numbers off peak but this drops considerably as AP bandwidth demand increases and its not backhaul limitations but my suspicion is that its a shortcoming in Mikrotik having almost everything done in software and not a combination of both hardware / SW.

You are correct re " ... advertised service of 25 / 5 is setup as 26.25 / 5.25 ... "

TCP/IP overhead is about .05 of the traffic

FYI - There are several methods to govern individual customer up/down bandwidth. Here is how I do my wireless network:

- APs , many many many and many different locations all APs have the same SSID and same nv2 settings using (N-only 20/40 Ce). No two APs share the same frequency.
All APs and customer mikrotiks are set for Hw Retries 3
All v6.40 APs now use nv2 settings of (TDMA Period Size = 3ms -&- Downlink Ratio = 75). I am still fine-tuning/testing these settings.
All APs only bridge the wlan to a lan (actually one of my vlans).
None of my APs are dhcp servers
None of my APs have any IP related services.
All of my APs and client Mikrotiks have the CPU clocked at the second to fastest speed setting. If a new Mikrotik comes in from the factory at the fastest CPU speed settings, then we leave it there.
Almost all of my APs are on fiber back to my core office NOC.
By keeping the AP CPU usage low, I gain network throughput.
No part of my network is using PPOE

- Client Mikrotiks default-gateway (through an AP) to one of my PfSense routers (captive-portal/walled-garden) servers in my office.

- All unique/individual customer bandwidth rate limiting is performed by a PfSense server. Each client Mikrotik has a unique wan MAC accress. My PfSense server uses captive-portal which governs the up/down speed of each MAC address. (FYI - If a PfSense server does not have a MAC address in the system, then it redirects all customer web traffic to a web server which says to call our office. Anyways - on my PfSense servers is where I configure the "... 25 / 5 is setup as 26.25 / 5.25 ..." speeds per customer MAC address.

North Idaho Tom Jones

My results are horible. From ~65mbps is down to 30mbps.

InoX, which kind of hardware? N or AC?

AP is .ac but clients are .n, so it's N.

Not exactly... Nv2 is tightly bound to the radio chipset ROS driver, so if AP is AC it isn't the same as setting the radio in N mode, ROS drivers for AC chipsets are different than drivers for N chipsets.

Analogy: you can make a spectral-scan on N hardware, but you can't on AC hardware, no matter if set to N mode, because of the drivers; AC driver lacks that feature presently.

Results from this thread seems to indicate this new Nv2 feature works much better when used on N hardware than on AC hardware, hence my question.

I am pretty sure that the new nv2 downlink-ratio is helping my network especially during peak saturation times.

The image below shows a typical city-wide customer wireless day before and after v6.40 with downlink-ratio set at 75
North Idaho Tom Jones

You did this tests without upgrading the CPEs ?.
regards

You did this tests without upgrading the CPEs ?.
regards

I have performed the tests with and without upgrading the clients. Clients before and after upgrade appear to return similar results. The big result I got for the wireless network was on the nv2 APs.

North Idaho Tom Jones

Does anyone have any insight on the "NV2 Sync" feature? Any test results with how the two Access Points co-exists on same tower and same channel?

Does anyone have any insight on the "NV2 Sync" feature? Any test results with how the two Access Points co-exists on same tower and same channel?

When it first came out, I tried it and it did not want to work for me , so I just gave up and figured that it was just me now knowing what to do to make it work properly.

Mabey there is some better documentation and examples now ...

North Idaho Tom Jones

With fixed downlink I can confirm a little improvment in wireless performance around 30% in peak time (40 Mb/s max throughput) our configuration is:

downlink ratio: beetween 60 to 67
TDMA period size: auto

with TDMA period size fixed from 2 to 5 the improvment is minimal.

Giuseppe

FYI - There are several methods to govern individual customer up/down bandwidth. Here is how I do my wireless network:

- APs , many many many and many different locations all APs have the same SSID and same nv2 settings using (N-only 20/40 Ce). No two APs share the same frequency.
All APs and customer mikrotiks are set for Hw Retries 3
All v6.40 APs now use nv2 settings of (TDMA Period Size = 3ms -&- Downlink Ratio = 75). I am still fine-tuning/testing these settings.
All APs only bridge the wlan to a lan (actually one of my vlans).
None of my APs are dhcp servers
None of my APs have any IP related services.
All of my APs and client Mikrotiks have the CPU clocked at the second to fastest speed setting. If a new Mikrotik comes in from the factory at the fastest CPU speed settings, then we leave it there.
Almost all of my APs are on fiber back to my core office NOC.
By keeping the AP CPU usage low, I gain network throughput.
No part of my network is using PPOE

North Idaho Tom Jones

A couple of Questions:

- What is the argument to use Hw Retries setting = 3? I never tested it but in my thinking higher was better. So I have all CPE's set to 15 and AP's to default 7...... Maybe I should re think that?
- I believe you started this tread with NV2 setting; TDMA period size=2ms and Downlink ratio=80. Why are you now at 3ms and 75?
- Did you already test AP's that have 'ac' on board? With radio set to 'N-only' , 'A/N' or 'A/N/AC'? Most of my AP's are Netmetals and now several OminTiks-ac too. But only some smaller P2MP networks are running with all CPE's in 'ac' mode. Any experiences to share in the 'n' versus 'ac' mode?

- ROS 6.40 you'd refer to. Actually we are at 6.40.5, we have 6.41.3 and 6.42rc49 that is said to have spectaculair NV2 improvements......... Already tried any of these?

What are we talking about? 40Mbps total? We are in 2018 !!!
We need at least 40Mbps per user offered and 150-200 aggregate per AP. Smart nv2, sync, better cpe, spectral scan etc...
No major upgrade to wireless since 2013. 5 years ago.
Just not enough this days...

@TomjNorthIdaho

Just double check first of all you have tested NV2 new features by which mode=fixed downlink and that you swapped to dynamic downlink and you got better results,is it right?

Thanks

Have always been an adamant Mikrotik supporter and still is. Will always be using there switches and routers. Nothing out there with same capability’s at the price. Unfortunately they do not develop their own radio equipment in house, which is where the problem is, especially in noisy environment. There is only so much you can do from the software side. Play with the NV2 download ratios and mode. It did significantly improve speed, but maybe 20 Mb/s. Still using Mikrotik extensively. As you mentioned, for the past few years there radio side started lagging behind, up to the point where we, as a WISP, had no choice and had to start using different make of WIFI to keep up with the bandwidth demands.

...... Unfortunately they do not develop their own radio equipment in house, which is where the problem is, especially in noisy environment. There is only so much you can do from the software side. .....

I totally agree with you that software can only do so much also for wireless they need to go back basics and use only what will give maximum performance, once done add on features or functions of ROS that don't impact on wireless performance ?

When we started up, many moons back, we were the only WISP and Atheros chips were great. Then things started getting more and more crowded and data usage sky rocketed. Would today at any given time scan around 35 different AP's of whom i am aware of 5 WISP's. Handling interference/filtering in my opinion, is the biggest bottle neck. The newer Mikrotik hardware is quite powerful, doubt this is a problem. For intrace sake, in 2008 we used 90GB of data for the year and we were the only AP. Up to now, for the year we have already used 101TB with no stop in sight competing for space with all the other AP's.

I wonder if software is part of the problem as other vendors who use similar chipsets get better performance?
Another vendor uses the A,B,C labelling for its wireless products and appears to work much better from reports,

I am sure that is also part of it. Can imagine it is difficult to develop your software around what the radio chipsets is capable off. Most of the other vendors do their own hardware development, giving the possibility to change the radio as well. In my opinion, all of them is using some form of Linux based operating system.

Yeah, but one of these "other vendors" show us perfectly that the most important part here is AP side. They reuse existing old SXTs or NS5's and make users happy for a time being with speeds up to 30-50M per client and with sectors toping at 120-150M without visiting their households. They simply browse and don't feel any shortage of bandwidth. Even IPTV/OTT became possible for private houses. Replacing equipment at AP sites are far more simplier and cheaper than visiting thousands of customers and buying them new CPEs. Even gradually replacing CPEs to other vendor wouldn't be a problem, if there only were enough spectrum to operate both brands.

We've already started slowly moving to different eq, but still have thousands of SXT's (Lite5, ac, sq), SEXTANT's, QRTs, DynaDishes operating in our network. I still thank MikroTik very much for keeping their legacy wireless usable that long. And if they somehow miraculously developed something similar to other vendors AP-side equipment with similar capabilities, RouterOS alone would hold their loyal base from certain WISPs. I simply can't stand these web based GUI's or CLI's from UBNT, ePMP, etc.. and I like having unified solutions with environment I'm familiar with. So MT, please hire some workforce, reverse engineer some products in the market and revive the very reason you've once risen to where you are now - wireless.

And by the way, the introduction of TDD ratio setting, was the last major improvement we've witnessed recently. Dynamic 80/20 increased wireless DL traffic up to 20%. That's great, considering that it only took software update and some tweaking. Initial tests of NV2 improvements with high number of P2MP clients haven't showed anything appreciable, but I'll do some more testing.

I hear you and can't agree more.

Yeah, but one of these "other vendors" show us perfectly that the most important part here is AP side. They reuse existing old SXTs or NS5's and make users happy for a time being with speeds up to 30-50M per client and with sectors toping at 120-150M without visiting their households. They simply browse and don't feel any shortage of bandwidth. Even IPTV/OTT became possible for private houses. Replacing equipment at AP sites are far more simplier and cheaper than visiting thousands of customers and buying them new CPEs. Even gradually replacing CPEs to other vendor wouldn't be a problem, if there only were enough spectrum to operate both brands.

We've already started slowly moving to different eq, but still have thousands of SXT's (Lite5, ac, sq), SEXTANT's, QRTs, DynaDishes operating in our network. I still thank MikroTik very much for keeping their legacy wireless usable that long. And if they somehow miraculously developed something similar to other vendors AP-side equipment with similar capabilities, RouterOS alone would hold their loyal base from certain WISPs. I simply can't stand these web based GUI's or CLI's from UBNT, ePMP, etc.. and I like having unified solutions with environment I'm familiar with. So MT, please hire some workforce, reverse engineer some products in the market and revive the very reason you've once risen to where you are now - wireless.

Could have been my words!

And back to the topic

And by the way, the introduction of TDD ratio setting, was the last major improvement we've witnessed recently. Dynamic 80/20 increased wireless DL traffic up to 20%. That's great, considering that it only took software update and some tweaking. Initial tests of NV2 improvements with high number of P2MP clients haven't showed anything appreciable, but I'll do some more testing.

I've done a 28 client P2MP network yesterday. Overal AP's throughput doubled, single clients had higher throughput and two really poor performing client were made to 'moderate performing' clients. What did I do? Upgrade ROS to 6.42rc49, upgrade firmware, set fixed download ratio 75/25 and set hw-retries to 3 (always used 15...) So far on the combined upgrade/tweaking good result!

Can also try setting TDMA Period size to 3ms instead of auto.

Don't forget to play with NV2 Radius.

If all clients are less than 10 and you have a NV2 Radius of 30 , it will run a bit slower.

I try to set a NV2 Radius setting of furthest client + 10 percent. Thus if my furthest client is 20 , I would use 22. If my furthest client is less than 10, then I will use a setting of 10.

Also - something I have wondered about but have not tested .... Is a longer nv2 pre-shared key slower than a small/short/tiny pre-shared key ???

Also - Don't fck with the Tx Power settings on the AP or Client Mikroti devices !!!
When you increase TX power , you also increase signal distortation which always results in a slower rate connection.
Keep all Tx Power settings at default.
The only exception - only exception - only exception is if you only want to connect at the slowest wireless rate and stay low & slow.

With thousands of wireless clients and hundreds of APs since the early 2000's , I am finally getting a hand on what works and what blows....

FYI - nothing beats fiber

North Idaho Tom Jones

Don't forget to play with NV2 Radius.

If all clients are less than 10 and you have a NV2 Radius of 30 , it will run a bit slower.

I try to set a NV2 Radius setting of furthest client + 10 percent. Thus if my furthest client is 20 , I would use 22. If my furthest client is less than 10, then I will use a setting of 10.

Also - something I have wondered about but have not tested .... Is a longer nv2 pre-shared key slower than a small/short/tiny pre-shared key ???

Also - Don't fck with the Tx Power settings on the AP or Client Mikroti devices !!!
When you increase TX power , you also increase signal distortation which always results in a slower rate connection.
Keep all Tx Power settings at default.
The only exception - only exception - only exception is if you only want to connect at the slowest wireless rate and stay low & slow.

With thousands of wireless clients and hundreds of APs since the early 2000's , I am finally getting a hand on what works and what blows....

FYI - nothing beats fiber

North Idaho Tom Jones

Indeed, set the radius.
Good question about the length of the NV2 password. I don't know how many times this is syncd between devices. If this is for each frame.... pff that could make a difference.
Should try on a link with, and without NV2 passphrase....

Power setting only use to decrease power. If an AP has many clients connected with -50dB one client that connects with -30dB gets better change of communicating (in 802.11 RTS/CTS mode). I don't know if this is true in NV2 (don't think so). But it is not recommended to have a client hit the AP with more then -30dB signal anyway. It overpowers the AP's receiver circuits (they say. I never had seen problems with even -15dB link. All I think to see is maybe less throughput. But no scientific measurements done here....)
So yeah, if a client is that close to an AP that the signal comes in with better then -30 I would reduce the power. (It would be nice if Mikrotik could build some power limited in the software, like Mimosa has.)

FYI - We beat fiber in price!

We are rural, don’t have fiber yet. Actually our WISP has, but at a price that bleeds you dry.
We used to run nv2 without password and then started running into problems when the competitors also started using nv2, we started using password. Did not find any significant change in speed. Also regarding distance, since you cannot link much more than 30 clients and radio travel basically at the speed of light. Doubt there will be much difference in the distance setting. However, what we did find which wasn’t mentioned before, if you have one client on the AP with interference or signal above -60 dB, you will bring down the AP throughput for all clients. Bit strange for TDMA, but guising allocating more time slots to client re transmitting packages.

We are rural, don’t have fiber yet. Actually our WISP has, but at a price that bleeds you dry.
We used to run nv2 without password and then started running into problems when the competitors also started using nv2, we started using password. Did not find any significant change in speed. Also regarding distance, since you cannot link much more than 30 clients and radio travel basically at the speed of light. Doubt there will be much difference in the distance setting. However, what we did find which wasn’t mentioned before, if you have one client on the AP with interference or signal above -60 dB, you will bring down the AP throughput for all clients. Bit strange for TDMA, but guising allocating more time slots to client re transmitting packages.

Exactly that last is something they said to have improved now in the latest rc!

- In general , I've found the average sweet-spot for signal strength to be in the range of -45 to -60 (-50 normally works best on average)

- On an AP with many clients , it often takes only a single weak/bad client ACTIVE connection to degrade all clients on an AP.
Example:
... 5 to 20 clients connected with good strong signals , great CCQ , great connect rates
... 1 (or more clients) connected with medium to weak signals , lower or low CCQ , low/slower connect rates...
... Peak usage hours & everybody watching Netflix (trying to stream 3 meg up to 15 meg)

The weak - low CCQ - low rate-connected clients also trying to watch Netfilx may experience wireless retries. Also - because these weak/poor client connections are connected at a slower wireless connect-rate , they require more/longer time periods to receive and transmit (client to AP data). The larger time periods for these weak clients takes away AP air time that the AP would normally be using for everybody else also watching Netflix. Thus , all active clients begin to suffer - and possibly even more re-tries and more Random-Early-Detects are created for everybody , which again results in a cascading downward slope to even poorer AP communications to/from wireless Clients.

So - note ... you can't go by signal strength alone. It is possible for everybody to have great signal strengths , but ... if one remote Client has interference caused by a customer-owned in-house wireless AP , then the CCQ will be lower resulting in some wireless packet retries between the AP and Clients. Which again , starts to result in more Random-Early-Detects and more retries system wide. So - also look at your CCQs when under peak usage times when everybody is busy. CCQ might look great when everybody is idle - but it will change when the wireless network starts to get busy and/or saturated.

Just some of my thoughts ...
North Idaho Tom Jones

- In general , I've found the average sweet-spot for signal strength to be in the range of -45 to -60 (-50 normally works best on average)

- On an AP with many clients , it often takes only a single weak/bad client ACTIVE connection to degrade all clients on an AP.
Example:
... 5 to 20 clients connected with good strong signals , great CCQ , great connect rates
... 1 (or more clients) connected with medium to weak signals , lower or low CCQ , low/slower connect rates...
... Peak usage hours & everybody watching Netflix (trying to stream 3 meg up to 15 meg)

The weak - low CCQ - low rate-connected clients also trying to watch Netfilx may experience wireless retries. Also - because these weak/poor client connections are connected at a slower wireless connect-rate , they require more/longer time periods to receive and transmit (client to AP data). The larger time periods for these weak clients takes away AP air time that the AP would normally be using for everybody else also watching Netflix. Thus , all active clients begin to suffer - and possibly even more re-tries and more Random-Early-Detects are created for everybody , which again results in a cascading downward slope to even poorer AP communications to/from wireless Clients.

So - note ... you can't go by signal strength alone. It is possible for everybody to have great signal strengths , but ... if one remote Client has interference caused by a customer-owned in-house wireless AP , then the CCQ will be lower resulting in some wireless packet retries between the AP and Clients. Which again , starts to result in more Random-Early-Detects and more retries system wide. So - also look at your CCQs when under peak usage times when everybody is busy. CCQ might look great when everybody is idle - but it will change when the wireless network starts to get busy and/or saturated.

Just some of my thoughts ...
North Idaho Tom Jones

Yet again I can confirm all this. Since a year we really started to realize how important it is everybody has good signal and preferably good CCQ.
Now standard practise is we basically don't accept clients with less then -60dB more but actually look for -50's.
It depends a bit on the AP too. We have one AP with 8 clients but one has only -70dBm even with a 27,5dBi antena. Not ideal but its manageable.

Another AP has 28 clients on we still have one that has a poor connection. Signal -55 but poor CCQ. Although scan doesn't show any channels near, there must be something that interferes. This client definitely needs more investigation to solve the issue. Especial since to up to half a year ago it all worked fine for him.....

Getting better CCQ's is also achieved by setting some fixed connection rates only, make sure all units can get the ones you set and have at least one lower and we set two with the same rate for the sigle stream. Some CPE's have better stable signal on a signle stream than with both.
And by setting the mcs rates fixed the CCQ's are much higher. But I am still not 100% convinced is this indeed a show of better links, or is it just optic illusion since the rates jump up and down less and thus less resends only because of this...

Speaking of connection rates and CCQ ...

When you reset/reboot an AP - or something that causes all wireless clients to disconnect and re-connected , the CCQ & signal strengths & signal-to-noise & connection rates do NOT give you a true picture of how well all of your client connections are to the AP. - - - Here is the reason why:

- When a client (or many or all clients) connect to an AP , the clients will normally connect at the basic-rate (slowest supported) connection rate. Depending on the wireless protocols , this could be a 6 Meg Tx/Rx wireless connection rate.
- All wireless cards (in general) have a stronger/more-power/higher-db transmit power at the slowest supported connection basic-rate. Thus , at first , thus when a client first connects the Client and AP have stronger more-powerful transmit power. The slowest basic connection rate can easily be 10 db or more (stronger) than a connection at the fastest wireless rate possible.
- All wireless cards (in general) have a better receive sensitivity at the slowest supported connection basic-rate. This results in the wireless card in being better able to listen and receive (aka , pick out a weak signal in the background RF noise). The slowest basic connection rate might receive 10 db or more (better) than a connection at the fastest wireless rate possible.
----- So far , my point is that initial connection rates may look good and show decent Signal-to-Noise ratio , decent CCQ , strong signal strengths on all new fresh connections.
- As the packet count (bandwidth) starts to increase from traffic across wire wireless link , the wireless cards will begin to shift connection rates to faster connection rates and then again later shift connection rates to even faster connection rates. Almost every time a wireless connection rate increases , the wireless card receive sensitivity will get worse (weaker) and the wireless cars transmit power will also be lower (weaker).
- Wireless cards and wireless protocols will auto up-shift connected rates after a fixed number of wireless packets make it through the wireless network. This will continually auto-repeat until they either hit the fastest supported connection rate -or- there is an error or errors at the now faster wireless connection rate. When this happens , there is a packet retry (re-transmit) period that occurs. When the packet retry (re-transmit) count hits a certain number , the connection rate will auto lower (decrease) to a slower wireless connection rate.
- Often , client connection rates may remain at a slow (basic rate) , until the wireless client actually passes traffic on the wireless network.
----- My point I am trying to establish here is that on busy active wireless networks , all connection rates will ramp up to the fastest reliable wireless connection rate , then periodicall auto rate-shift one speed faster and auto-rate shift back one speed slower. This will continue. To you , all you see is the established connection rate after some wireless bandwidth. (((Note - each time there is a rate shift , there is a slight delay in the AP-to-Client & Client-to-AP data stream.
- Note , that when a wireless connection rate increases, the channel width may also increase. So what started as an initial 20-MHz wide channel width could end up with a much faster connection rate using 40-MHz, 80-MHz or even 160-MHz channel widths. These additional channel widths also need clean/clear/low-noise on those additional frequency bands. ((( Example - check out Ce vs Ceee channel width requirements ))) ((( You can kinda think of the "C" as an initial 20-MHz wide channel and each "e" as an additional 20-MHz channel width. ))) As connection rates auto-increase and fall back , different channel widths "e" may be added or removed from the wireless connection.

In a Mikrotik there are some settings available to configure the wireless cards. They include:
-- Basic-Rate
-- Maximum supported connection speed
-- Retry settings (You may want to consider testing how this effects the throughput of your network)
-- Disconnect timeout settings
-- Channel width settings
-- and many other settings , including NV2

So , when investigating how well your wireless network is performing (AP to clients and clients to AP) , you should look/check during wireless peak usage hours when customer are placing the highest throughput demans on your wireless network. An O-Dark-30 wireless network configuration might look good when nobody is awake and using the network and suddenly horrible when everybody is doing everything at the same time.

If you use btest as a tool when testing a wireless network , consider running many btests at the same time to a large pool of connected wireless clients all at the same time on the AP. On multiple btests , set your up/down speeds for 75 percent traffic to a remote wireless customers (AP to customer) and 25 percent traffic from wireless customers (customer to AP).

Somewhat related - you might want to read up on "Random Early Detect" aka "RED".

I assume almost all of this is well known to most wireless/network engineers who have been around and have experience - however - if any of this information help anybody , then I feel good.

North Idaho Tom Jones

A very good post!

- In general , I've found the average sweet-spot for signal strength to be in the range of -45 to -60 (-50 normally works best on average)

Could this high signal level just having AGC type of circuit reduce the gain so as not to overload the input stages and this reduction also reduces interference?

- On an AP with many clients , it often takes only a single weak/bad client ACTIVE connection to degrade all clients on an AP.
Example:
... 5 to 20 clients connected with good strong signals , great CCQ , great connect rates
... 1 (or more clients) connected with medium to weak signals , lower or low CCQ , low/slower connect rates...
... Peak usage hours & everybody watching Netflix (trying to stream 3 meg up to 15 meg)

What is the best solution for that scenario, as I have clients signal from -55 to -74 I pick an the best average set AP data rates to suit all the connected clients, I suppose if spectrum allowed
have one AP for 50-60, another for 61-70, finally one for 71-74??

So - note ... you can't go by signal strength alone. It is possible for everybody to have great signal strengths , but ... if one remote Client has interference caused by a customer-owned in-house wireless AP , then the CCQ will be lower resulting in some wireless packet retries between the AP and Clients. Which again , starts to result in more Random-Early-Detects and more retries system wide. So - also look at your CCQs when under peak usage times when everybody is busy. CCQ might look great when everybody is idle - but it will change when the wireless network starts to get busy and/or saturated.

Just some of my thoughts ...
North Idaho Tom Jones

As regards interference, we must not forget in a unlicensed band that interference can be from any type of RF device transmitting in that band and not just 802.XX....WiFi only ?
I am somewhat bemused when I read users looking for WiFi spectrum analyzers, sure they will help for WiFi signals but if you have a serious interference issue you need the proper kit to trace and indentify?

As regards interference, we must not forget in a unlicensed band that interference can be from any type of RF device transmitting in that band and not just 802.XX....WiFi only ?
I am somewhat bemused when I read users looking for WiFi spectrum analyzers, sure they will help for WiFi signals but if you have a serious interference issue you need the proper kit to trace and indentify?

Hence we'd miss the spectral-history tool so dearly in the new 'ac' devices. Just a Wifi scan is only half the tool. I leave now at most of my AP's an old Omnitik just for the spectral scan. But we need to have such tool at the CPE too!

Speaking of connection rates and CCQ ...etc.......
North Idaho Tom Jones

Good explanatory post!
What we do now is squeezing CPE's as much as we can in a receive signal range no wider then 10dB apart and not higher then -60 / -65.
So if needed some clients get 24dbi CPE antena where others can do with a 12dBi. As long as we can bring most signals close to our goal.

Next thing is we do we look in a somewhat longer runningn P2MP network where users have been 'active' to see to what connection rates the algorithm sets the radios.
Then we know what rates we need to get at least the traffic we'd promise to the client. (If he has a 10Mb contract, we are aiming at a rate that can do at least 2,5 to 3 times that. So for 10Mb that should be at least mcs 9 or 10 (802.11 'n'). But if we see all CPE's maintain at least 11 or 12 we can even set these as long as the CCQ stays better then 80% on average.

We always set a block of at least 3 mcs rates for dual chain, and the same mcs rates but for single chain. Then we set a basic rate of 6 or 9 or 12mb so the antenna will always make a connections.
We found that it might take a bit more time to get to the higher rates when a unit has been down or rebooted but once 'alive' the rates stay more stable and thus the CCQ's better. (Each rate adaption up or down drops the link for a ms and thus during that time no data passes. It decreases de CCQ and slows the link a bit....

But to be honest, after 15 year in this business one of my most timely actions is still the testing and fine tuning of the ever changing wireless spectrum, hardware, interference, software and protocols PER P2MP network. And I have 40 that all need my attention...... You're simply never ready!

a wish list of something I started to create - and even posted in these forums about - but nothing was ever finished

If I had the free time and many non-busy days , I would like to create this:

A Linux based computer - with expect scripts and shell programs and a simple database
In the database I would have:
- IP address of an AP
- IP addresses of all clients on that AP (or a sample pool of clients on that AP)

Then have the program connect to an AP and do the following:
-1, brief btest to every client (log the btest results)
-2, change the AP and sample client wireless settings (walk 1-by-1 through all combinations of frequency, retries, distance (nv2 cell radius), optional-wireless-protocol-802.11/nstream/nv2 , and possibly other wireless settings (on the client sample pool and the AP)
-3 perform a brief btest on each wireless setting and log the results
- give the Linux shell program a start time and a stop time (could be late O-Dark-30 -or- busy times of the day).


Then start the Linux shell program , let it run for hours or days or what-ever.
When finished return everything back to the way it was when finished or the stop-time occures
After all testing is completed , produce a file or document that shows the following:
--- combined btest throughput test results per wireless setting tested
--- average btest results per test
--- combined CCQ , and signal strengths and connection rates
--- average CCQ , and signal strengths and connection rates

Then with this information , you have the information to configure an AP/Client network for best throughput.

A single AP with a dozen or more clinents might take an hour or more.
100 APs with several hundred clients might take a week (give or take more weeks).

To do this by hand in-person is nearly impossible - but for a computer it is a simple repeating-looping task that will eventually deliver usefull information.

I started on this 10 years ago and never got it properly running/finished. I no longer even have the old code. My plan at the time was to make it freely available to all Mikrotik users.

Anybody up to writing the code and donating their work ??? - I am only a Linux shell / expect programmer ( The only real program language I actually know is the 30-year-old BASIC)

North Idaho Tom Jones

I wonder why this topic is not pinned above the others anymore? Are the improvements not really improvements or is there some kind of serious problem to be corrected in this version?

EDIT: Sorry, wrong topic! I was talking about the topic with the NV2 Improvements made in version 6.42.1. Where is it actually?

I think these guys ever developed the 'radio mobile' or similar programs should do the next;

These programs give nice theoretical spectral scenery based upon standard atmospheric conditions, the geographical location and elevation of terrain combined with a database of some antena characteristics and power settings of radio's. All very theoretical, nothing more, nothing less...

Some minor defects in this programs are the existence yes or not of high buildings or other human high constructions and for instance the existence of vegetation.
(And do these programs differ between land and sea/water surfaces?)

But the biggest lack of these programs are the ability to add several towers with their radio emissions of interest (that give interference, like other operator's towers) and sectors etc. so the user can predict where which channel use or what kind of antenna would be best to give best results.
(Even when the competition is not willing to cooperate, all you need to do is scan a tower, at close range for frequencies, look what antennas they'd use (binoculairs!) and in what direction they work.)
If you could feed this info, together with all your towers, in a calculation model it should be an easy task for such program to show where what frequencies can be used/should be avoided.

I would die to have such a program. Now I don't even use Radio Mobile or similar since it can only tell me a theoretical 'reach' for a certain antena combination (master and client). Nice, but my brain already has that kind of info for about 75% of the cases.


But to come back on the topic; "Nv2-downlin-ratio - new huge bandwidth increase" .... I think there are serious problems indeed. We saw several vent these here on the forum but so far ample comments from MT's end.....

But to come back on the topic; "Nv2-downlin-ratio - new huge bandwidth increase" .... I think there are serious problems indeed. We saw several vent these here on the forum but so far ample comments from MT's end.....

I apologize you guys. I was refering to the topic with the new NV2 Improvements made in version 6.42.x I posted my message above in the wrong topic... The topic I am talking about had been fixed for a while and then they took it out from the most important topics... Why?

Found it:

viewtopic.php?f=21&t=132181&p=663086&hi ... nt#p663086

they've transfered it to the announcement forum...

.

- In general , I've found the average sweet-spot for signal strength to be in the range of -45 to -60 (-50 normally works best on average)

- On an AP with many clients , it often takes only a single weak/bad client ACTIVE connection to degrade all clients on an AP.
Example:
... 5 to 20 clients connected with good strong signals , great CCQ , great connect rates
... 1 (or more clients) connected with medium to weak signals , lower or low CCQ , low/slower connect rates...
... Peak usage hours & everybody watching Netflix (trying to stream 3 meg up to 15 meg)

The weak - low CCQ - low rate-connected clients also trying to watch Netfilx may experience wireless retries. Also - because these weak/poor client connections are connected at a slower wireless connect-rate , they require more/longer time periods to receive and transmit (client to AP data). The larger time periods for these weak clients takes away AP air time that the AP would normally be using for everybody else also watching Netflix. Thus , all active clients begin to suffer - and possibly even more re-tries and more Random-Early-Detects are created for everybody , which again results in a cascading downward slope to even poorer AP communications to/from wireless Clients.

So - note ... you can't go by signal strength alone. It is possible for everybody to have great signal strengths , but ... if one remote Client has interference caused by a customer-owned in-house wireless AP , then the CCQ will be lower resulting in some wireless packet retries between the AP and Clients. Which again , starts to result in more Random-Early-Detects and more retries system wide. So - also look at your CCQs when under peak usage times when everybody is busy. CCQ might look great when everybody is idle - but it will change when the wireless network starts to get busy and/or saturated.

Just some of my thoughts ...
North Idaho Tom Jones

Yet again I can confirm all this. Since a year we really started to realize how important it is everybody has good signal and preferably good CCQ.
Now standard practise is we basically don't accept clients with less then -60dB more but actually look for -50's.
It depends a bit on the AP too. We have one AP with 8 clients but one has only -70dBm even with a 27,5dBi antena. Not ideal but its manageable.

Another AP has 28 clients on we still have one that has a poor connection. Signal -55 but poor CCQ. Although scan doesn't show any channels near, there must be something that interferes. This client definitely needs more investigation to solve the issue. Especial since to up to half a year ago it all worked fine for him.....

Getting better CCQ's is also achieved by setting some fixed connection rates only, make sure all units can get the ones you set and have at least one lower and we set two with the same rate for the sigle stream. Some CPE's have better stable signal on a signle stream than with both.
And by setting the mcs rates fixed the CCQ's are much higher. But I am still not 100% convinced is this indeed a show of better links, or is it just optic illusion since the rates jump up and down less and thus less resends only because of this...

How do you set fixed connection rates in nv2, wireless only-n?
I would like to tweak this to improve signal on some clients.


Sent from my SM-G930W8 using Tapatalk