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?

It is normal, Mikrotik is calling this a feature not a failure

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.

Yes going slower is safer

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.

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?

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.

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.

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.

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.

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?

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...

. 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.

. 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? Back to square one...

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.

So then why we only seeing 20-30Mbps throughput on the APs? 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

So then why we only seeing 20-30Mbps throughput on the APs? 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."

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.

So then why we only seeing 20-30Mbps throughput on the APs? 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%... 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.

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.

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.

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.

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?

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.