Community discussions

MikroTik App
 
Muzaki
newbie
Topic Author
Posts: 43
Joined: Wed May 13, 2009 3:12 pm
Contact:

Nv2 limitations??

Thu Nov 16, 2017 10:21 pm

Im having trouble using NV2 on some (most) of my P2MTP. I use RB912 with RF Element horn at my towers, and RB911 with RF Element Stationbox XL as CPE. (Some are RB711 and Stationbox Micro) 20MHz and both HT enabled

There is about 20+ clients.

My problem is that with NV2 it seems to peak at 20-23 Mbps total, but with 802.11 it has no problems with 50-60Mbps ++ total.

I have also seen this issue with P2P links (QRT) it performs much better with 802.11 than with NV2.

This cant be normal? Any advice?
 
mistry7
Forum Guru
Forum Guru
Posts: 1398
Joined: Tue Oct 13, 2009 11:57 am
Location: Germany

Re: Nv2 limitations??

Fri Nov 17, 2017 1:31 am

It is normal, Mikrotik is calling this a feature not a failure
 
JDSurfnet
just joined
Posts: 11
Joined: Fri Mar 09, 2012 2:49 am

Re: Nv2 limitations??

Sat Nov 18, 2017 1:41 am

I would check to make sure all the subscribers have good connections. I've recently noticed with NV2 that one poor connection causes the whole AP to suffer dramatically.
 
server8
Member
Member
Posts: 426
Joined: Fri Apr 22, 2011 1:27 pm

Re: Nv2 limitations??

Sat Nov 18, 2017 8:38 am

Yes going slower is safer :-(
 
hengst
Frequent Visitor
Frequent Visitor
Posts: 86
Joined: Sun Jan 03, 2010 3:04 pm

Re: Nv2 limitations??

Sat Nov 25, 2017 12:08 pm

the key in AP (NV2) performance is always that

- the lowest signal client is in control of the total throughput of the AP

the way to avoid this is, is to hard set the queue on the client to lets say 80% of the possible wireless data rate.
 
Lakis
Forum Veteran
Forum Veteran
Posts: 701
Joined: Wed Sep 23, 2009 7:52 pm

Re: Nv2 limitations??

Sat Nov 25, 2017 1:27 pm

the key in AP (NV2) performance is always that

- the lowest signal client is in control of the total throughput of the AP

the way to avoid this is, is to hard set the queue on the client to lets say 80% of the possible wireless data rate.
Than why in P2P scenario 802.11 outperform nv2?
 
hengst
Frequent Visitor
Frequent Visitor
Posts: 86
Joined: Sun Jan 03, 2010 3:04 pm

Re: Nv2 limitations??

Sat Nov 25, 2017 1:46 pm

Wireles is always about the Signal, CCQ, SNR etc.

in basic theory , 50% of the connected data rate is your real throughput.

NV2 is helpfull for avoiding hidden node effect on an PtMP seen in 802.11, by using a form of TDMA ( a serving time window for every client )

For PtP it can be different what works best for you. it depends on distance, nearby radios, etc.
 
JDSurfnet
just joined
Posts: 11
Joined: Fri Mar 09, 2012 2:49 am

Re: Nv2 limitations??

Sun Nov 26, 2017 12:39 am

the key in AP (NV2) performance is always that

- the lowest signal client is in control of the total throughput of the AP

the way to avoid this is, is to hard set the queue on the client to lets say 80% of the possible wireless data rate.
This is why NV2 needs airtime fairness or at least a function to enable priority over each connection in PTMP.
 
savage
Forum Guru
Forum Guru
Posts: 1220
Joined: Mon Oct 18, 2004 12:07 am
Location: Cape Town, South Africa
Contact:

Re: Nv2 limitations??

Sun Nov 26, 2017 7:21 am

We're sitting with the same thing...

What makes this interesting, is that CCQ drops when the link is idle and there's no traffic. Yet, when there's traffic all CCQs are well over the 80% and we still only get about 30Mbps / 35Mbps.

Given that CCQ drops when links are idle, just how are you supposed to know what a "bad link" is?

In which version did this start (if anyone knows). Would love to downgrade to a version where this isn't an issue.
Regards,
Chris
 
hengst
Frequent Visitor
Frequent Visitor
Posts: 86
Joined: Sun Jan 03, 2010 3:04 pm

Re: Nv2 limitations??

Sun Nov 26, 2017 3:54 pm

What makes this interesting, is that CCQ drops when the link is idle and there's no traffic. Yet, when there's traffic all CCQs are well over the 80% and we still only get about 30Mbps / 35Mbps.
CCQ can only be measured with active traffic.
This is why NV2 needs airtime fairness or at least a function to enable priority over each connection in PTMP.
NV2 is all about airtime, all clients are giving a "time slot" , only wifi radio basics are still the same.
 
n21roadie
Forum Guru
Forum Guru
Posts: 1896
Joined: Fri Aug 07, 2009 10:36 pm
Location: Limerick,Ireland

Re: Nv2 limitations??

Sun Nov 26, 2017 8:33 pm

Wireles is always about the Signal, CCQ, SNR etc.

in basic theory , 50% of the connected data rate is your real throughput.

NV2 is helpfull for avoiding hidden node effect on an PtMP seen in 802.11, by using a form of TDMA ( a serving time window for every client )

For PtP it can be different what works best for you. it depends on distance, nearby radios, etc.
Does that theory hold for both half and full duplex?
 
savage
Forum Guru
Forum Guru
Posts: 1220
Joined: Mon Oct 18, 2004 12:07 am
Location: Cape Town, South Africa
Contact:

Re: Nv2 limitations??

Sun Nov 26, 2017 8:38 pm

What makes this interesting, is that CCQ drops when the link is idle and there's no traffic. Yet, when there's traffic all CCQs are well over the 80% and we still only get about 30Mbps / 35Mbps.
CCQ can only be measured with active traffic.
Well... DUH, of course.

And when it's NOT active, you sit with links with 3% or 5% CCQ, which degrades the performance of the links that IS active...
Regards,
Chris
 
hengst
Frequent Visitor
Frequent Visitor
Posts: 86
Joined: Sun Jan 03, 2010 3:04 pm

Re: Nv2 limitations??

Sun Nov 26, 2017 9:01 pm

. And when it's NOT active, you sit with links with 3% or 5% CCQ, which degrades the performance of the links that IS active...
How ? , only active low data rates that are degrading throughput of AP. Thats basic wifi behaviour. Idle connections almost none.
 
savage
Forum Guru
Forum Guru
Posts: 1220
Joined: Mon Oct 18, 2004 12:07 am
Location: Cape Town, South Africa
Contact:

Re: Nv2 limitations??

Sun Nov 26, 2017 9:07 pm

. And when it's NOT active, you sit with links with 3% or 5% CCQ, which degrades the performance of the links that IS active...
How ? , only active low data rates that are degrading throughput of AP. Thats basic wifi behaviour. Idle connections almost none.
So then why we only seeing 20-30Mbps throughput on the APs? :D Back to square one...
Regards,
Chris
 
n21roadie
Forum Guru
Forum Guru
Posts: 1896
Joined: Fri Aug 07, 2009 10:36 pm
Location: Limerick,Ireland

Re: Nv2 limitations??

Sun Nov 26, 2017 9:25 pm

I would check to make sure all the subscribers have good connections. I've recently noticed with NV2 that one poor connection causes the whole AP to suffer dramatically.
Strange I have never seen one or more low signal,low ccq (or both) clients registered to a AP causing this, have you any examples to share to prove this point?
I suspect that for TDMA performance to be effected it would take the overall (average) signal + CCQ + SNR for the group of clients (?) to be low.
 
hengst
Frequent Visitor
Frequent Visitor
Posts: 86
Joined: Sun Jan 03, 2010 3:04 pm

Re: Nv2 limitations??

Sun Nov 26, 2017 10:51 pm

So then why we only seeing 20-30Mbps throughput on the APs? :D Back to square one...

running a loop here...

one more time ;

a client with Rx-rate connection rate of 52Mbps will have throughput of more or less 30Mbps when doing bandwidth test.
at that moment the total bandwidth available to all clients will be 30Mbps.

next client ( Rx-rate 135Mbps ) doing bandwidth test will get more or less 15Mbps )

this because Ap has sfq interface queue active. which will divide available resources.

client with lowest "active" Rx-rate is total available bandwidth on AP
 
n21roadie
Forum Guru
Forum Guru
Posts: 1896
Joined: Fri Aug 07, 2009 10:36 pm
Location: Limerick,Ireland

Re: Nv2 limitations??

Mon Nov 27, 2017 2:44 am

So then why we only seeing 20-30Mbps throughput on the APs? :D Back to square one...

running a loop here...

one more time ;

a client with Rx-rate connection rate of 52Mbps will have throughput of more or less 30Mbps when doing bandwidth test.
at that moment the total bandwidth available to all clients will be 30Mbps.

next client ( Rx-rate 135Mbps ) doing bandwidth test will get more or less 15Mbps )

this because Ap has sfq interface queue active. which will divide available resources.

client with lowest "active" Rx-rate is total available bandwidth on AP
Are you sure about sfq, default now unless changed is "only-hardware-queue"
https://wiki.mikrotik.com/wiki/Manual:Queue#SFQ
"Note: Starting from v5.8 there is new kind none and new default queue only-hardware-queue. All RouterBOARDS will have this new queue type set as default interface queue"
"only-hardware-queue leaves interface with only hw transmit descriptor ring buffer which acts as a queue in itself. Usually at least 100 packets can be queued for transmit in transmit descriptor ring buffer. Transmit descriptor ring buffer size and the amount of packets that can be queued in it varies for different types of ethernet MACs.

Having no software queue is especially beneficial on SMP systems because it removes the requirement to synchronize access to it from different cpus/cores which is expensive."
 
hengst
Frequent Visitor
Frequent Visitor
Posts: 86
Joined: Sun Jan 03, 2010 3:04 pm

Re: Nv2 limitations??

Mon Nov 27, 2017 7:54 am

In my testlab equipment it was all default on sfq , playing with diff types of queue did not had better results in my case.

Sfq looked to be needed to share the Ap resources best. But if someone have better setti gs there i love to hear them.
 
savage
Forum Guru
Forum Guru
Posts: 1220
Joined: Mon Oct 18, 2004 12:07 am
Location: Cape Town, South Africa
Contact:

Re: Nv2 limitations??

Mon Nov 27, 2017 9:04 am

So then why we only seeing 20-30Mbps throughput on the APs? :D Back to square one...

running a loop here...

one more time ;

a client with Rx-rate connection rate of 52Mbps will have throughput of more or less 30Mbps when doing bandwidth test.
at that moment the total bandwidth available to all clients will be 30Mbps.

next client ( Rx-rate 135Mbps ) doing bandwidth test will get more or less 15Mbps )

this because Ap has sfq interface queue active. which will divide available resources.

client with lowest "active" Rx-rate is total available bandwidth on AP
And a client whom is IDLE will have their ACTIVE rates, drop to as low as 6Mbps, with a CCQ of like 4%, or 6%... :lol: So even IF I have clients at 6Mbps, I still only get 30mbps throughput on the AP. WAY HIGHER than "client with lowest "active" Rx-rate is total available bandwidth on AP"

Your arguments are flawed, at best.
Regards,
Chris
 
hengst
Frequent Visitor
Frequent Visitor
Posts: 86
Joined: Sun Jan 03, 2010 3:04 pm

Re: Nv2 limitations??

Mon Nov 27, 2017 9:22 am

Whit active data rates i mean a client that is downloading data. An idle client is not active, and will drop rates to 6.5Mbps.

But do the test and you will see for your self.
 
n21roadie
Forum Guru
Forum Guru
Posts: 1896
Joined: Fri Aug 07, 2009 10:36 pm
Location: Limerick,Ireland

Re: Nv2 limitations??

Mon Nov 27, 2017 11:16 am

In my testlab equipment it was all default on sfq , playing with diff types of queue did not had better results in my case.

Sfq looked to be needed to share the Ap resources best. But if someone have better setti gs there i love to hear them.
In our network using a central PPPoE concentrator we approached queues with an overall network performance perspective, currently in use a the custom queue for pppoe server,
on the AP's interfaces "only-hardware-queue", on the CPE'e wireless and Ethernet defaults.
 
User avatar
Cha0s
Forum Veteran
Forum Veteran
Posts: 978
Joined: Tue Oct 11, 2005 4:53 pm

Re: Nv2 limitations??

Mon Nov 27, 2017 12:20 pm

In which version did this start (if anyone knows). Would love to downgrade to a version where this isn't an issue.
This has always been that way. At least since v2.9.x.

There's a perfectly good explanation in the manual why it works that way .
https://wiki.mikrotik.com/wiki/Manual:W ... ermined.3F
What is CCQ and how are the values determined?

Client Connection Quality (CCQ) is a value in percent that shows how effective the bandwidth is used regarding the theoretically maximum available bandwidth. CCQ is weighted average of values Tmin/Treal, that get calculated for every transmitted frame, where Tmin is time it would take to transmit given frame at highest rate with no retries and Treal is time it took to transmit frame in real life (taking into account necessary retries it took to transmit frame and transmit rate).
So since CCQ is calculated based on what is transmited over the air, it makes perfect sense that it only shows the real numbers when there is traffic.
What I've done in the past to always get more realistic CCQ numbers on idle links is to run a continuous ping with large packet size and small interval causing enough traffic (~1mbps) for CCQ to show something meaningful but not enough to 'steal' from real traffic.
 
JDSurfnet
just joined
Posts: 11
Joined: Fri Mar 09, 2012 2:49 am

Re: Nv2 limitations??

Wed Nov 29, 2017 6:42 am

I would check to make sure all the subscribers have good connections. I've recently noticed with NV2 that one poor connection causes the whole AP to suffer dramatically.
Strange I have never seen one or more low signal,low ccq (or both) clients registered to a AP causing this, have you any examples to share to prove this point?
I suspect that for TDMA performance to be effected it would take the overall (average) signal + CCQ + SNR for the group of clients (?) to be low.
We have fixed both clients by moving them to another access point, so I don't have an active example to share. I will say this, it happened on two separate access point and both subscribers had fresnel issues(trees) and at a distance around 15km. Signal strength on both were between -74 and -78. The overall throughput difference when each subscriber was removed rose by around 40-50Mbps TCP on both access points. It was extremely hard to spot.

Does anyone know how NV2 allocates airtime? Does each timeslot have airtime based on bandwidth(modulation) or is airtime allocated equally?
 
ste
Forum Guru
Forum Guru
Posts: 1831
Joined: Sun Feb 13, 2005 11:21 pm

Re: Nv2 limitations??

Wed Nov 29, 2017 7:23 am

JDSurfnet wrote:
[quote=n21roadie post_id=629795 time=1511724355 user_id=34967]
JDSurfnet wrote:
I would check to make sure all the subscribers have good connections. I've recently noticed with NV2 that one poor connection causes the whole AP to suffer dramatically.

Strange I have never seen one or more low signal,low ccq (or both) clients registered to a AP causing this, have you any examples to share to prove this point?
I suspect that for TDMA performance to be effected it would take the overall (average) signal + CCQ + SNR for the group of clients (?) to be low.


We have fixed both clients by moving them to another access point, so I don't have an active example to share. I will say this, it happened on two separate access point and both subscribers had fresnel issues(trees) and at a distance around 15km. Signal strength on both were between -74 and -78. The overall throughput difference when each subscriber was removed rose by around 40-50Mbps TCP on both access points. It was extremely hard to spot.

Does anyone know how NV2 allocates airtime? Does each timeslot have airtime based on bandwidth(modulation) or is airtime allocated equally?[/quote]

We have seen lower number of cpes help regardless if they do anything. So keep numbers low and signals good. My guess is the AP needs more cpu to handle the protocol.

Who is online

Users browsing this forum: No registered users and 46 guests