NV2 set cpe queue to 80% of wireless data rate

the key in AP (NV2) performance is always that

  • the lowest signal client/data rate is in control of the total throughput.

so when a cpe maxes out on the connected datarate, it takes down the overall 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 and so protect the AP from dropping throughput.

what is the way to go here, write an script for cpe, or implement this in NV2 protocol on the station/cpe side.

ok i got a start of a script to play with, but am not a coder , so this needs some help from a script guru please.

:global check [/interface wireless registration-table get 0 rx-rate ]

:log info [:pick $check 0 3 ]

/queue simple set 0 max-limit=([:pick $check 0 3 ]-0.XX)

the goal is that the simple queue has to be set on the cpe wlan,
the queue limit is then adjusted every few seconds by script.
up and download of the queue should be lets say 80% of the connection data rates.

Very interesting topic.

I would like to see feedback and examples on this.

Sent from my Pixel 2 using Tapatalk

First can I ask where did you get this info ?
Also is not more complicated than just lowest signal/ data rate , how about SNR + noise floor + CCQ for calculation.

Https://documentation.meraki.com/MR/WiFi_Basics_and_Best_Practices/Wireless_Throughput_Calculations_and_Limitations

First can we really compare Cisco Meraki to Mikrotik NV2!



I have to disagree with this statement how can this occur on a TDMA wireless protocol (NV2),

For example there is a CPE on our network that is really on borderline signal drop out -82 to -89dbm, SNR =40dB CCQ=20/57%
It doesn’t have any major effect on the overall performance of that AP otherwise we would loads of calls from unhappy customers?
This customer has a growing forest in between him and the AP and as expected complains but only in the evening and it’s not network saturation but our assumption is that during the day the AP has extra timeslots available so he can get the required bandwidth to stream, but in the evening there is no extra timeslots available and suffers buffering,
On Reading
https://wiki.mikrotik.com/wiki/Manual:Nv2
“.. Nv2 is based on TDMA (Time Division Multiple Access) ..”
“…Nv2 implements dynamic rate selection on per-client basis and ARQ for data transmissions …”
https://wiki.mikrotik.com/wiki/Manual:Nv2#QoS_in_Nv2_network
• Reduced polling overhead - instead of polling each client, Nv2 AP broadcasts uplink schedule that assigns time to multiple clients, this can be considered “group polling” - no time is wasted for polling each client individually, leaving more time for actual data transmission. This improves throughput, especially in PtMP configurations.

Q. Does “multiple clients” mean all registered clients or say a group of 5 clients?

My opinion is that NV2 would benefit greatly if it was full duplex (looks like Cisco Meraki are trying full duplex on dual band) and NV2 management protocol speed was dynamic rather than currently fixed at 6Mbps rate.

First can we really compare Cisco Meraki to Mikrotik NV2!

its not about Meraki, and not to compare Meraki to Mikrotik , it is about Wifi basics.


Take this example.

1 Ap NV2 ( N protocol )

1 active client connected with Rx rate 52Mbps , will give you more or less 30Mbps with doing bandwidth test to AP ( so maxing out the connection )

so now the AP has more or less 30Mbps available to all clients

second client that is connected with Rx rate 139Mbps will only get the half of that 30Mbps because lowest connection rate is master when doing also banwidth test ( sfq interface queue on AP ) ,
so about 15Mbps to both clients.

now stop bandwidth test on first client and the second client will get his full throughput. ( more or less 100Mbps )

now when you set a local queue on client 1, to keep the wlan on 10Mbps so it can not max out Rx rate of 52Mbps

/queue simple
add max-limit=10M/10M name=queue1 target=wlan1

and do the same test, you will see that client 1 will get his 10Mbps and other client more or less 90Mbps

you can test your self with simple setup.

So you can have a low signal/Rx client without problem, it only gives problems to others when the are maxing out there Rx rate.

To get it “on topic”

i would love to see a script that can set a Simple queue based on the Rx-rate

how can help with that, as iam not a script guru but do understand the basics.

it is easy
after configure simple queue as you need
use this script

{ 
:local RX [/interface wireless registration-table get 0 rx-rate ]; 
:local QS [:pick $RX 0 [:find $RX "M"]]; 
/queue simple set 0 max-limit=((($QS / 10)*8)."M")
}

Your the best !, learning a lot here.

:wink:

@hengst I am sorry but cannot agree with your statement " - the lowest signal client/data rate is in control of the total throughput." is just not accurate, It maybe accurate for 802.11 but certainly not for NV2 TDMA because I have had faulty CPE’s using a data rate of 1Mbps and only the customer with that very low data rate was complaining while none of the rest of other clients registered to that AP complained ?

Can someone give the throughput calculation for 1Mbps data rates and this shared with 30 Clients ?

Please check ;
http://forum.mikrotik.com/t/wifi-connection-tx-rx-rates/114558/1

http://forum.mikrotik.com/t/detect-1mbps-data-rate/112579/1

Please check ;
viewtopic.php?f=7&t=128415

viewtopic.php?f=7&t=126028

These might have suffered from other problems, i dont think you should compare them to this topic/issue .
( also correct data rates are only showing when there is actual data using the connection )

My topic is based on the question “Why my Ap has low total throughput”

the statement of " - the lowest signal client/data rate is in control of the total throughput. " is based on a simple test.

put up an AP with NV2 as TDMA protocol.

connect 1 client with higher data rate , and 1 client with low data rates.


now do bandwidth test on both and you will see that the lowest data rate is in control of total throughput of the AP.

the total is then shared amongst the connected 2 clients because of the sfq interface queue.

when set an queue half the data rate on the client with lowest data rate you will see a big gain in total throughput on the AP,

thats why i want to try this 80% script.

make your experiment and share result in the forum
Best Regards

I also will await your detailed result of the experiment and would certainly welcome any “tweak” that could improve NV2 throughput ?

So i had some playing with the script,

besides the script is very basic at this point, it does work to set the queue for some data rates.

( as seen in the script it will set the queue if data rate is 54Mbps , but not if it is 6.5Mbps )

and i was able to play with it.

long story short :

  • Setting queue on client wlan to half the connection data-rate will help total throughput of the AP.

( or if you like “it will prevent the low data-rate cpe to degrade the overall AP throughput” )

the script needs work for better automation the process.


even better would be if a protection like that was build into the NV2 protocol



Probably the biggest issues in AP throughput are the basic wifi limitations,
active connected data-rates seems to affect total AP throughput big time.

RouterOS doesn’t support floating numbers, so you have to eliminate point

try this one

{ 
:local RX [/interface wireless registration-table get 0 rx-rate ];
:if ([:find $RX "."]>=1 ) do={:set $RX ( [:pick $RX 0 [:find $RX "."]]+1 )} else={:set $RX [:pick $RX 0 [:find $RX "M"]]}; 
/queue simple set 0 max-limit=((($RX * 8) / 10)."M"); 
}

for logging

:log warning ("queue set to " . ((($RX * 8) / 10)."M"));

Thnx ADahi , think you make magic happen here.

after some testing i found using ccq is a better approach

{
:local CX [/interface wireless registration-table get 0 rx-ccq ];
/queue simple set 0 max-limit=((($CX * 5) / 10)."M");
}

one can play with the factor “5” , ideal would be that its dynamic to the ccq.

so if ccq is 20%, , the divide number would be 1 for example, and if ccq is 100% divide would be 9.


i see big improvements in test setup.

such a simple solution that makes big difference by preventing a client with low ccq degrading AP overall throughput.

now the script need to be fine tuned and run with scheduler or should it be looped script and only change queue if needed ?

also it needs to set up and down limits according to ccq up/down rates.

but it is big improvement for sure to AP throughput.

@Mikrotik programmers. is it not possible to integrate this approach in NV2 ?

nice lets try remove all queue and try set only hardware queue

/queue interface
set wlan1 queue=only-hardware-queue

let me know the results.
many thanks