Significant improvement for wireless Nv2 PtMP

Tue Mar 20, 2018 1:30 pm

We have made a potentially significant improvement for wireless Nv2 PtMP configurations in the latest 6.42rc46 version release.
Upgrade of the AP is required to the new rc version, clients can still use the old version.

Edit 18.04.17,
now changes are merged to MikroTik RouterOS 6.42 version. We strongly suggest to use the latest current RouterOS version.

HaQs · Tue Mar 20, 2018 1:40 pm

+100
Thanks.

Tue Mar 20, 2018 3:29 pm

We have made a potentially significant improvement for wireless Nv2 PtMP configurations in the latest 6.42rc46 version release.
Upgrade of the AP is required to the new rc version, clients can still use the old version.

Those of you who are willing to test rc versions on your test network, please upgrade to the latest version, test the performance and report to support@mikrotik.com with the results. Your effort and feedback will be highly appreciated.

Please note that rc versions are released strictly for testing purposes and should not be used on crucial network devices.

This is a message we are waiting for years now. Many thanks !!! Is this specific to hardware or is this a general improvement of the protocol handling at the AP ?

Tue Mar 20, 2018 3:30 pm

In the pictures below you can see the differences without and with the Nv2 improvements. TX and RX tests are done separately. TX is total/combined download speed from the AP to the clients.

before.png

after.png

sakirozkan · Tue Mar 20, 2018 3:48 pm

+ Thanks

soulflyhigh · Tue Mar 20, 2018 3:49 pm

Hello Uldis,
this is the test with 802.11ac or 802.11n radios?
Could you describe in more details signal levels and hardware used?

Regards,
M.

server8 · Tue Mar 20, 2018 3:56 pm

Tested now +20% of bandwidth improvment in tx from AP

I hope with newer version we can get more

Thank you a lot mikrotik

Tue Mar 20, 2018 4:46 pm

In the setup we had a R11e-5HnD as AP and Clients was SXTsq Lite5

honzam · Tue Mar 20, 2018 5:22 pm

In the setup we had a R11e-5HnD as AP and Clients was SXTsq Lite5

In BAND - N? Channel width? 40Mhz? TDMA = 2ms or AUTO? More info about config please...

server8 · Tue Mar 20, 2018 5:28 pm

On the first AP updated after one hour we got

15:47:29 system,error,critical router was rebooted without proper shutdown
15:47:29 system,error,critical kernel failure in previous boot

router has rebooted

Tue Mar 20, 2018 9:53 pm

server8 - Please generate supout file on this router and send it to support@mikrotik.com for investigation.

server8 · Tue Mar 20, 2018 9:57 pm

done [Ticket#2018032022005404] RE: router reboot V6.42r [...]

nkourtzis · Wed Mar 21, 2018 1:21 am

This is a welcome improvement but: NV2 has been neglected for very long and needs A LOT of care from the MkTik devs. This version shows that it can be done, it can be improved. Interference mitigation (NV2 is VERY sensitive to noise even with one client) and better compatibility with 802.11ac should be the next goals.

server8 · Wed Mar 21, 2018 8:50 am

I'd like interesting to know if we can espect more improvements in the future or this is the best that NV2 can do

Wed Mar 21, 2018 9:04 am

In the setup we had a R11e-5HnD as AP and Clients was SXTsq Lite5
In BAND - N? Channel width? 40Mhz? TDMA = 2ms or AUTO? More info about config please...

band=5ghz-a/n channel-width=20/40mhz-Ce un TDMA - 2m

soulflyhigh · Wed Mar 21, 2018 9:35 am

In the setup we had a R11e-5HnD as AP and Clients was SXTsq Lite5
In BAND - N? Channel width? 40Mhz? TDMA = 2ms or AUTO? More info about config please...
band=5ghz-a/n channel-width=20/40mhz-Ce un TDMA - 2m

What was the distance between the AP and SXTs?

hapi · Wed Mar 21, 2018 9:58 am

In what universe can you actually reach 200Mbit in ptmp? We have a problem getting 200Mbit even in ptp. (N, 20/40-Ce)

200Mbit in TCP.

Of course, with the growing number of clients, the chart is real.

mistry7 · Wed Mar 21, 2018 10:00 am

In what universe can you actually reach 200Mbit in ptmp? We have a problem getting 200Mbit even in ptp. (N, 20/40-Ce)

200Mbit in TCP.

Of course, with the growing number of clients, the chart is real.

I believe it is udp

Wed Mar 21, 2018 10:02 am

In what universe can you actually reach 200Mbit in ptmp? We have a problem getting 200Mbit even in ptp. (N, 20/40-Ce)

200Mbit in TCP.

Of course, with the growing number of clients, the chart is real.

We had a 6km PtP link doing 200mbit TCP with 802.11n using Jirous 24dBi dishes. Doing it on PTMP though, that would be impressive!

honzam · Wed Mar 21, 2018 10:21 am

band=5ghz-a/n channel-width=20/40mhz-Ce un TDMA - 2ms

Hello. Thanks for info and very thanks for improvement!
Can you plese make this test in 20Mhz channel?
first test - only N, 20Mhz
second test - only AC, 20Mhz
Thanks

xrayd · Wed Mar 21, 2018 11:52 am

@uldis
which mode, Dynamic or Fixed Downlink?
And Downlink Ratio is 70%?

fiberwave · Wed Mar 21, 2018 1:08 pm

We tested the new release, and it works great.
n/ac, 20MHz, dynamic dl. ratio, auto TDMA period size.

xrayd · Wed Mar 21, 2018 1:55 pm

@fiberwave
Downlink Ratio 70%?

fiberwave · Wed Mar 21, 2018 1:57 pm

@fiberwave
Downlink Ratio 70%?

80%, but it depends that what you want to achieve.
Where we have 30 clients on a sector, now we measure 80-90Mbps TCP per client.

taduikis · Wed Mar 21, 2018 2:18 pm

Can you post more details about your setup? I’ve tried similar setup and had lower total aggregate throughput per sector than with previous ROS releases. Total throughput per single client wasn’t bad before.

We tested the new release, and it works great.
n/ac, 20MHz, dynamic dl. ratio, auto TDMA period size.

fiberwave · Wed Mar 21, 2018 2:23 pm

Can you post more details about your setup? I’ve tried similar setup and had lower total aggregate throughput per sector than with previous ROS releases.

We tested the new release, and it works great.
n/ac, 20MHz, dynamic dl. ratio, auto TDMA period size.

We have a lot of sites in crowded and in silent areas with different specifications.
There's not a given formula for all the different scenarios.

Whatever, the new rc sw increased the aggregated throughput per client where we had problems.

"Total throughput per single client wasn’t bad before."

- which works, do not touch it.

taduikis · Wed Mar 21, 2018 2:29 pm

I understand that, same here. I tested on AP with 29 clients, 20MHz, NV2, tdma period auto, N only. Signals and CCQ were great. While doing simultaneous bandwidth-tests on ~10 clients, total throughput with rc46 was 10% lower than with previous relases. The single client performance wasn't really an issue before for me.

Redmor · Wed Mar 21, 2018 5:09 pm

In the setup we had a R11e-5HnD as AP and Clients was SXTsq Lite5
In BAND - N? Channel width? 40Mhz? TDMA = 2ms or AUTO? More info about config please...
band=5ghz-a/n channel-width=20/40mhz-Ce un TDMA - 2m

Please send us a backup file or an export of that AP, it will be my Bible.

human1982 · Wed Mar 21, 2018 6:31 pm

Testing, working good at a/n Ce with configured mcs up to 5 and 13 (75 nad 150mbit), guard interval long, period size 2ms, cell 10km, dynamic downlink ratio 50% Any chance for period size 1,5 or 2,5ms?

regards
Mateusz

human1982 · Thu Mar 22, 2018 4:59 am

Hello! When sq or other 711 get speed full test others get ping 200ms. If fix ratio 75/25 the same. Shoul it work then fine?
4 core=500mbit 600mhz=200mbit

human1982 · Thu Mar 22, 2018 5:30 am

Next mistake, sq noise -106, 711 -117, wtf mates.

networkfudge · Thu Mar 22, 2018 7:12 am

Next mistake, sq noise -106, 711 -117, wtf mates.

Two different stations can absolutely have different noise floors, since they are in different physical locations.

mistry7 · Thu Mar 22, 2018 8:22 am

Next mistake, sq noise -106, 711 -117, wtf mates.
Two different stations can absolutely have different noise floors, since they are in different physical locations.

same point, but different chipsets

server8 · Thu Mar 22, 2018 12:23 pm

First 2 days test on 2 AP

20 Mhz
fixed downlink 67
tdma period size auto
client 33
all client signal goog below -50
all modulation good

real world test in the peak time we have the same performance of 6.40.5 no download improvments but we have issue with the upload tha is aorund 256kb/s often less

human1982 · Thu Mar 22, 2018 1:12 pm

Next mistake, sq noise -106, 711 -117, wtf mates.
Two different stations can absolutely have different noise floors, since they are in different physical locations.

Same test location. Something is wrong with noise floor with 711 old stuff. Rx i crazy, doing manualy noise floor on -100 then problem is gone.

human1982 · Thu Mar 22, 2018 1:17 pm

First 2 days test on 2 AP

20 Mhz
fixed downlink 67
tdma period size auto
client 33
all client signal goog below -50
all modulation good

real world test in the peak time we have the same performance of 6.40.5 no download improvments but we have issue with the upload tha is aorund 256kb/s often less

Same here. Fixed downlink doesn`t work as it should. 1. It should clean ping peaks. 2. It should take every station separately so other station would live by tdma i think so.

taduikis · Thu Mar 22, 2018 1:24 pm

I also didn't notice any significant increase or improvement. The performance even dropped a little. I'd like to know some more info of exactly what this NV2 improvement do and what problems under what circumstances it should solve.

karina · Thu Mar 22, 2018 2:14 pm

Very promising results, with an AP of 30 clients, MAX overall throughput has gone up from around 30megs to 45+ megs

basebox5 - N only - 20mhz - 4ms NV2 timing - dynanic downlink

Thu Mar 22, 2018 3:51 pm

done [Ticket#2018032022005404] RE: router reboot V6.42r [...]

This kernel crash is fixed in v6.42rc49.

zorrua · Thu Mar 22, 2018 4:21 pm

Hello,

Would this fix work for PtP installations?

Kind regards.

human1982 · Thu Mar 22, 2018 4:46 pm

Hello,

Would this fix work for PtP installations?

Kind regards.

p2p nstreme fixed

human1982 · Thu Mar 22, 2018 4:47 pm

Hello,

Would this fix work for PtP installations?

Kind regards.
p2p nstreme fixed

N

human1982 · Thu Mar 22, 2018 5:54 pm

We will be migrating wrom 711 to 433 arm but there is no devices! Wtf! May be some?

human1982 · Thu Mar 22, 2018 6:05 pm

We will be migrating from 711 to arm but there is no devices! Wtf! May be some?

marcin21 · Thu Mar 22, 2018 6:28 pm

Does anyone see any improvements in real life?

lomayani · Thu Mar 22, 2018 6:52 pm

Does anyone see any improvements in real life?

Ooh yes. We used to get not more than 15mbps per client with sectors with more than 30 clients when all clients are active. Because of drop of performance when sector has more than 30 clients we were discussing migrating to another vendor but this version changed our mind already. Now with clients with good signal we can see up 85mbps under 20MHz channel and period size of 3ms. I see improvement on latency also. In short this changed our network. Am running this in production network of thousands of mikrotik radios, I failed to wait stable version because of performance am seeing now.

human1982 · Thu Mar 22, 2018 7:15 pm

Does anyone see any improvements in real life?
Ooh yes. We used to get not more than 15mbps per client with sectors with more than 30 clients when all clients are active. Because of drop of performance when sector has more than 30 clients we were discussing migrating to another vendor but this version changed our mind already. Now with clients with good signal we can see up 85mbps under 20MHz channel and period size of 3ms. I see improvement on latency also. In short this changed our network. Am running this in production network of thousands of mikrotik radios, I failed to wait stable version because of performance am seeing now.

And he kised the princess.

2jarek · Thu Mar 22, 2018 8:56 pm

@20 Mhz 802.11N
TCP/IP Speed test noisy area & good signal clients +10/20% good job. Sometimes 90mbit/s for client !!!
UDP test for 20 clients sector 110 Mbit/s impressive.

xrayd · Thu Mar 22, 2018 9:00 pm

I confirm improvement by ca. 40%
With version 6.41.3 and 26 clients ca.25-30 Mbit
With version 6.42.rc49 and 26 clients ca.45-50 Mbit

Testing with Only N, 20 Mhz, TDMA auto, dynamic downlink and 80% downlik ratio. MCS0-MCS7

Thanks Mikrotik!!!

karina · Thu Mar 22, 2018 9:48 pm

Massive improvement. However odd thing. Customer has 20megs. www.openspeedtest.com confirms. As does real world test like streaming multiple streams simultaneously. Ookla only shows 6 to 8 megs ??? Any ideas. Ookla is Def wrong

Sent from my ONEPLUS A5010 using Tapatalk

marcin21 · Thu Mar 22, 2018 9:54 pm

@lomayani
@2jarek
@xrayd

Have You upgraded clients as well, or just only AP ?

karina · Thu Mar 22, 2018 10:13 pm

@lomayani
@2jarek
@xrayd

Have You upgraded clients as well, or just only AP ?

Just ap.

Sent from my ONEPLUS A5010 using Tapatalk

mistry7 · Fri Mar 23, 2018 9:19 am

On my test Setup

Omnitik AC to 10x SXT Lite5ac i dont see a improvement, does it only works for 802.11an?
@Uldis

Did you test with old AN Hardware, because of it works only with them?

fiberwave · Fri Mar 23, 2018 9:46 am

@lomayani
@2jarek
@xrayd

Have You upgraded clients as well, or just only AP ?

First Mikrotik post says:
"Upgrade of the AP is required to the new rc version, clients can still use the old version."

.... read, read, read.....

karina · Fri Mar 23, 2018 11:05 am

The single most important thing that has happened for wisps everywhere. Thank you Mikrotik devs you rock the routing world.

marcin21 · Fri Mar 23, 2018 11:11 am

@lomayani
@2jarek
@xrayd

Have You upgraded clients as well, or just only AP ?
First Mikrotik post says:
"Upgrade of the AP is required to the new rc version, clients can still use the old version."

.... read, read, read.....

Yes, I've read what mikrotik staff reccomends, BUT its difference between REAL WORLD (what I was asking) and what Mikrotik declares that should work. And we have plenty of proofs it happened before many times.

Polky · Fri Mar 23, 2018 11:17 am

@uldis

Uploaded last rc46 i rc49 and watching great improvement. Linking to 1 thread is far better. Previously, I had to use AP 802.11 for that. Now Omnitik AC, 19 clients, 20/40 Ce, 2ms, dynamic 75 (no client has AC) .. 1 thread will make 110 Mbits, which was previously impossible. Of course, there is a zero traffic on the AP.
I see great improvement for myself, but there are still places where it is not that big.

Anyway, I send a lot of karma

.

I've already been thinking of deploying other software in the routerboard, but now I can forget it if the NV2 algorithm improves this way.

Fri Mar 23, 2018 11:42 am

Are people seeing improvements with 802.11ac or is this 802.11n only ?

xrayd · Fri Mar 23, 2018 11:56 am

@Polky
We also wanted to switch to Cambium Elevate, but luckily we do not have to do that anymore!!!

taduikis · Fri Mar 23, 2018 12:16 pm

@Polky
We also wanted to switch to Cambium Elevate, but luckily we do not have to do that anymore!!!

Well, these are not really even comparable yet. Elevate is expensive and only supports Lite5, but performance is way better due to huge advantages of AP side: neighboring channel rejection, better TDMA implementation, smart multibeam antennas, automatic channel selection, tx-power control, gps sync for channel reuse and so on. I've seen how they perform on UBNT elevated networks, and numbers are impressive. So MT do have everything in their hands here - just massively upgrade AP side to acquire all the missing features that almost all other vendors already have, and these improvements can be introduced to existing MT-based networks without replacing client side equipment. You then continue to exist and buy MT equipment to scale your network. I've also started testing Elevate and this MT improvement came out very coincidentally, but to me it doesn't solve anything..

fiberwave · Fri Mar 23, 2018 12:55 pm

@lomayani
@2jarek
@xrayd

Have You upgraded clients as well, or just only AP ?
First Mikrotik post says:
"Upgrade of the AP is required to the new rc version, clients can still use the old version."

.... read, read, read.....
Yes, I've read what mikrotik staff reccomends, BUT its difference between REAL WORLD (what I was asking) and what Mikrotik declares that should work. And we have plenty of proofs it happened before many times.

Ok, but that the problem was with the tx side not with rx == changing the sw on the client is not significant.
Have a nice day!

lomayani · Fri Mar 23, 2018 1:12 pm

Are people seeing improvements with 802.11ac or is this 802.11n only ?

these are my observations. we have few basebox5(802.11n) which is still existing in our network. We are seeing better results with netmetal ac more than basebox5
With basebox am seeing around 50-60mbps. With netmetal ac we are seeing up to 90mbps. We are seeing high improvement in both 802.11n and 802.ac but ac is performing better

okoun · Fri Mar 23, 2018 1:20 pm

we also ask that the great spcetral-history function begin again

[111@222] > interface wireless spectral-history wlan1 
failure: this device can not do spectral scan

server8 · Fri Mar 23, 2018 1:29 pm

Yesterday we switch from fixed download to dynamic with 6.42rc46 and we have had an improvment from 40 Mb/s to 50 Mb/s with upload working correctly

802.11 a/n/AC
20 Mhz
dinamic downlink
tdma period size auto
client 33
all client signal goog below -50
all modulation good

mistry7 · Fri Mar 23, 2018 2:37 pm

RB922 to Sextant (4 more clients)

nv2:

802.11

Fri Mar 23, 2018 2:46 pm

What happens is you use nv2-qos=default and second test what happens if you use dynamic-downlink instead of fixed-downlink mode?

mistry7 · Fri Mar 23, 2018 2:59 pm

What happens is you use nv2-qos=default and second test what happens if you use dynamic-downlink instead of fixed-downlink mode?

fixed

dyn dowblink

amt · Fri Mar 23, 2018 3:14 pm

What is 20/40MHz XX on Channel Width , I haven't seen it before.

human1982 · Fri Mar 23, 2018 3:20 pm

What happens is you use nv2-qos=default and second test what happens if you use dynamic-downlink instead of fixed-downlink mode?
fixed

dyn dowblink

I was talking abaout this, i was testing speed test and the speed was fine 60mbit to 711rb, but second rb has ping 10, 10, 20,200, 300, 2, 3. Default option. What with noise detection in 711? 6.39.3 Fine, up is the problem.

karina · Sat Mar 24, 2018 10:58 am

confirmed here, fixed download mode has severe impact on upload speeds on AP with 40 clients. dynamic all normal we give 10 down and 4 up. default QOS AP able to handle up to nearly 50Mb overall. before we maxed out at 30Mb with 40 clients

cpetey147 · Sun Mar 25, 2018 8:48 pm

IMO it is an improvement over the existing nv2. Roughly 20 percent increase but it still is in the shadow of nstreme. With nstreme I have much more reliable speeds to same client signals off different towers. With the newer nv2 I can push 30to40mg to metal 5s on 20mhz channel than in some other areas with same setup which is 2ms 80 percent dynamic downlink and black on spectral history for AP I can only push 10 to 12mg. On AC it performs better I can push 80mg to a single client with signals in 50s but it still pales in comparison to ubnt ptmp. Improvement yes needs another 20 to 30 percent increase in throughput to get close to ubnt or mimosa.

raceboy · Sun Mar 25, 2018 9:10 pm

i have sxt 5hg...both with latest rc os. nv2 protocol. signal is 100% both ways and rssi cca -45. send btest from ap is 170mbit receive is 250mbit. clean frequency. why is only 170mbit send?

Sent from my Moto G (5) Plus using Tapatalk

networkfudge · Mon Mar 26, 2018 7:11 am

I can confirm a consistent 2x increase in bandwidth on 1 N and 3 AC basestations after this update.

20mhz channel, nv2 period size auto, dynamic downlink 70%

Bandwidth increase observed before upgrading routerboard firmware on basestation and without touching any of the CPE devices.

This free, yet significant, boost in performance enables us to remain loyal to Mtik for our Wireless needs for the next few years.

Thank you Mikrotik team for not giving up on wireless

Now if you could just improve the nv2 jitter siuation somewhat that would truly make you the indisputable king of wireless

Polky · Mon Mar 26, 2018 10:28 am

@uldis

I started uploading rc49 to client units. But I have terrible results. Ping 5,5,450,10,730 ... etc . It's quiet for a while, and CCQ falls, and RATE to 6 Mbits, and it's up again.
Test for Omnitik a / n and RB711 client. I get the same results with SXT SA5ac and SXTsq client.
As soon as the client is, for example, 6.33.5 on RB711 .. CCQ and rate are OK.
(6.41.3, 6.40.6 version also bad) .. unfortunately, SXTsq can not use older.

Do not upload new versions to clients, only to AP. (I like rc49, AP gives very good results)

Mon Mar 26, 2018 11:06 am

Note that with the new changes if you have client with bad connection now it would not effect the performance of the whole AP. Now if both good and the bad client downloads at the max speed will result not in equal data amount to each client but the equal download time spent for each client.
Also with a fully saturated link even when the dynamic downlink is used it is possible to get faster Download speed with higher downlink-ratio but that would result in bigger latency as the AP would check the clients less often if they have some data for sending.

Polky · Mon Mar 26, 2018 11:15 am

I'm very glad that one client will not kill the entire AP.
The new changes are very good on the AP. But when the last rc version I upload to the client, it behaves very weird about CCQ and ping, even though I think it has a very good signal and CCQ.

WirelessRudy · Mon Mar 26, 2018 12:14 pm

@uldis

Uploaded last rc46 i rc49 and watching great improvement. Linking to 1 thread is far better. Previously, I had to use AP 802.11 for that. Now Omnitik AC, 19 clients, 20/40 Ce, 2ms, dynamic 75 (no client has AC) .. 1 thread will make 110 Mbits, which was previously impossible. Of course, there is a zero traffic on the AP.
I see great improvement for myself, but there are still places where it is not that big.

What do you mean with 1 thread? One stream? How to achieve that, only setting mcs 1-7? (not 8-15?)

Second Question; What do you mean with "Of course, there is a zero traffic on the AP?" How can you have zero traffic on AP if you are testing clients? Zero traffic means no traffic at al and clients have nothing.....

Polky · Mon Mar 26, 2018 2:25 pm

Sorry, bad english.
I thought 1 connection in Btest.
I'm always testing 1 connection.

Zero traffic: I think other AP clients carry a small amount of data.

Previously, I was not able to make 100 Mbits for 1 connection in the NV2 protocol with so many clients.

WirelessRudy · Mon Mar 26, 2018 2:28 pm

Ok, been reading this tread with interest. We've been migrating some AP's already to both eCambium and Mimosa en Albetia (Spanish) and although each in their field give better results then Mikrotik, they also come with side effects. Main factor is the higher price. Main complication is the need to swap a whole M2MP network..... So if this new firware is as good as some would make me believe AND if more improvements are on the horizon we might decide to stay with Mikrotik a bit longer....
(I hate the view of all these ubnt dishes around me! Mikrotik, please help us to beat them!

)

This new improvement in wireless can be concluded as follows?

- Only need to upgrade AP, don't touch the CPE
- Improved capacity towards client in >10+ CPE M2MP.
- Improved capacity in aggregated throughput over the AP
- One 'bad' client won't have such a devastating effect on the rest if he is 'eating' airtime....

Still a lot of questions to be answered (I refer to 20+ CPE P2MP networks in congested spectrum):

- Dynamic versus fixed downlink. It seems fixed is better but I cannot get a real conclusion on this.

- TDMA Period Size; I cannot distill what is better. Dynamic of fixed set? To be honest in post of members they are all over the place and in our network they are also not consistent. Sometimes 'auto' is better, sometimes not. And sometimes the same AP is set to 'auto' because it is better, but half a year later we st it back to 2ms fixed because then that gives better results.
It's a bit misty because in fact it is not really sure what 'auto' means. Is this really an automatice continue variable setting adapted to real time conditions and per connected client? Or is it just like after reboot AP sets a fixed overal setting and keeps it there until next reboot?

- 'n' protocol versus 'ac'. The basic 802.11ac is by its nature better then 'n'. But is this also in effect for NV2? (In fact I have some AP on plain 'ac' and they work no worse then on NV2.)

- 'n' protocol versus 'ac'. The devices capable of 'ac' have a better chipset which also helps in performance. So if 'ac' is better, even with the new firmware, is this because of the better chipset or is it because of the better firmware?

- Signal strengths: Where we would work up to -70's years ago, started with -60's a year ago we should really go for -50's or better on 20+ CPE networks in congested regions? What is the experience in the field of the many WISPS that have to serve high amount of clients?

- If fixed/dynamic down-link rate 60/40 - 70/30 or even 80/20 are set, and we are replacing Sextants or SXT's for LHG's versus SXTsq's we also loose 2 to 5dB in output of the CPE (=up-link). We are getting bigger differences in the down-link versus up-link signals on the AP. So if we are seeking better MCS rates AND 'ac' AND start working a-synchrone up/down-link rates we have to be aware that although we might have improved a lot on de down-link side, the up-link has become worse and therefore still brings the overall capacity of the P2MP network down?

Wishes we still have:
- Spectral scan/history. Any serious WISP nowadays needs to know about the real spectral situation. When is this being solved? We have seen the SXT-ac device come with a 2,4Ghz radio in which hasn't a lot of use to many or us. Why not replace that for an 802.11a/b/g/n radio? Now we can use that radio for the Spectral and band scan without interrupting the actual link! (Make sure that the radio should filter out/omitt the signal of its own main radio!)
Make sure this 2nd radio is available in the new Omnitik and other devices that can serve as AP.

- 'out of band' filtering. Mimosa, eCambium and the Airmax radio's all have something to filter/eliminate/reduce signals the radio is not really aimed for. Mikrotik should be looking into this.

- beam forming. This needs at least triple or quadruple chain radios. Is Mikrotik already working towards that? We already have triple chain Netmetals but beam forming is a real good tool for interference rejections and signal improvements that most competitors already understood and started to roll out....

- Mu-Mimo. Although it needs new hardware we have no clue if MT is working on this. More then a year ago in Milan somebody in a presentation showed how it worked and sort of 'tipped' Mikrotik to start working on it but since then not a single word. Most competitors are working on it, have some prototypes or are starting to roll it out.
From Mikrotik we don't even know if they are having development team working on it.

These 'wish list' items we need some foresight. If by the present improvement we could sustain a bit longer with Mikrotik instead of migrating. But if there are no more lights at the horizon we still look at other options. Wifi is an evolving market and competition is severe in many regions. We/Mikrotik can only survive if they have a good roadmap into the future......

WirelessRudy · Mon Mar 26, 2018 2:46 pm

Sorry, bad english.
I thought 1 connection in Btest.
I'm always testing 1 connection.

Zero traffic: I think other AP clients carry a small amount of data.

Previously, I was not able to make 100 Mbits for 1 connection in the NV2 protocol with so many clients.

Ok, I understand. 1 connection bandwidth test indeed reflects best the capacity for a single client if he uses IPTV (a big data consumer nowadays) and it gives a good idea of the overall package loss.
When testing client capacity we test from the client CPE (not always a 2nd router behind the CPE is available, it would be better though) towards a powerful router just behind the AP. This way is best to test the P2MP network performance for that CPE and the AP.
Then we also test with 20 or more connections. If the result is the same (bad or good) we know that the limit is in the physical link (connection rate, power of the cpu)
If there is big difference between 1 or many streams we know the package loss 'per stream' is high and the wireless link should be improved. (CCQ is a help here too, but not always very reliable and fluctuating a lot)

Atentaduh · Tue Mar 27, 2018 2:48 am

Hi guys,

i've been working with mikrotik for quite a while.. and i never ever could see good results with nv2 seriously
and i was so excited when i read the patch notes. so i give it a try with nv2 again and the same thing... high ping low troughput even 802.11 works better

NSTREME works way better in every way for me.. low latency, good troughput

Atentaduh · Tue Mar 27, 2018 2:58 am

Hi guys,

i've been working with mikrotik for quite a while.. and i never ever could see good results with nv2 seriously
and i was so excited when i read the patch notes. so i give it a try with nv2 again and the same thing... high ping low troughput even 802.11 works better

NSTREME works way better in every way for me.. low latency, good troughput

well i cant attach a file.. so i've a omnitik(N) running nstreme @20Mhz with 37 sxt lite5 and the ap reach over 68Mbps... if i switch to nv2.. i can barely push over 30Mbps

WirelessRudy · Tue Mar 27, 2018 3:10 am

Tonight tried the new 6.42rc49 on a Netmetal that had 6.40.5 running.

The radio is running 'n' mode with 28 'n' clients connected. Before the upgrade max TTL througput over the AP I could hardly get 40Mbps and some poor connected clients could hardly get 1Mbps of traffic.
After the upgrade I could push the AP through the 100Mb limit when I did not use the poor clients. But in trying the poor clients I could stil increase their capacity from around 2-4mbps to over 10Mbps.

Nstreme never worked for me. Not on P2P and not on P2MP.

Yesterday I spend 2 hours testing a P2MP network and a link. In both instances nstreme was the worst. I tried every possible setting with nstreme and although the ping more stable then 802.11 the NV2 ping was a bit less stable but much lower then nstreme.

Over the years I tried nstreme several times on links and P2MP but never got better results. NV2 is mostly winner, and in some specific situations with RTS/CTS finetuning in low use network plain 802.11 is sometimes even better....

Cetalfio · Tue Mar 27, 2018 7:54 am

I tried version 6.42rc49 with some AP with 921GS-5HPacD r2 and 912UAG-5HPnD. While with the first RBs I have noticed substantial improvements with only-n and tdma auto and mode dynamic downlink ratio 80, with some 912UAG-5HPnD I had problems with some CPEs with non-optimal signal values that work first while with the new version remain associated to the BS but no data traffic.

Uldis we have been many years waiting for a wireless improvement on ROS and we are all very happy with this update, we hope that you continue to develop this part where the other competitors are definitely ahead.

cetalfio

server8 · Tue Mar 27, 2018 12:31 pm

Uldis we have been many years waiting for a wireless improvement on ROS and we are all very happy with this update, we hope that you continue to develop this part where the other competitors are definitely ahead.

I hope this is a starting point and to have future improvements and synced hardware

n21roadie · Tue Mar 27, 2018 2:19 pm

........
After the upgrade I could push the AP through the 100Mb limit when I did not use the poor clients. But in trying the poor clients I could stil increase their capacity from around 2-4mbps to over 10Mbps.

.......

Just to be clear did connected poor clients impact on the AP overall performance?

xrayd · Tue Mar 27, 2018 2:30 pm

rborz · Tue Mar 27, 2018 10:18 pm

Upgraded two nv2 sectors to current release candidate, 20 subscribers each. Now clients with good RSSI/CCQ get reasonable speed, while clients with low RSSI/CCQ are stil performing bad. Also the average throughput on the sectors almost doubled during peak times (from 8-10 to 16-20 Mbps). Running this with fixed-downlink-ratio set to 75 and 20 MHz channel 5-ghz-onlyn, TDMA 2 ms.

Looks good!

Maybe this can be more improved in the future. But it really looks like a great step forwards.

What is the recommendation in noisy environments? Running nv2 with adaptive-noise-immunity switched on on client and AP? Does ist affect nv2 operation at all?

Robert

WirelessRudy · Wed Mar 28, 2018 12:37 am

........
After the upgrade I could push the AP through the 100Mb limit when I did not use the poor clients. But in trying the poor clients I could stil increase their capacity from around 2-4mbps to over 10Mbps.

.......
Just to be clear did connected poor clients impact on the AP overall performance?

Indeed not. In the past, when performing a bandwidth test from a poor client while good clients where running this was noticeable. Now this hardly is noticeable anymore. Two good clients running with some 30mbps didn't loose speed. The poor clients (I have two) had more speed as before but it doesn't seem to have too much impact on the better clients.
Tests are still moment pictures and speeds always fluctuate. It's a 28 client network where at least half of them where browsing or whatever. Although maybe not yet the holy grail, definitely better then before...

WirelessRudy · Wed Mar 28, 2018 12:51 am

What is the recommendation in noisy environments? Running nv2 with adaptive-noise-immunity switched on on client and AP? Does ist affect nv2 operation at all?

Robert

I always use it. To be honest be surprised by the question. Why NOT use them?

WirelessRudy · Wed Mar 28, 2018 1:56 am

Why can I not put a picture (screendump) in this forum anymore? Drag and drop won't work. Click on 'insert image' give me the code for the image insert but cannot put the image from my PC in there....?

It was to show that after my upgrade to the new rc the average overall throughput on one AP went up by some 40-60%.
In comparison, our total network traffic from client in the same period doesn't show more usage....
Since this AP has 28 clients and in a normal region where other AP's also cover it's not because of more internet demand from just this group. It's because demand is met easier due better performing AP!

marcin21 · Wed Mar 28, 2018 5:24 pm

Massive improvement. However odd thing. Customer has 20megs. www.openspeedtest.com confirms. As does real world test like streaming multiple streams simultaneously. Ookla only shows 6 to 8 megs ??? Any ideas. Ookla is Def wrong

Maybe mikrotik staff "borrowed" some technics from plain 802.11n. afair 6,5mbps per tcp session was/is limit of 802.11n standard.
or am I wrong?

WirelessRudy · Wed Mar 28, 2018 9:52 pm

Massive improvement. However odd thing. Customer has 20megs. www.openspeedtest.com confirms. As does real world test like streaming multiple streams simultaneously. Ookla only shows 6 to 8 megs ??? Any ideas. Ookla is Def wrong

Maybe mikrotik staff "borrowed" some technics from plain 802.11n. afair 6,5mbps per tcp session was/is limit of 802.11n standard.
or am I wrong?

If you make a speed test with Mikrotik bandwidth test you can test with up to 99 streams. Ookla only uses 2 I believe.
What is the difference?
If you use one stream to test, then the link shows the maximal throughput of that stream. If the connection is poor (low CCQ) then this stream needs many package re sending. Next package is only send when previous made it in order.
With many streams you can make better use of the radio's air time. Even if one package from one stream had to be resent the other stream could have had succes or is just working on its own data stream to get it to the other end... So at least radio is more busy.
Do this with 4, 10, 30 or 99 streams and its clear that you now can use the radio's capacity to the max and thus test the absolute throughput of the link.
But this is only nice for programs where latency is not an issue, like web browsing and/or ftp, p2p, downloads etc. Although there maybe many packages needed to resend, the total is still good. As long as the data makes it in the end!

But for programs that run on one stream only (IPTV, communications, single download steam) it is more important the single stream throughput is good. It means little package resend or losses and thus low latency.

So if you can test your link with Mikrotik bandwidth test program and many streams you can test the raw bulk maximum capacity of the link.
With a single stream, or Ookla, you are more testing how good or bad the link is. How many data gets lost or has to resend while trying to reach the other end of the link....

In this analogy you can first make a test with lets say 10 or 20 streams. Then you have a good idea of how fast multi stream programs (webbrowser) can download and what the physical maximum is of the link.
Then if you do a single stream test and see its almost the same, you have a good quality link and not a lot of saturation on the P2MP network (too many other users busy)
If the difference is huge, then something is wrong with the quality and you'd start looking for the problem and try to solve it.

karina · Wed Mar 28, 2018 10:05 pm

Massive improvement. However odd thing. Customer has 20megs. www.openspeedtest.com confirms. As does real world test like streaming multiple streams simultaneously. Ookla only shows 6 to 8 megs ??? Any ideas. Ookla is Def wrong

Maybe mikrotik staff "borrowed" some technics from plain 802.11n. afair 6,5mbps per tcp session was/is limit of 802.11n standard.
or am I wrong?
If you make a speed test with Mikrotik bandwidth test you can test with up to 99 streams. Ookla only uses 2 I believe.
What is the difference?
If you use one stream to test, then the link shows the maximal throughput of that stream. If the connection is poor (low CCQ) then this stream needs many package re sending. Next package is only send when previous made it in order.
With many streams you can make better use of the radio's air time. Even if one package from one stream had to be resent the other stream could have had succes or is just working on its own data stream to get it to the other end... So at least radio is more busy.
Do this with 4, 10, 30 or 99 streams and its clear that you now can use the radio's capacity to the max and thus test the absolute throughput of the link.
But this is only nice for programs where latency is not an issue, like web browsing and/or ftp, p2p, downloads etc. Although there maybe many packages needed to resend, the total is still good. As long as the data makes it in the end!

But for programs that run on one stream only (IPTV, communications, single download steam) it is more important the single stream throughput is good. It means little package resend or losses and thus low latency.

So if you can test your link with Mikrotik bandwidth test program and many streams you can test the raw bulk maximum capacity of the link.
With a single stream, or Ookla, you are more testing how good or bad the link is. How many data gets lost or has to resend while trying to reach the other end of the link....

In this analogy you can first make a test with lets say 10 or 20 streams. Then you have a good idea of how fast multi stream programs (webbrowser) can download and what the physical maximum is of the link.
Then if you do a single stream test and see its almost the same, you have a good quality link and not a lot of saturation on the P2MP network (too many other users busy)
If the difference is huge, then something is wrong with the quality and you'd start looking for the problem and try to solve it.

Thank you for this explanation. Excellent information.

Sent from my ONEPLUS A5010 using Tapatalk

networkfudge · Wed Mar 28, 2018 10:31 pm

I would argue that one must always test radio links with single tcp stream.

Testing whether your tcp connection can build up and withstand its speed is the one true benchmark when it comes to testing your layer 1 (radio link in our case).

Say for example you get 70meg with 1 connection tcp traffic one-way, and then you subsequently attempt to test with 4 connections. If you get the same result then you know that your channel is nice and clean and path has no fresnel issues or reflections because you can reach the physical speed limits (defined by your channel width, no of spatial streams, max modulation) of your layer 1 just with that single connection.

Hope this helps someone.

Wed Mar 28, 2018 10:42 pm

Massive improvement. However odd thing. Customer has 20megs. www.openspeedtest.com confirms. As does real world test like streaming multiple streams simultaneously. Ookla only shows 6 to 8 megs ??? Any ideas. Ookla is Def wrong

Maybe mikrotik staff "borrowed" some technics from plain 802.11n. afair 6,5mbps per tcp session was/is limit of 802.11n standard.
or am I wrong?
If you make a speed test with Mikrotik bandwidth test you can test with up to 99 streams. Ookla only uses 2 I believe.
What is the difference?
If you use one stream to test, then the link shows the maximal throughput of that stream. If the connection is poor (low CCQ) then this stream needs many package re sending. Next package is only send when previous made it in order.
With many streams you can make better use of the radio's air time. Even if one package from one stream had to be resent the other stream could have had succes or is just working on its own data stream to get it to the other end... So at least radio is more busy.
Do this with 4, 10, 30 or 99 streams and its clear that you now can use the radio's capacity to the max and thus test the absolute throughput of the link.
But this is only nice for programs where latency is not an issue, like web browsing and/or ftp, p2p, downloads etc. Although there maybe many packages needed to resend, the total is still good. As long as the data makes it in the end!

But for programs that run on one stream only (IPTV, communications, single download steam) it is more important the single stream throughput is good. It means little package resend or losses and thus low latency.

So if you can test your link with Mikrotik bandwidth test program and many streams you can test the raw bulk maximum capacity of the link.
With a single stream, or Ookla, you are more testing how good or bad the link is. How many data gets lost or has to resend while trying to reach the other end of the link....

In this analogy you can first make a test with lets say 10 or 20 streams. Then you have a good idea of how fast multi stream programs (webbrowser) can download and what the physical maximum is of the link.
Then if you do a single stream test and see its almost the same, you have a good quality link and not a lot of saturation on the P2MP network (too many other users busy)
If the difference is huge, then something is wrong with the quality and you'd start looking for the problem and try to solve it.

Ookla does 4 streams. IPTV does udp which was not a big problem so far with nv2. Nv2 kills tcp speed with more connected clients which gIves bad speedtest result even if the cpe is the only one using bandwidth. This problem starts below 10 connected cpes. Nstreme always was much better regarding this but at some time in ROS history nstreme became unstable with light interference causing cpes to reconnect.

Hope this new effort MT does now solve this problems. They ignored this problem so long that every wisp with more then 10 customers shopped elsewhere.

There are still basic features missing. ATPC at cpe side is a must have feature for wisps. Working radar detection,...
Beside a good working tdma protocol fighting interference is a must have. There is a lot of work todo ...
Let's see if MT takes thing's serious now.

WirelessRudy · Thu Mar 29, 2018 1:06 am

I would argue that one must always test radio links with single tcp stream.

Testing whether your tcp connection can build up and withstand its speed is the one true benchmark when it comes to testing your layer 1 (radio link in our case).

Say for example you get 70meg with 1 connection tcp traffic one-way, and then you subsequently attempt to test with 4 connections. If you get the same result then you know that your channel is nice and clean and path has no fresnel issues or reflections because you can reach the physical speed limits (defined by your channel width, no of spatial streams, max modulation) of your layer 1 just with that single connection.

Hope this helps someone.

You are absolutely right!
But real world is a bit different at times. Sometime you just need a link to carry a bulk of traffic even if the single tcp stream show it's not a very good link. Sometimes there's simply no alternative or no time, or no money, to upgrade.
As long as my 300Mb PHY link can transport 100Mb of my clients during rush time while the single stream only produces 20-30mbps I know that it should be better but at least my 200 clients have internet...... Lets write it in the 'to do list' book with a back log of about half a year and lets work on higher priority issues....

Building the best network you can is always a balance between resources, time and client income. And in the meantime competition tries to beat you on each of these arguments......

rborz · Sat Mar 31, 2018 10:38 am

What is the recommendation in noisy environments? Running nv2 with adaptive-noise-immunity switched on on client and AP? Does ist affect nv2 operation at all?
I always use it. To be honest be surprised by the question. Why NOT use them?

With adaptive-noise-immunity turned on throughput and latency are a mess. Download to the clients (still 20 subscribers per sector) only 2-3 Mbps, upload from the clients below 500 Kbps. So we switched it off.

Additionally we had to switch nv2 configuration from fixed-downlink-mode to dynamic-downlink-mode and also set QoS to default instead of frame-priority. Our VoIP prioritization rules are now useless... but VoIP quality, throughput and latency are good.

Now seeing a total througput on the sectors of up to 28 Mbps.

Robert

WirelessRudy · Sat Mar 31, 2018 4:47 pm

With adaptive-noise-immunity turned on throughput and latency are a mess. Download to the clients (still 20 subscribers per sector) only 2-3 Mbps, upload from the clients below 500 Kbps. So we switched it off.

That doesn't make a lot of sense.

I found some text prescribing in short (I found much more extended articles too) what ANI does do:

Adaptive Noise Immunity
Better WLAN throughput due to immunity against interferences. With Adaptive Noise Immunity WLAN clients benefit from significantly more
data throughput, thanks to a trouble-free WLAN coverage. With Adaptive Noise Immunity the access point dismisses interferences in the radio field
and focuses only on WLAN clients with sufficient signal strength.

You are saying its the opposite in your case?

Yes, in heavy foreign interference spectrum the cpu has to work hard so that could have a performance impact to the older/weaker type CPU's. But anything better then the 911 series of board should have no problems with that.
And if you would be working with older CPE's and be in a heavy foreign interference troubled spectrum, switching it off would make transmissions between station and client even worse...
Unless off course you are working weak signal level connected clients. Anything worse then -70dB should be discarded. We already set the max. level at -60dB and are basically aming to have all clients close to -50 or better.

In the past I'd remember on some units we forgot to switch it on and after troubleshooting why client had poor performances we found it off. After switching it on the link improved...
The use is ANI is almost de-facto standard in the industry and I have never heard any that says its better to switch it off....
But I'll be the first to learn if someone can really show under which circumstances it would better be off.....

WirelessRudy · Sat Mar 31, 2018 5:07 pm

Additionally we had to switch nv2 configuration from fixed-downlink-mode to dynamic-downlink-mode and also set QoS to default instead of frame-priority. Our VoIP prioritization rules are now useless... but VoIP quality, throughput and latency are good.

Now seeing a total througput on the sectors of up to 28 Mbps.

Robert

I just post a test viewtopic.php?f=7&t=132548&p=651567#p651167 where I hardly see a difference between variable and fixed download link rate. Actually a slight difference in favor of the fixed mode....

We'd always work with default QoS settings. Rarely having complaints about Voip, Skype, Facetime, or whatever communication services. I just make sure there is plenty bandwidth available and the need of QoS is little. Our network is a big X-mas tree style with some clients have to go through 6 or 7 wireless hops and double the amount of routers/switches so setting QoS everywhere would slow down traffic more than have it passed to all corners unprocessed. Plus al the extra work in fine tuning (to make QoS work you need to set bandwidth usage to 80% of the maximum to make it work and account for weather margin, interference margins. Each link has its own characteristics and variables so that would make a hell of a task and we loose 20% capacity on the total network. )
I'd rather spend a bit more on wide enough 'pipes' everywhere including my supplier's..

server8 · Fri Apr 06, 2018 3:05 pm

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

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

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

Mikrotik maybe with a little work on the NV2 scheduler we can stay closer to ubiquiti

WirelessRudy · Fri Apr 06, 2018 7:31 pm

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

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

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

Mikrotik maybe with a little work on the NV2 scheduler we can stay closer to ubiquiti

That's good news, and bad....
The good is that you can confirm there is a improvement, something others already noticed including me. But since some others also still say they don't see the improvement happening this always leaves room for doubts... hence the more, and the bigger operators, can confirm, the better....

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

Now I do have some remarks on the side:

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

This would make the comparison different?

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

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

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

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

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

karina · Sat Apr 07, 2018 7:28 pm

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

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

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

Mikrotik maybe with a little work on the NV2 scheduler we can stay closer to ubiquiti

I am a little confused about the downlink ratio setting. I assumed the percentage setting was for fixed and dynamic was just dynamic with no bias. I read people are setting the ratio to Dynamic but also assuming the percentage setting make a difference. Can someone confirm the difference between 80% Dynamic and 80% fixed

Sent from my ONEPLUS A5010 using Tapatalk

karina · Sat Apr 07, 2018 7:50 pm

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

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

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

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

Sent from my ONEPLUS A5010 using Tapatalk

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

Sent from my ONEPLUS A5010 using Tapatalk

n21roadie · Sun Apr 08, 2018 3:02 pm

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

Sent from my ONEPLUS A5010 using Tapatalk

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

WirelessRudy · Sun Apr 08, 2018 5:22 pm

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

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

I can underwrite that last question in ful!

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

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

hapi · Wed Apr 11, 2018 9:12 am

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

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

hapi · Wed Apr 11, 2018 9:35 am

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

mistry7 · Wed Apr 11, 2018 11:25 am

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

I rolled back my Test AP because of users complaining about Voice quality, this could be the reason.....

nichky · Wed Apr 11, 2018 11:47 am

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

Thanks

hapi · Wed Apr 11, 2018 11:59 am

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

hapi · Wed Apr 11, 2018 12:13 pm

NV2 is still very bad.

802.11:

nv2 2ms dynamic:

n21roadie · Wed Apr 11, 2018 4:12 pm

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

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

@ hapi Just looking at your clients CCQ and they are terrible ! Are you using default or set data rates?

hapi · Wed Apr 11, 2018 4:14 pm

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

You do not talk to a beginner.

n21roadie · Wed Apr 11, 2018 4:21 pm

NV2 is still very bad.

802.11:

nv2 2ms dynamic:

@ hapi Sorry for this but those very high signals ( -22,......) could be overloading wireless input stages and it appears in this situation that 802.11 is more tolerant than NV2?

hapi · Wed Apr 11, 2018 5:49 pm

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

n21roadie · Wed Apr 11, 2018 9:09 pm

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

After a very quick search -please read the following to support my "Theory"
https://community.ubnt.com/t5/airMAX-Wi ... d-p/188574

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

Could I suggest as a test as you have issues NV2 (and for our network NV2 is very stable - but getting more throughput is always a challenge)
Have you tried to lower AP power by entering +db number in "Antenna Gain" and try to get client signals in the 50-65 dbm range and test NV2 ?

hapi · Wed Apr 11, 2018 10:55 pm

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

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

As I said, the results are the same in other locations where signals are around -50dB.

WirelessRudy · Thu Apr 12, 2018 1:38 am

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

I'll guess every network has its characteristics. NV2 is designed to overcome problems in P2manyP networks. So it would be a complete failure if that would not be the case. And since most in Mikrotik land claim it does work better than plain 802.11 I think your statement of NV2 not being so good at all bears little fundament.
TDMA is especially designed to give each associated station a fair part of the radio time compared to its need to send or receive data. In 802.11 basically all radio's fight for airtime with AP and if then some of those CPE's can't even 'hear' each-other we get the 'hidden-node' issue on top of it.

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

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

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

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

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

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

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

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

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

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

hapi · Thu Apr 12, 2018 1:54 am

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

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

And this is what? This is complete failure.

I do not want to talk about how bad it is. I show how NV2 is in a difficult environment. This is the meaning of this thread. If I have to go to 802.11, it does not make sense for us to use MIKROTIK because 802.11 can also be another manufacturer that currently works on MIKROTIK much better than their own protocols.

WirelessRudy · Thu Apr 12, 2018 2:13 am

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

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

As I said, the results are the same in other locations where signals are around -50dB.

Experiences over the years and trying to get the higher signal levels so we can get the higher speeds to the clients I sort of distilled the following:

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

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

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

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

http://www.revolutionwifi.net/revolutio ... pping.html

0ldman · Thu Apr 12, 2018 8:31 am

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

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

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

WirelessRudy · Thu Apr 12, 2018 12:29 pm

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

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

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

What do you mean with "full modulation"?

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

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

Working with signals in the -60 to -80 range is nowadays only possible in real remote areas where there is hardly any other Wifi around and demand is small.....

taduikis · Thu Apr 12, 2018 3:23 pm

No wonder everyone is complaining and whining about poor WiFi performance.. signals of -20 dBm.. sweet jesus.. help me live through this madness..

0ldman · Thu Apr 12, 2018 7:12 pm

Full modulation, max speed, highest modulation.

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

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

WirelessRudy · Thu Apr 12, 2018 8:06 pm

Full modulation, max speed, highest modulation.

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

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

My English isn't my first language no, but it is coming close. After 45 years working in an English environment I think it's not so bad.

But even if you would have written it in Dutch, (my native language, "modulation" = "modulatie") I would still asked you the same.......

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

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

WirelessRudy · Thu Apr 12, 2018 8:15 pm

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

Now the 5Ghz is only a backup.)

0ldman · Thu Apr 12, 2018 9:50 pm

Gotcha.

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

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

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

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

It is very odd.

n21roadie · Thu Apr 12, 2018 10:28 pm

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

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

As I said, the results are the same in other locations where signals are around -50dB.

It must be very frustrating trying to work with that ambient noise level !
I am sure you have already tried re-locating PTP's and AP's + CPE's that are effected the most to where interference is reduced ?

n21roadie · Thu Apr 12, 2018 10:31 pm

.................... But we had to tune down the radio to very low output to make a -40 signal. Basically we talk 4 or 6 dBm. We actually found that the links became unstable. On other occasions where we had the same issue we found that most Mikrotik devices don't like it when we set outpot lower than some 10 dBm.
......................

Can I ask if output power was above 10dBm were the links stable?

WirelessRudy · Fri Apr 13, 2018 3:01 am

.................... But we had to tune down the radio to very low output to make a -40 signal. Basically we talk 4 or 6 dBm. We actually found that the links became unstable. On other occasions where we had the same issue we found that most Mikrotik devices don't like it when we set outpot lower than some 10 dBm.
......................
Can I ask if output power was above 10dBm were the links stable?

Yes, with higher output they were fine. This were SXT-HG-n units we took away now we have the 60Ghz link running.
But I saw similar on some SXT-Lites that were very close to a tower. It was better to have it hit the tower with -25 and it's output somewhere around 10dB while if we set the output lower the connection rates started to jump up and down resulting in more un-stable ping.

But this is all info from some 2-3 years ago. Maybe it's not that bad any more with the newer devices...

Zod · Fri Apr 13, 2018 10:46 pm

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

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

Here is what I saw:

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

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

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

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

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

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

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

Z

planetcaravan · Wed Apr 18, 2018 1:07 pm

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

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

I've noticed a big increase on WLAN throughput

mistry7 · Wed Apr 18, 2018 2:05 pm

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

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

I've noticed a big increase on WLAN throughput

please check your latency
Do you deliver voice service?

planetcaravan · Wed Apr 18, 2018 4:02 pm

Latency seems to be remains the same as before
Yes, I deliver voice service

jonmansey · Sat Apr 21, 2018 8:12 am

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

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

Are we starting to see a pattern with OmniTik not working right under 6.42 nv2? Anyone with an OmniTik PtMP get the expected success and improvement with 6.42?

hapi · Sat Apr 21, 2018 8:41 am

not everyone.

mistry7 · Sat Apr 21, 2018 8:59 am

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

We saw the same on RB922, not possible for voice service, to much jitter
We go back to 6.41.4 and everything fine

human1982 · Sat Apr 21, 2018 10:41 am

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

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

Are we starting to see a pattern with OmniTik not working right under 6.42 nv2? Anyone with an OmniTik PtMP get the expected success and improvement with 6.42?

Try period auto mcs auto hw-retries 10 dynamic downlink cell 10 Guard long. If u also upgraded stations check noise floor on them. Some 711 (random and in 802.11 work fine!) noise floor need to be set manually to -105 -100... Re

WirelessRudy · Sun Apr 22, 2018 9:10 pm

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

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

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

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

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

We tried ROSv 6.40.5, 6.40.7, 6.41.3 and last 6.42

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

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

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

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

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

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

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

Sun Apr 22, 2018 9:49 pm

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

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

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

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

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

We tried ROSv 6.40.5, 6.40.7, 6.41.3 and last 6.42

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

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

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

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

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

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

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

You are kidding. You have 5X hangin and do this fiddling around with nv2

. I've our first 5XHD hanging so 5X is already old stuff. There is no way I waste a second longer on trying to squeeze nv2 to get a poor link at best. We stay with MT routing and might use the upcoming switches. But wireless ... ages behind !
Just updates some CPEs and learned that I forgot that since a specific ROS Version CPEs only try 2 APs with same SSID. So if they see more they just dont try the other and do not connect. So update means disconnect for some of the CPEs.... I am so bored with this buggy crap eating my time like bread ... Each of this cpes is replaced immediately with working stuff to keep this customer.

WirelessRudy · Mon Apr 23, 2018 11:36 am

You are kidding. You have 5X hangin and do this fiddling around with nv2 . I've our first 5XHD hanging so 5X is already old stuff. There is no way I waste a second longer on trying to squeeze nv2 to get a poor link at best. We stay with MT routing and might use the upcoming switches. But wireless ... ages behind !

The 5X's we have do their job. So budget we have is not spend to replace them. As long as they give us enough bandwidth they are fine...
But we have plenty of smaller backhauls; 1 - 4 km's that need to transport up to 100Mbps. Since all our towers are full and our budget is very limited we'd rather squeeze the max out of Mikrotiks then just buy more Airfibre-X5's. If we'd had the money we'd probably do. (And these units seem to disrupt spectrum more than other solution in and around their working band. A lot of energy is thrown out.)

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

Just updates some CPEs and learned that I forgot that since a specific ROS Version CPEs only try 2 APs with same SSID. So if they see more they just dont try the other and do not connect. So update means disconnect for some of the CPEs.... I am so bored with this buggy crap eating my time like bread ... Each of this cpes is replaced immediately with working stuff to keep this customer.

Why would you have several CPE's with the same SSID? Every CPE from us is tuned to its AP with its own specific SSID. It also makes it easy to find other AP's in the region if you'd run a scan So it only looks for that SSID only that we know is the nearest or that the scan shows gives the strongest signal. Only in some rare case I set in 'connect list' a second AP with its SSID. So this CPE could go to another easy when the first is overloaded for instance But in reality this is not ideal. That 2nd AP's signal is always worse since we pick the best to tune the CPE at.
I agree that since some versions ago, the first line of the 'connect list' is decisive. Where in the past CPE's could freely pick any AP from the list, now it only searches for the top one. Even if that AP is down, the CPE will make no attempt to connect to the second in the list. I agree that in that respect (and more 'small' issues) ROS definitely didn't bring progress. On the contrary!)

Mon Apr 23, 2018 11:56 am

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

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

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

Esp with full towers the limited (expensive) resource is spectrum. So squezing >100MBit out of a 10MHz Channel and reusing the same freq is worth the money. Dont forget your working time to fiddle around. Spending 1000€ to a Networking expert gives not much time to play.

Mon Apr 23, 2018 2:44 pm

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

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

Are we starting to see a pattern with OmniTik not working right under 6.42 nv2? Anyone with an OmniTik PtMP get the expected success and improvement with 6.42?

Could you tell us more detailed info on your setup? What is the distance from the SXTs to the OmniTik? Does all the clients suffer from this or only few? which exact SXT models you have as CPEs?

WirelessRudy · Mon Apr 23, 2018 5:48 pm

Esp with full towers the limited (expensive) resource is spectrum. So squezing >100MBit out of a 10MHz Channel and reusing the same freq is worth the money.

Are you talking bits per second or bytes?
I am referring to 100Mbps. That would equal to only 12,5Mega Bits per second (KB/s)

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

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

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

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

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

jonmansey · Mon Apr 23, 2018 6:39 pm

Replying to Uldis,

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

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

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

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

Mon Apr 23, 2018 11:55 pm

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

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

My testlink runs 100Mbps UDP (real traffic) aggregated over a 10MHz Channel. MCS15 is a wifi thing ...
40MHz gives 460Mbps.

jonmansey · Tue Apr 24, 2018 5:24 am

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

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

hapi · Tue Apr 24, 2018 7:40 am

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

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

viewtopic.php?f=21&t=132181&start=100#p653489
deja vu?

hapi · Tue Apr 24, 2018 7:42 am

Replying to Uldis,

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

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

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

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

viewtopic.php?f=21&t=132181&p=656604#p653516
deja vu?

jonmansey · Tue Apr 24, 2018 7:13 pm

@hapi, I see a couple of ar7240 devices in your registration table there, the ones with 00:0C:42 Mac addresses, try blocking them with access list and see if nv2 clears up.

draguzet · Wed Apr 25, 2018 12:04 am

What is final conclusion for best practice setup after this update ?
TDMA Period: fiksed 2-3-4 ms or Auto ?
Fixed or Dynamic downlink ?

WirelessRudy · Wed Apr 25, 2018 12:10 am

What is final conclusion for best practice setup after this update ?
TDMA Period: fiksed 2-3-4 ms or Auto ?
Fixed or Dynamic downlink ?

On the networks I tested dynamic download worked best. But tdma period is still not conclusive by me. I tend to use 2ms but don't see a lot of difference between 'auto' or 1 or 2. Higher then 3 brings throughput down...

WirelessRudy · Thu Apr 26, 2018 9:06 pm

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

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

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

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

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

Would be nice if any can confirm similar or have any comments...

taduikis · Fri Apr 27, 2018 12:06 am

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

I've noticed that older gen chipsets perform poorly and also drag down whole AP a little. Also older chipsets don't support Short GI on 20MHz channels. I rotate and replace old 5nD and 5HPnD devices and upgrade to newer ones when possible. Got boxes full of waste 5nD's lying around..

0ldman · Fri Apr 27, 2018 12:36 am

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

So far auto seems to work best in my situation.

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

Nstreme and nv2 both seem to be best tuned for each location. There doesn't seem to be a "best practice" aside from tuning each location.

WirelessRudy · Fri Apr 27, 2018 2:14 am

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

I've noticed that older gen chipsets perform poorly and also drag down whole AP a little. Also older chipsets don't support Short GI on 20MHz channels. I rotate and replace old 5nD and 5HPnD devices and upgrade to newer ones when possible. Got boxes full of waste 5nD's lying around..

These SEXTANTS are indeed rb911G-5HPnd units.
There are actually 4 of these in that specific network only! And two rb911G-5HnD and two rbSXT 5HPnD and one rbSXT 5HPnD

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

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

taduikis · Fri Apr 27, 2018 9:17 am

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

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

I don’t suggest you to buy new units for existing clients. We deploy fiber to our clients so get plenty of used Lite5’s to reuse. And slowly replacing old devices with them. We also considered to replace some more quality sensitive network segments to other vendor, so that way even more Lite’s would get freed for reuse..

Ginsu · Mon Apr 30, 2018 10:32 pm

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

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

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

Congratulations for this improve, I hope you keep going with wireless implementations, this is something that you abandoned for some time.

n21roadie · Mon Apr 30, 2018 11:01 pm

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

I've noticed that older gen chipsets perform poorly and also drag down whole AP a little. Also older chipsets don't support Short GI on 20MHz channels. I rotate and replace old 5nD and 5HPnD devices and upgrade to newer ones when possible. Got boxes full of waste 5nD's lying around..

This is very interesting comment!
I just wonder when I checked a few boards that the firmware which has factory default of say 3.02 but can be updated, would this improve performance!
RB433AH - ar7100 - 2.23
711-5Hn - ar7240 - 3.02
711-5Hn-MMCX - ar7240 - 2.28
711-5Hn-u.FL - ar7240 - 2.37
911-5Hn - ar9344L - 3.22

Also where can I locate information on guard interval support for each chipset,

jonmansey · Tue May 01, 2018 4:26 am

@Uldis, so can we expect any kind of fix for this poor station performance under nv2 on ar7240 chips in a future firmware release? Or are we SOL?

WirelessRudy · Tue May 01, 2018 12:49 pm

Well, I cannot guarantee that it’ll do a lot, but at least short GI gives additional capacity by reaching higher datarates on 20MHz.

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

I’ve witnessed performance and user experience/happyness increase numerous times after replacing these 5HnD’s to Lite5, etc. I don’t know how it’s related, but even CCQs are better on newer units (where I got 60-70 with 5HnD, easily >92 on Lite5).

Could this not also be because newer chipsets have usually better sensitivity, higher CPU speed (=higher capacity to modulate and de-modulate data) and not seldom just better antenas? It's the combination of all I would think.....?

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

Well, if the newer antena has better sensitivity and better antena design automatically you get better signal and thus better S/N rates that in return give the radios the option to use higher MCS rates and thus they perform better....
I also must say in this relation that I found many radios/boards already in the field for some years that get replaced by exactly the same unit, but new, give better results too.... Like boards degrade.....

I don’t suggest you to buy new units for existing clients. We deploy fiber to our clients so get plenty of used Lite5’s to reuse. And slowly replacing old devices with them. We also considered to replace some more quality sensitive network segments to other vendor, so that way even more Lite’s would get freed for reuse..

Well, we have to compete in some parts at fiber. We just don't have the resources to start using fiber to our clients, even if it's in the street. But with Mimosa or now the new 60Ghz units of Mikrotik we'd manage to keep our clients and even gain where we lost less then 1 % to the fiber alternative. And they are fanatic in their promotions!

WirelessRudy · Tue May 01, 2018 12:52 pm

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

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

Also where can I locate information on guard interval support for each chipset,

I always upgrade the fw as well when performing ROS upgrades.... but if it helps. I tend to think it does but have no hard evidence. I also must say the issues of the poor effect of the use of these boards to P2MP networks I'd notice but not to the same extend as other wrote here..... So who knows. At least I don't think it hurts....

taduikis · Tue May 01, 2018 11:01 pm

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

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

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

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

Nevertheless, I’ll continue replacing old units whatever the reason of this performance improvement is (aging, chipset features, antenna design, etc). In my opinion MT CPEs are quite good and quality units. All we need now is some magic at AP side, which is surely possible as other vendors clearly demonstrated, even with MT CPEs..

WirelessRudy · Wed May 02, 2018 12:48 am

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

To my understanding Firmware (/sys rout ) is 'drivers'. At least that is what has been xplained to me once by some MT guy. It is needed to have all kinds of hardware working with the software. And in writing new drivers the older drivers get updated too. That always has been my understanding but correct me if I am wrong.

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

Well, If I upload a file (for instance a new upgrade ROS) to a new 720Mhz unit or to a 400Mhz device, even if they have the same conn. rate and signal, in the 720Mhz it goes way faster. And this is only a big package of data that has to be written in memory. I am not talking the actual upgrade process. (Or is ti because the newer memory is much faster?)
Also; if you run a bandwidth test 'over' and old 400Mhz device or a new 720Mhz device, the latter shows less cpu usage.
Which would make sense, the radio continuously has to make decisions on the conn. rate and choose 'up' or 'down' one, has to check the checksum of the packages so it was transported 'intact' and ask for a 'resend' if corrupted, receive and proces tdma time stamps and send/receive windows and encrypt or decrypt the data that is send over the wireless link. That's all work to be done each data frame again, over and over.

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

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

At least the CPU doesn't have to make that decision anymore. Each and every time GI is changed traffic is halted for a split (m)second. If my modulation rate is high enough for the capacity that is needed, it gives me better CCQ and thus lower latency.

Nevertheless, I’ll continue replacing old units whatever the reason of this performance improvement is (aging, chipset features, antenna design, etc). In my opinion MT CPEs are quite good and quality units. All we need now is some magic at AP side, which is surely possible as other vendors clearly demonstrated, even with MT CPEs..

I can nothing more then to fully agree on this. Apart maybe from the noise shielding* (which in my opinion is better if the transceiver would be placed in the focus of a metal sphere (like ubnt does) these little SXT's, SXT-sq's, SEXTANT's, LHG's and now the DISC's are nice little units that with its versatile ROS can be fine tuned to levels other makers can only dream of. And for a very competitive price!

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

taduikis · Wed May 02, 2018 9:09 am

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

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

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

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

Wed May 02, 2018 11:40 am

@Uldis, so can we expect any kind of fix for this poor station performance under nv2 on ar7240 chips in a future firmware release? Or are we SOL?

We are still trying to reproduce your setup and at the moment we are unable to do that - it works ok in a room setup.
Maybe you have a test site where the problem is happening then we could do dome remote debugging to understand what setup needs to be made locally to reproduce that problem?

n21roadie · Wed May 02, 2018 12:16 pm

.......................... If some 20-30mbps are passing through the device, with all management, NAT, firewall, etc CPU never gets past 50%. So to my understanding - plenty of resources left? Or this CPU utilization figure doesn’t show all the picture here?
..............................

You maybe correct and a faster CPU is simply processing quicker all the "other stuff" which is running on ROS!

HaQs · Wed May 02, 2018 12:24 pm

nv2 improvments BUG:

Hello i upgraded 300AP

to ROS 6.42.1 with this package and NV2 improvment have BUG:

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

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

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

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

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

when downgraded to 6.40.8 then problem not exist.

Ginsu · Wed May 02, 2018 2:55 pm

nv2 improvments BUG:

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

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

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

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

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

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

when downgraded to 6.40.8 then problem not exist.

I Can confirm that upgrading only the AP (That's what i do to begin testing) i can't reproduce this BUG. When i start a bandwith test or some client start a download the other clients doesn't loss any packet.
The only thing that i can reproduce is what i post before, that latency changes if the client is with traffic (better) and without heavy traffic (worst)

HaQs · Wed May 02, 2018 4:44 pm

check carefully again.

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

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

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

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

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

To the full happiness was to improve yet jitter

Thanks MT.

hapi · Sun May 06, 2018 12:48 pm

v6.43rc6

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

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

mistry7 · Sun May 06, 2018 4:07 pm

Please test latency to Sxtsq ac too......

lomayani · Sun May 06, 2018 6:07 pm

v6.43rc6

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

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

Am see poor performance too on 6.43. last version(6.42.1) is working very fine for me. Hardily getting stable 50mbps capacity on 6.43rc6.

Mon May 07, 2018 10:02 am

v6.43rc6

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

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

Am see poor performance too on 6.43. last version(6.42.1) is working very fine for me. Hardily getting stable 50mbps capacity on 6.43rc6.

Could you both share the exact setup and configurations and also how you are doing the speed tests so we could try to reproduce your problem?

lomayani · Mon May 07, 2018 10:47 am

v6.43rc6

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

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

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

I have done similar tests few minutes ago. Ap configuration is below

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

You can see for the same client hardily going to 50mbps with 6.43rc6 installed in the AP but am getting 100Mbps on the same client on 6.42.1. this AP has 32 clients connected

Mon May 07, 2018 12:10 pm

that speed test is going to one client or to all clients together?

lomayani · Mon May 07, 2018 1:07 pm

that speed test is going to one client or to all clients together?

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

the structure of setup is client radio(dynadish ac)-AP(NetMetal 5 )-rb1100-fiber link-CCR1036-12G-4S.

human1982 · Mon May 07, 2018 5:36 pm

that speed test is going to one client or to all clients together?

To 2 clients getting 80mbit 1x1 auto tdma ccq 70 and 85 so i think is`t getting better. Work on latency in overhead situation please.

ricake24 · Tue May 08, 2018 7:54 am

I use that open speed test all the time!

viesturs · Tue May 08, 2018 9:45 am

We were not able to recreate the issue locally with your written configuration with the exact devices. Would it be possible to grant remote access so we could observe the issue on your network?

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

the structure of setup is client radio(dynadish ac)-AP(NetMetal 5 )-rb1100-fiber link-CCR1036-12G-4S.

lomayani · Tue May 08, 2018 10:42 am

We were not able to recreate the issue locally with your written configuration with the exact devices. Would it be possible to grant remote access so we could observe the issue on your network?

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

the structure of setup is client radio(dynadish ac)-AP(NetMetal 5 )-rb1100-fiber link-CCR1036-12G-4S.

Send me an email. I can give teamviewer access to one of our testing virtual machine and you can access the AP and client radio.

hapi · Tue May 08, 2018 11:23 am

v6.43rc6

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

this is not funy. Add to 802.11 CSMA disable and let it go. NV2 is bad. We no longer have the quality of wireless.
Am see poor performance too on 6.43. last version(6.42.1) is working very fine for me. Hardily getting stable 50mbps capacity on 6.43rc6.
Could you both share the exact setup and configurations and also how you are doing the speed tests so we could try to reproduce your problem?

AP: mANTBox 15s

/interface wireless
set [ find default-name=wlan1 ] adaptive-noise-immunity=ap-and-client-mode band=5ghz-a/n basic-rates-a/g=54Mbps comment=5360 \
    country="czech republic" disable-running-check=yes disabled=no distance=1 frequency-mode=superchannel \
    hw-retries=15 mode=ap-bridge multicast-helper=full nv2-cell-radius=10 nv2-downlink-ratio=75 scan-list=5000-6000 \
    tdma-period-size=3 wireless-protocol=802.11 wps-mode=disabled

CPE: SXTsq 5 AC

/interface wireless
set [ find default-name=wlan1 ] band=5ghz-a/n/ac country="czech republic" \
    disable-running-check=yes disabled=no frame-lifetime=10 frequency-mode=\
    superchannel hw-retries=15 radio-name="SXTsq 5 ac" scan-list=default,full

BTEST between unit, 1 tcp connection.

n21roadie · Tue May 08, 2018 9:01 pm

AP: mANTBox 15s

/interface wireless
set [ find default-name=wlan1 ] adaptive-noise-immunity=ap-and-client-mode band=5ghz-a/n basic-rates-a/g=54Mbps comment=5360 \
    country="czech republic" disable-running-check=yes disabled=no distance=1 frequency-mode=superchannel \
    hw-retries=15 mode=ap-bridge multicast-helper=full nv2-cell-radius=10 nv2-downlink-ratio=75 scan-list=5000-6000 \
    tdma-period-size=3 wireless-protocol=802.11 wps-mode=disabled

CPE: SXTsq 5 AC

/interface wireless
set [ find default-name=wlan1 ] band=5ghz-a/n/ac country="czech republic" \
    disable-running-check=yes disabled=no frame-lifetime=10 frequency-mode=\
    superchannel hw-retries=15 radio-name="SXTsq 5 ac" scan-list=default,full

BTEST between unit, 1 tcp connection.

Just curious why you have set the scan-list=5000-6000 as this results in the AP to listen to all frequencies between 5-6GHz - we when using 20Mhz channels set our AP's -/+ 20Mhz above and below the AP frequency, so for AP freq=5360 scan-list=5340-5480, just to add further we also set hw-retries=5, multicast-helper=disabled, band=5ghz-onlyn,

HT MCS supported and basic have equal setting, we are perhaps over conservative at present on this ! but would rather have a slower more stable connection to the CPE's than data rates varing on very regular basis which customers have complained about?

WirelessRudy · Tue May 08, 2018 10:29 pm

Just curious why you have set the scan-list=5000-6000 as this results in the AP to listen to all frequencies between 5-6GHz - we when using 20Mhz channels set our AP's -/+ 20Mhz above and below the AP frequency, so for AP freq=5360 scan-list=5340-5480, just to add further we also set hw-retries=5, multicast-helper=disabled, band=5ghz-onlyn,

We set the scan-list in the band we work. Like 5450-5750 so the scan 'sees' al available 'low noise' areas as well other AP's close to our working frequency. we do this since we'd pretty regurlarly need to swap working frequency if yet again somebody decided to work on ours......

Since 6.41.xx the scan seems to be slower, and if we set a scan time higher then 59 seconds it comes back in terminal to disappear before we could even read some of it. Secondly, setting it to anything less doesn't give us the whole range in scan anymore. I have to sort of cut it 'in two' (twice a scan, both with a part of the range in the scan-list). This performance was much better in 6.40.x and before. Very irritating, the more since we already lost the spectral scan/history in the 'ac' units.
While spectrum scanning becomes more and more important the tool itself works worse every new ROS family...

HT MCS supported and basic have equal setting, we are perhaps over conservative at present on this ! but would rather have a slower more stable connection to the CPE's than data rates varing on very regular basis which customers have complained about?

Conn. rate settings; good mentioning. I only set one, low (6 or 12Mbps) basic rate and then one supported rate that would give me a 'subribers' speed if only one stream connects and then 2 or 3 MCS rates that will give me at least the client's subscribers speeds and 1 or 2 higher. (In 'subscribers speed' I mean that if a client has a 25Mbps contract het at least needs mcs 11 to get it happening, or mcs 5 for the single chain.)

networkfudge · Tue May 08, 2018 10:34 pm

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

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

Redmor · Tue May 08, 2018 11:54 pm

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

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

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

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

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

Would be nice if any can confirm similar or have any comments...

Improvements can be seen with 10+ CPEs.
As MK support said to me in a support e-mail, with these "improvements" CPEs with lower signals don't slower other CPEs.
I haven't fully tested improvements and I can't say what are these improvements, but I can tell you that CPEs throughput has been increased after I've updated to 6.42.1, and I'm updating all my APs.
I didn't do 10+ bandwidth tests, but on CPEs that had 2Mbps DL, after 6.42.1 they've reached 10+Mbps, without changing settings or frequencies.

Redmor · Tue May 08, 2018 11:57 pm

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

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

Scan list for APs is used only to scan for frequencies usage/noise etc.
If you set a non-default frequency on AP with default scan list, clients connect.

n21roadie · Tue May 08, 2018 11:57 pm

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

Just curious why you have set the scan-list=5000-6000 as this results in the AP to listen to all frequencies between 5-6GHz - we when using 20Mhz channels set our AP's -/+ 20Mhz above and below the AP frequency, so for AP freq=5360 scan-list=5340-5480, just to add further we also set hw-retries=5, multicast-helper=disabled, band=5ghz-onlyn,
[/quote]
[/quote]
After a reboot we have noticed a much faster clients wireless registration when scan list it reduced, if it's set to Default or in the above example it will take longer.

networkfudge · Wed May 09, 2018 12:08 am

Narrowing the scan-list on the CPE will reproduce what you are describing, on the AP it shouldn't have any effect whatsoever.

After a reboot we have noticed a much faster clients wireless registration when scan list it reduced, if it's set to Default or in the above example it will take longer.

WirelessRudy · Wed May 09, 2018 12:45 am

Narrowing the scan-list on the CPE will reproduce what you are describing, on the AP it shouldn't have any effect whatsoever.
After a reboot we have noticed a much faster clients wireless registration when scan list it reduced, if it's set to Default or in the above example it will take longer.

That's my experience too. If you set the scan-list on the CPE to the working frequency a client re-connects pretty fast after any kind of edit in the config. Long enough to have the winbox session not break (not if all 40 clients of an AP disconnected, then some stay alive, some still take too long to re-connect. But that is more due NV2 timing/slots)

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

Setting scan-list parameters in Mikrotik AP has no effects as far as I am aware. (We only set it to make a quick scan at time to 'see' if we don't have other AP's hammering our working frequency.)

WirelessRudy · Wed May 09, 2018 12:52 am

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

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

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

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

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

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

It is very erratic. Yesterday I 'fought' with a 3 (!) client AP and the 6.42.1 NV2 is crap.... set it to 802.11 and everything works twice as fast and more consistent.
I have some 30+ AP's that I tested with 6.42.1 and yes, I did see improvement and no dragging down a whole network by one poor client. (Test done with 5 clients while the rest of the clients were still 'online')
But I also have some 30+ AP's where the opposite happened. Crappy speeds, very irregular and yes, a poor client drags the whole network down.

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

lomayani · Wed May 09, 2018 9:34 am

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

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

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

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

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

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

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

Am not seeing this issue on my network over 50+ APs in 6.42.1. For clients running AC am getting up to 100Mbps under 20Mhz channel. I found tdma period size=auto give few more Mbps than 3msec or 2msec size . I had few issue with few APs being slow. After long troubleshooting I came to realize that noise has big impact. I decided to set adaptive-noise-immunity=ap-and-client-mode and fixed my issue on those APs

viesturs · Wed May 09, 2018 2:12 pm

You wrote that you have to test each AP separate, because the in different sectors the performance may differ. How you observed any patterns or AP/CPE combinations on which the issue repeats more often? This would give us valuable info to work with and improve the performance and stability.

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

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

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

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

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

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

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

WirelessRudy · Wed May 09, 2018 2:59 pm

You wrote that you have to test each AP separate, because the in different sectors the performance may differ. How you observed any patterns or AP/CPE combinations on which the issue repeats more often? This would give us valuable info to work with and improve the performance and stability.

Well, to be honest I'd lack the time to invest this all. I have 40 or so AP's but each AP has a lot of variables to work with:
- full 'n' network or 'ac'
- NV2 network or 802.11
- v.6.40.3 or 6.41.1 or newer
- some networks all clients have better then -55dB signal, others have clients up to -70dB. Make a big difference
- some clients have been given new 'arm' devices to work with 'ac' and with its high capacity CPU (Since we try to get signals close or better, then -50dB we are replacing a lot of 'n'-SXT's for the new DISC's or LHG-5ac's). We do PPoE on the antena but found that any ROS lower then 6.41.x is not supporting PPPoE. So networks with 'arm' devices are not the same as networks where we don't have such devices running yet....

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

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

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

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

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

I always thought too one setting would serve all P2MP networks but to my horror I'd see now huge differences in performance with the same settings depending on the actual networks....

taduikis · Thu May 10, 2018 12:36 am

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

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

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

Some other observations and suggestions from my side:

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

What majority of us want here is simply more throughput per user (to meet ever-growing user traffic demand) and more total sector capacity and for all it to work stable. We already know it can be done. Because it has been done. Unfortunately not where we want.

taduikis · Thu May 10, 2018 1:34 am

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

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

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

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

Yes, that in fact would be nice. But you wouldn't need to specify anything for it to work. For this you need some clever and sophisticated circuitry that can adapt the filter according to set frequency and cancel out everything outside your selected frequency+channel width. This indeed gives quite a lot of improvement on link quality, especially on heavily co-located towers as it raises SNR on uplink. But it's highly unlikely we'll see this on some RouterBoard anytime soon, since RBs are built from off-shelf parts and this filtering technology isn't what's easily available on the market, everyone holds a grip on it heavily. What MT actually could do is to update their rate-selection algorithm to support asymmetric downlink/uplink rates to allow lower modulations to be used for uplink to APs, while allowing higher ones for downlink. This is done and recommended even on other vendor equipment that does have the neighbor channel filtering.

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

draguzet · Thu May 10, 2018 10:33 am

Thumb up for that review...we are WISP and working only on NV2, as the post above says, logically that NV2 has to give the best results, so please MT let us know the recommendations of the settings as described below:

Some other observations and suggestions from my side:

if it's key point here - don't bother trying to make nv2 perform on obsolete equipment with very old chipsets;

clearly give suggestions on how to tune up our networks (hardware and software wise):

which ROS versions to use on AP and CPE;

which boards work the best on AP side (for example does later generation AC boards work better or the difference is negligible);

which protocols to set for single/mixed mode setups (N/AC);

do we need some specific NV2 settings: period-size, d/u ratio, etc;

you can actually post detailed scenarios and configs you've tested and achieved good performance. For example RB921 as AP, Lite5ac's as clients, so we could compare these setups and perhaps consider replacing few remaining old equipment to gain considerable boost in throughput;

WirelessRudy · Thu May 10, 2018 11:33 am

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

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

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

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

I can only hope these remarks, comments and criticisms make Mikrotik works harder/invest more in their wireless/NV2 developments. Because as other vendors proved, a good performing tdma network can do much better then we see now with Mikrotik.

taduikis · Thu May 10, 2018 2:15 pm

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

By the way, are there any evident advantages of using AC boards on NV2 APs when clients are 11n or mixed n/ac?