Significant improvement for wireless Nv2 PtMP

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?

mkx · Thu May 10, 2018 5:46 pm

Even some LTE networks use TDD based TDMA.

Which LTE networks?

Please bear in mind that OFDMA as used in LTE is partly TDMA (probably OFDMA in 802.11ac as well, I don't know the details). Partly in a sense that block of orthogonal frequencies is assigned to single client device at a time and assignment is done in regular intervals (in LTE interval length is 1 ms) thus same frequency block can be assigned to different client devices at different times.
The big difference between "proper" TDMA systems and OFDMA is that in TDMA all resources (if this was OFDM, then whole set of orthogonal frequencies spanning while carrier) is assigned to single client device while in OFDMA many client devices can get assigned part of orthogonal frequencies at the same time (of course one block can be assigned to single device). Surely if number of devices needing air-time is low, then it can happen that single client device gets assigned resources in certain time interval thus OFDMA can really look like TDMA.
In uplink LTE uses slightly different technology, called SC-OFDMA .. SC meaning Single Carrier, where each client device gets assigned contigous block of frequencies while in "straight" OFDMA, assigned blocks of frequencies can be sparsely distributed across whole carrier.
.

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.

This describes very badly designed TDMA. The last time such TDMA was used in mobile networks, was in GSM/PCS for voice calls - so called circuit-switched services (including 9.6kbps/14.4kbps data transfer modes). GPRS/EDGE works on top of TDMA but it doesn't really reserve so much air-time for inactive users. There's state transition (idle/dedicated) happening with idle timeout with magnitude of 1 second. When client is idle, no resources are reserved for it and when data transfer is about to resume, special signalling procedure takes place (and time

). When client is in dedicated mode, then resources are indeed reserved for it (but dynamically).

I have hard time to believe that NV2 would be implemented in GSM way (and not in GPRS way).

WirelessRudy · Thu May 10, 2018 6:01 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?

Because TDMA is used by most main stream vendors doesn't inherently mean it is the best. Many of us know the history of the video standard used by Betamax versus VHS versus V2000 (Philips) of the last century. The most popular system wins, not the best.
There are vendors using 5Ghz wifi systems that use 10Mhz wide (!) channels ans still seem to be able to deliver 30Mbps to clients in an area where I with my Mikrotik netmetals in a 20Mhz won't be able to do the same..... no matter what protocol I'd use. I am not fully aware how they do it, but they do....

Usually the advantage of 'ac' radio's over'n' radios are;
- Two 'ac' AP radio's can share the same 80Mhz (or 160Mhz) band if there s/n difference at each other is 25/30dB and both use the 'pilot' band different as the other. For instance one AP has the upper channel as its 'pilot' channel whereas the other uses the lower. (Like one AP has eeeC and the other has Ceee but both have the same 80Mhz range.
Clients that can pick up both signals can work without interference. If the full 80Mhz signal has enough s/n ratio both CPE and AP work in the full band. If the CPE notices in the designated band the 'not to be associated to' AP interferes for that CPE only the 40Mhz part of the channel will be used that is the pilot on its 'to be associated' AP.
Basically it means that two 80Mhz channel working AP's that have different 'pilot' channel don't interfere with each other at the expense of switching back to a 40Mhz channel, only for that CPE!
It's a sort of interference avoiding capability that comes with 802.11ac (and I believe doesn't work in 40Mhz wide channels)

- Apart from that, 'ac' chipsets are 1 to 2dB more powerful then its 'n' counterparts. See the specs of MT radios. (An SXT-5Lite has 22dBm at MCS7 where the SXT-5acLite has 25dBm. An Omnitik has 26dBm at MCS7 but the Omnitik-ac has 27dBm.

- Newer chipsets (like the 'ac' chipset) usually also have better sensitivity and thus need less signal to get to the same modulation rate. (The MCS7 for the Omnitik-ac works already with -77dBm where the Omnitik-n needs -75dBm.)

- The CPU that comes with 'ac' devices is usually also much faster, so more power under the hood! (650Mhz versus 600/400Mhz for the SXT or 720Mhz versus 600Mhz for the Omnitiks.

- 'ac' radios that have good enough signal have two extra (256QAM) modulations available and can thus get higher speeds, which in a busy network means faster dealing with clients. (So the capacity of the AP increases since traffic to that 'ac' client gets send or received faster.)

mkx · Thu May 10, 2018 6:23 pm

- Apart from that, 'ac' chipsets are 1 to 2dB more powerful then its 'n' counterparts. See the specs of MT radios. (An SXT-5Lite has 22dBm at MCS7 where the SXT-5acLite has 25dBm. An Omnitik has 26dBm at MCS7 but the Omnitik-ac has 27dBm.

- Newer chipsets (like the 'ac' chipset) usually also have better sensitivity and thus need less signal to get to the same modulation rate. (The MCS7 for the Omnitik-ac works already with -77dBm where the Omnitik-n needs -75dBm.)

.
You need to keep in mind, that 'n' uses frequency channels wide up to 40MHz while 'ac' uses up to 160MHz wide channels. Meaning that TX power is dispersed over 6 dB wider frequency band and if total TX power was the same, ratio Watt-per-Hertz would be 6dB lower for wide-band 'ac'. Higher TX power and better RX sensitivity of 'ac' combined give 3dB gain over 'n' ... when using same frequency band-width (e.g. 40MHz). When using maximum supported 'ac' frequency bandwidth then whole path budget is still 3 dB lower in 'ac' so perhaps it'll occasionally use lower MCS than 'n' would have ... but still benefit because of using so much wider frequency band.

WirelessRudy · Thu May 10, 2018 7:56 pm

- Apart from that, 'ac' chipsets are 1 to 2dB more powerful then its 'n' counterparts. See the specs of MT radios. (An SXT-5Lite has 22dBm at MCS7 where the SXT-5acLite has 25dBm. An Omnitik has 26dBm at MCS7 but the Omnitik-ac has 27dBm.

- Newer chipsets (like the 'ac' chipset) usually also have better sensitivity and thus need less signal to get to the same modulation rate. (The MCS7 for the Omnitik-ac works already with -77dBm where the Omnitik-n needs -75dBm.)
.
You need to keep in mind, that 'n' uses frequency channels wide up to 40MHz while 'ac' uses up to 160MHz wide channels. Meaning that TX power is dispersed over 6 dB wider frequency band and if total TX power was the same, ratio Watt-per-Hertz would be 6dB lower for wide-band 'ac'. Higher TX power and better RX sensitivity of 'ac' combined give 3dB gain over 'n' ... when using same frequency band-width (e.g. 40MHz). When using maximum supported 'ac' frequency bandwidth then whole path budget is still 3 dB lower in 'ac' so perhaps it'll occasionally use lower MCS than 'n' would have ... but still benefit because of using so much wider frequency band.

True. But important! Just by changing our normal OmniTiks into the new Omnitik 'ac's and also replacing SXT's by the SXT-ac's we gained 3-4dB per client in the same channel and same bandwidth. This improvement of +/-3dB (double de signal!) gained just because of that one or two mcs rates! The average capacity of the P2MP network increased just by the replacements only!
Now this network still runs in 'n' mode since not all clients are changed yet, but when the last one is done we will switch to full 'ac' and see what we get then....

)

mkx · Thu May 10, 2018 11:02 pm

@WirelessRudy: indeed if you only replace equipment and keep the wireless parameters the same, you get better performance. What I was trying to show is that it's only normal that 'ac' has better performance because that's simply necessary for 'ac' modus operandi. Without it, 'ac' performance would be less than great.

n21roadie · Fri May 11, 2018 12:10 am

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

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.

I would add to this list but no sure its important or required but TDMA is Time-division multiple access, we have set all our CPE's and AP's in fact every router to sync to NTP pools,
this for accurate time on logs and maybe this has helped our AP's and CPE's !

Also does ROS with all it's **extra's** built in, result in "Bloatware" for wireless but OK for non wireless functions ?

WirelessRudy · Fri May 11, 2018 12:32 am

I would add to this list but no sure its important or required but TDMA is Time-division multiple access, we have set all our CPE's and AP's in fact every router to sync to NTP pools,
this for accurate time on logs and maybe this has helped our AP's and CPE's

Imho: No, it doesn't mean anything to the TDMA protocol.
In TDMA the AP divides the available time for sending and receiving for each station in an timely 'order' by giving each device a 'time slot'. 'One by one' to say so. This can be deviated into upload and download slots and devices that need to send more data get more slots then other that don't.
But the order and length is depicted by the AP to the station in the dataframe that it sends to the station. Eacht time the AP 'runs' the cycle among its associated clients its tell them it's time "0" again and when it's each specific stations time to act. That is in fact completely independent to the actual clock.

The fact the ROS clock's are syncd yes or not with a NTP server has no influence on the working of the TDMA. (As I'd understand well. Correct me if I am wrong)

Some vendors though use GPS to sync the TDMA in each associated station to get a better sync of the TDMA. This because during each cycle of the AP's P2MP network clocks of each associated device can already run out of sync with each other. The GPS clock timing now makes sure that the clocks are much more precise then what the build in software clock of ROS can achieve. But this is usually not seen in typical CPE devices or it must be some high end vendors. It is used on backhaul devices like Mimosa B5's, AirFibers and probably other vendor's hardware.
And when this GPS sync is there to sync the link, it can also be used to sync several devices on the same tower. But still one device needs to tell all others that take part in that specific syncronized clock when it's hour "0"
But MT doesn't use this way of sync so setting the clock's to NTP only serve to get syncd log over your devices.
(Yet again, please correct me if I am wrong but that is what my understanding is.)

draguzet · Fri May 11, 2018 12:37 am

What with NV2 sync ?
Is someone use in production NV2 sync (master-slave) and reuse same frequency on "behind" sectors on the same tower ?
Are this function work OK or not ?

WirelessRudy · Fri May 11, 2018 1:18 am

What with NV2 sync ?
Is someone use in production NV2 sync (master-slave) and reuse same frequency on "behind" sectors on the same tower ?
Are this function work OK or not ?

We tried it, as well as others. Unless you have full 100% isolation for participating AP's it doesn't. So far haven't heard hard evidence from anyone that it really worked for them....

Redmor · Fri May 11, 2018 11:02 am

What with NV2 sync ?
Is someone use in production NV2 sync (master-slave) and reuse same frequency on "behind" sectors on the same tower ?
Are this function work OK or not ?

As I stated before, if a client sees two or more AP in sync, it will go bad.
I have some clients that can see 4 of them because they're 300 meters far.
Nv2 sync should be made on a RB in my opinion, not on an AP.

taduikis · Fri May 11, 2018 11:14 am

You mean clients of Sector A should not see clients of Sector B?
If so, that's fair enough. And it's achievable with quality antennas with good F/B ratios. But sync is advantageous only on ABAB or ABCD setups.
I wonder how MT sync implementation compares with GPS based syncing..

What with NV2 sync ?
Is someone use in production NV2 sync (master-slave) and reuse same frequency on "behind" sectors on the same tower ?
Are this function work OK or not ?
We tried it, as well as others. Unless you have full 100% isolation for participating AP's it doesn't. So far haven't heard hard evidence from anyone that it really worked for them....

Redmor · Fri May 11, 2018 11:44 am

You mean clients of Sector A should not see clients of Sector B?
If so, that's fair enough. And it's achievable with quality antennas with good F/B ratios. But sync is advantageous only on ABAB or ABCD setups.
I wonder how MT sync implementation compares with GPS based syncing..

What with NV2 sync ?
Is someone use in production NV2 sync (master-slave) and reuse same frequency on "behind" sectors on the same tower ?
Are this function work OK or not ?
We tried it, as well as others. Unless you have full 100% isolation for participating AP's it doesn't. So far haven't heard hard evidence from anyone that it really worked for them....

In setup AAAA or AABB if a client sees both A the throughtput is really low.
You can use ABAB for sync, with first A covering from 0° to 90°, first B 90° to 180°, second A 180° to 270° and the last 270° to 360°.
In that case sync should work with no problem, if you don't have -30 tx to a client.
I don't know if ABCD on two towers would be useful.

WirelessRudy · Fri May 11, 2018 12:27 pm

You mean clients of Sector A should not see clients of Sector B?
If so, that's fair enough. And it's achievable with quality antennas with good F/B ratios. But sync is advantageous only on ABAB or ABCD setups.

Only then it works. But in that case non syncd networks also works.....
The sync makes only sense if AP's that work in the same proximity where their CPE's can 'hear' both work in sync. As long as the CPE's then have sufficient signal difference between the two AP's both AP's can work with same frequency and client only associate with the strongest without beeing hammered by the other.
This works with our Mimosa setup. The only thing you have to be aware of is that CPE's that 'see' AP-A are not picking up signal from AP-B at almost the same strength. Then it doesn't work.

We have two Omni directional (4 single chain sectors) only some 200 meters apart with close proximity (<250 meters) clients that both work in a syncd. environment with a 80Mhz wide channel. Both AP's have the same frequency but different SSID. On the clients we set the SSID to associate to and make sure the working beam of the CPE antenna is not 'seeing' the other AP. If it does the link collapse.
The Mimosa CPE's are shielded, have power control from the AP and the AP in its turn has a signal level cut-off.
Meaning that if all CPE's of AP-A connect with -40 to -55 dB range where these same CPE's would show a signal level at the AP-B of -60 or worse, we set the working signal range of the AP-B to -60dB and all signals that 'hit' AP-B with -60 or less are filtered out. Off course on AP-A we do the same so it filters out all stations that come in with -60 or less signal.
That system works fine and I have no problems to deliver 200Mbps or more tcp traffic to clients.
We also have a third Omni directional AP working in the same 80Mhz band but the 'pilot' channel is on the other side of the band as AP-A and B. Because several CPE's will see either A, B or C no matter what we do. (All CPE's are in a 300 meter radius). By changing the pilot channel the 'ac' protocol take care of possible interference between the signals of different AP's and will start using only that 40Mhz signal of the designated AP while the 40Mhz of the 'interfering AP' will be omitted. Off course instead of 80Mhz we now only have a 40Mhz channel but with the high MCS rates we still have PHY rate of 300 to 450Mbps which is good enough to deliver 150Mbps peak speeds to our clients..
And to be honest, most of our CPE's have PHY rate well over this....

With two Mikrotik Netmetals that are on a tower with both good (not the best!) f/b ratio sectors working in opposite directions while both their clients are hundreds of meters away (minimal!) on the lower plains from the small hill that has the tower (so the clients of AP-A have no way of 'seeing' in a LOS or even NLOS the sector of AP-B and vice versa) the CCQ's dropped on all clients and with it the throughput. It just doesn't work. The test is done twice on two different towers and both saw no improvement at best.
(Probably because 100% f/b ratio separation doesn't exist. Even with RF-Element cone antennas opposite radio's on the same tower 'see' each other. The signal might be well less than AP's clients, but still. And one way or another, the MT sync still has flaws..)

I think the theory behind MT's sync might look promising, at least is did for us. But in reality we can't get it to work and I've seen similar experiences from others too. MT has some work to do here...

Fri May 11, 2018 2:16 pm

You mean clients of Sector A should not see clients of Sector B?
If so, that's fair enough. And it's achievable with quality antennas with good F/B ratios. But sync is advantageous only on ABAB or ABCD setups.
Only then it works. But in that case non syncd networks also works.....
The sync makes only sense if AP's that work in the same proximity where their CPE's can 'hear' both work in sync. As long as the CPE's then have sufficient signal difference between the two AP's both AP's can work with same frequency and client only associate with the strongest without beeing hammered by the other.
This works with our Mimosa setup. The only thing you have to be aware of is that CPE's that 'see' AP-A are not picking up signal from AP-B at almost the same strength. Then it doesn't work.

We have two Omni directional (4 single chain sectors) only some 200 meters apart with close proximity (<250 meters) clients that both work in a syncd. environment with a 80Mhz wide channel. Both AP's have the same frequency but different SSID. On the clients we set the SSID to associate to and make sure the working beam of the CPE antenna is not 'seeing' the other AP. If it does the link collapse.
The Mimosa CPE's are shielded, have power control from the AP and the AP in its turn has a signal level cut-off.
Meaning that if all CPE's of AP-A connect with -40 to -55 dB range where these same CPE's would show a signal level at the AP-B of -60 or worse, we set the working signal range of the AP-B to -60dB and all signals that 'hit' AP-B with -60 or less are filtered out. Off course on AP-A we do the same so it filters out all stations that come in with -60 or less signal.
That system works fine and I have no problems to deliver 200Mbps or more tcp traffic to clients.
We also have a third Omni directional AP working in the same 80Mhz band but the 'pilot' channel is on the other side of the band as AP-A and B. Because several CPE's will see either A, B or C no matter what we do. (All CPE's are in a 300 meter radius). By changing the pilot channel the 'ac' protocol take care of possible interference between the signals of different AP's and will start using only that 40Mhz signal of the designated AP while the 40Mhz of the 'interfering AP' will be omitted. Off course instead of 80Mhz we now only have a 40Mhz channel but with the high MCS rates we still have PHY rate of 300 to 450Mbps which is good enough to deliver 150Mbps peak speeds to our clients..
And to be honest, most of our CPE's have PHY rate well over this....

With two Mikrotik Netmetals that are on a tower with both good (not the best!) f/b ratio sectors working in opposite directions while both their clients are hundreds of meters away (minimal!) on the lower plains from the small hill that has the tower (so the clients of AP-A have no way of 'seeing' in a LOS or even NLOS the sector of AP-B and vice versa) the CCQ's dropped on all clients and with it the throughput. It just doesn't work. The test is done twice on two different towers and both saw no improvement at best.
(Probably because 100% f/b ratio separation doesn't exist. Even with RF-Element cone antennas opposite radio's on the same tower 'see' each other. The signal might be well less than AP's clients, but still. And one way or another, the MT sync still has flaws..)

I think the theory behind MT's sync might look promising, at least is did for us. But in reality we can't get it to work and I've seen similar experiences from others too. MT has some work to do here...

Sync also makes sense where APs hear each other in the same band. As APs are placed high it is very likely your APs hear each other even not beeing on the same tower. And they interfere even with some MHz between the used channels. So GPS-sync is a must have for wisps in 2018. It is available. It works. Why use gear which cant do it. MT needs to do it or WISPs shop elsewhere. Non wisps might live with it as they dont suffer from selfinterference.

taduikis · Fri May 11, 2018 3:00 pm

Well, almost all MT boards suitable for APs have USB port. And ROS have GPS package as I remember. Does this mean it's possible to take advantage of that?
MT: Update NV2 to support GPS sync and sell USB GPS modules. Additional profit.

You mean clients of Sector A should not see clients of Sector B?
If so, that's fair enough. And it's achievable with quality antennas with good F/B ratios. But sync is advantageous only on ABAB or ABCD setups.
Only then it works. But in that case non syncd networks also works.....
The sync makes only sense if AP's that work in the same proximity where their CPE's can 'hear' both work in sync. As long as the CPE's then have sufficient signal difference between the two AP's both AP's can work with same frequency and client only associate with the strongest without beeing hammered by the other.
This works with our Mimosa setup. The only thing you have to be aware of is that CPE's that 'see' AP-A are not picking up signal from AP-B at almost the same strength. Then it doesn't work.

We have two Omni directional (4 single chain sectors) only some 200 meters apart with close proximity (<250 meters) clients that both work in a syncd. environment with a 80Mhz wide channel. Both AP's have the same frequency but different SSID. On the clients we set the SSID to associate to and make sure the working beam of the CPE antenna is not 'seeing' the other AP. If it does the link collapse.
The Mimosa CPE's are shielded, have power control from the AP and the AP in its turn has a signal level cut-off.
Meaning that if all CPE's of AP-A connect with -40 to -55 dB range where these same CPE's would show a signal level at the AP-B of -60 or worse, we set the working signal range of the AP-B to -60dB and all signals that 'hit' AP-B with -60 or less are filtered out. Off course on AP-A we do the same so it filters out all stations that come in with -60 or less signal.
That system works fine and I have no problems to deliver 200Mbps or more tcp traffic to clients.
We also have a third Omni directional AP working in the same 80Mhz band but the 'pilot' channel is on the other side of the band as AP-A and B. Because several CPE's will see either A, B or C no matter what we do. (All CPE's are in a 300 meter radius). By changing the pilot channel the 'ac' protocol take care of possible interference between the signals of different AP's and will start using only that 40Mhz signal of the designated AP while the 40Mhz of the 'interfering AP' will be omitted. Off course instead of 80Mhz we now only have a 40Mhz channel but with the high MCS rates we still have PHY rate of 300 to 450Mbps which is good enough to deliver 150Mbps peak speeds to our clients..
And to be honest, most of our CPE's have PHY rate well over this....

With two Mikrotik Netmetals that are on a tower with both good (not the best!) f/b ratio sectors working in opposite directions while both their clients are hundreds of meters away (minimal!) on the lower plains from the small hill that has the tower (so the clients of AP-A have no way of 'seeing' in a LOS or even NLOS the sector of AP-B and vice versa) the CCQ's dropped on all clients and with it the throughput. It just doesn't work. The test is done twice on two different towers and both saw no improvement at best.
(Probably because 100% f/b ratio separation doesn't exist. Even with RF-Element cone antennas opposite radio's on the same tower 'see' each other. The signal might be well less than AP's clients, but still. And one way or another, the MT sync still has flaws..)

I think the theory behind MT's sync might look promising, at least is did for us. But in reality we can't get it to work and I've seen similar experiences from others too. MT has some work to do here...
Sync also makes sense where APs hear each other in the same band. As APs are placed high it is very likely your APs hear each other even not beeing on the same tower. And they interfere even with some MHz between the used channels. So GPS-sync is a must have for wisps in 2018. It is available. It works. Why use gear which cant do it. MT needs to do it or WISPs shop elsewhere. Non wisps might live with it as they dont suffer from selfinterference.

hapi · Fri May 11, 2018 3:25 pm

Keep a Topic. I do not care about GPS. Currently NV2 itself does not work properly. NV2 needs to be addressed in particular.

WirelessRudy · Fri May 11, 2018 5:30 pm

Keep a Topic. I do not care about GPS. Currently NV2 itself does not work properly. NV2 needs to be addressed in particular.

Right.. and True"

n21roadie · Fri May 11, 2018 5:54 pm

I would like to test a "barebones" version of ROS as I am beginning to think that its the amount of software used on ROS maybe part of the reason why NV2 is not the best wireless protocol currently available.

hapi · Fri May 11, 2018 5:59 pm

Of course he is not. Watch.

2x2 AC 20MHz. Btest 1 TCP. For Mikrotik is impossible. 145Mbit in 1 TCP !!

Only MCS 8 !!

sefirot127 · Thu May 17, 2018 12:05 pm

Hi, first of all I'm sorry that my English is not very good

I have updated to version 6.42.1 around 20 APs and since I updated them there are clients that disconnect and stay reconnecting
Some take minutes to connect and others have taken hours
This did not happen to me before.

In all my APs the clients are connected to less than 1Km and always with direct vision.
Coverages are between -50 and -60
The signal to noise is in all customers over 60
The Aps has between 10 and 20 clients
Security is active

The Nv2 configurations are like this:
tdma-period-size = auto
cell-radius = 30
Mode = Dynamic downlink

Should I change some configuration?

I hope you can help me

WirelessRudy · Thu May 17, 2018 7:14 pm

Hi, first of all I'm sorry that my English is not very good

I have updated to version 6.42.1 around 20 APs and since I updated them there are clients that disconnect and stay reconnecting
Some take minutes to connect and others have taken hours
This did not happen to me before.

In all my APs the clients are connected to less than 1Km and always with direct vision.
Coverages are between -50 and -60
The signal to noise is in all customers over 60
The Aps has between 10 and 20 clients
Security is active

The Nv2 configurations are like this:
tdma-period-size = auto
cell-radius = 30
Mode = Dynamic downlink

Should I change some configuration?

I hope you can help me

If all your clients are less then 1km away I would start to set cell-radius to 10 (=smallest). That will already improve latency.

We have found now on several AP's that in fact the new NV2 is much worse then plain 802.11 or nstreme. That was never the case but we are already in the process of changing (it needs to prepare the clients since they are all configured for NV2 only)
With 802.11/nstreme we more then double the client AND AP throughput in several P2MP networks. But not all though.... and so far we cannot put our finger on the issue.......

All we know that the introduction of NV2 PtMP improvement is not only bringing improvements. Sometime yes, sometimes definitely no....

jonmansey · Thu May 17, 2018 8:47 pm

Have you eliminated all the ar7240 stations and still having problems? that was the cause of the new nv2 instability for me.

framer99 · Sun May 20, 2018 9:14 pm

I have a 23km PtP link with netmetal5's i am using to play with A/N/AC/"only" and NV2 settings today. I stay connected to both ends of the hop when the link is down, so I can trying everything possible. I updated both ends to the latest RC routeros and firmware before i started (6.43rc14)

I'm leaving a UDP send-only Btest running on the side that is the "internet", and a ping test from the remote end, with 500ms timeout setting to watch the effects on latency. I saw a good youtube video where someone did this comparing NV2 802.11 etc.

So far.... 1ms NV2 period size will usually not even connect, it does seem to be related to the fixed/dynamic download mode and % setting when I do get it to connect at 1ms.

Anyway, I am still in the beginning of my testing but I did notice something odd and very repeatable:

2ms TDMA Period size, with fixed downlink with 80% causes every other ping to be high latency. I saw this in "Auto" TDMA Period size as well.... apparently when the auto selected size is 2ms?

http://imgur.com/tLhgte9

If i change fixed downlink % to 75, or TDMA Period Size to 3ms or higher, then it's all smooth and stable latency of pings.

It's not a big deal, but maybe it's why some people see 75% as the best setting vs some preferring 80%

WirelessRudy · Mon May 21, 2018 7:06 pm

Have you eliminated all the ar7240 stations and still having problems? that was the cause of the new nv2 instability for me.

I have tested it now on 4-5 P2MP networks. One Omnitk-5ac that has only 3 SXT's (2 x rb sXT 5nD r2 and one rb DISCG-5acD), so all relative 'new' devices and still the difference between 802.11/nstreme is considerable. NV2 to nstreme is almost double the speeds for the latter....

sefirot127 · Wed May 23, 2018 11:29 am

I tried to change cell radius to 10km and I still have reconnections, the only thing I can say is that in version 6.40.8 bugfix this does not happen.

The overall capacity has increased a bit but the reconnections take too long and I'll have to go back to version 6.40.8.

Has anyone had the same problem and been able to fix it?

Raumaster · Wed May 23, 2018 3:35 pm

I've been testing 6.42.1 for a while now in all of my Sectors with Basebox 5 and SXT SA5, all clients are SXT lite5 and sq and the results are a bit better then before when throughput is the only thing in mind, but ping times are not good and jitter seems to be even worse then before ping times go all over the place even if the traffic on the sector AP is very low. And for the first time after years using Mikrotik and NV2 and hearing lots of people saying nstream is bad for ptmp, that's not what I saw after 10 hours I changed one sector to Nstream. I also changed another sector to 802.11 and everything seems to be better, througput, ping times are consistent and very low! I've always used NV2, but now seeing the results of the other protocols... The only thing I think I might mis is if I get one client with bad signal ruinning the whole sector...

One other thing I notice on two sectors, when I remove the clients bandwidth control so I can make an Internal bandwitdth test to them, If i set the test to udp, when the throughput reaches the maximum speed, all the other clients starts dropping its pppoe session as if one client only overloads the AP and none of the others can pass any data.

WirelessRudy · Wed May 23, 2018 6:04 pm

So we now have several users that confirm indeed NV2 has issues and in several occasions 802.11 or nstreme actually works better....

Last night spend two hours to read the 6.43.rc changelog and related forum tread and after several version it seems some changes (they call it 'improvements') are made. So we actually should test them.
But after several bad experiences in the past with rc version on production networks I am a bit hesitating to do so.
Also new rc's are still been made on ample days times so when 6.43 will be stable heavens only know....

In the meantime we'd suffer from bad networks and the competition is expanding in our backgarden.....

lomayani · Thu May 24, 2018 11:11 am

I've been testing 6.42.1 for a while now in all of my Sectors with Basebox 5 and SXT SA5, all clients are SXT lite5 and sq and the results are a bit better then before when throughput is the only thing in mind, but ping times are not good and jitter seems to be even worse then before ping times go all over the place even if the traffic on the sector AP is very low. And for the first time after years using Mikrotik and NV2 and hearing lots of people saying nstream is bad for ptmp, that's not what I saw after 10 hours I changed one sector to Nstream. I also changed another sector to 802.11 and everything seems to be better, througput, ping times are consistent and very low! I've always used NV2, but now seeing the results of the other protocols... The only thing I think I might mis is if I get one client with bad signal ruinning the whole sector...

One other thing I notice on two sectors, when I remove the clients bandwidth control so I can make an Internal bandwitdth test to them, If i set the test to udp, when the throughput reaches the maximum speed, all the other clients starts dropping its pppoe session as if one client only overloads the AP and none of the others can pass any data.

Yes i have seen this issue one client can overload AP when have high download and cause other clients to go slow. If you are limiting clients to a certain speed then you dont need to worry of this.
When i did tests with 6.43rc fixes the possibility of one client to overload the AP but overall throughput of the AP is low in 6.43rc. One client can go to 100mbps in 6.42 but in 6.43rc hardly going to 60mbps

WirelessRudy · Thu May 24, 2018 12:07 pm

When i did tests with 6.43rc fixes the possibility of one client to overload the AP but overall throughput of the AP is low in 6.43rc. One client can go to 100mbps in 6.42 but in 6.43rc hardly going to 60mbps

What rc version did you actually test? If this is the latest then MT needs to go back to the drawing board with its NV2.

lomayani · Thu May 24, 2018 3:43 pm

When i did tests with 6.43rc fixes the possibility of one client to overload the AP but overall throughput of the AP is low in 6.43rc. One client can go to 100mbps in 6.42 but in 6.43rc hardly going to 60mbps
What rc version did you actually test? If this is the latest then MT needs to go back to the drawing board with its NV2.

I tested 6.43rc14. I have not worked with latest version. the sharing between clients is much better in 6.43 but overall throughput is less. So far 6.42.2 is working fine for me in terms of throughput. I can hit 100Mbps under 20Mhz channel which is very ok

mohamads · Sat May 26, 2018 12:39 am

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.

Yep same here send was 11Mbps now 7 to 8 Mbps with 20Mhz but when using 20/40Mhz Ce it goes to 18 or 20 Mbps that doesn't seem to be a fix my mistake was I didn't test it with 40 Mhz before upgrading both AP and Station ( note: station isn't AC).

I was really excited loosing three Mbps is pain in the ...

get it

jonmansey · Tue May 29, 2018 6:51 am

Early results look promising for v6.42.3 fixing this nv2 issue with ar7240 stations, today I installed on an OmniTik and a mixture of SXT5 Lite and SXT5HnD stations, and I no longer get the TX Rate dropping to 6Mbps and the terrible jitter and pauses seen with 6.42.1.

Raumaster · Mon Jun 04, 2018 10:11 pm

Yes, I can confirm jitter seems to be lower in version 6.42.3.

NathanA · Fri Jun 15, 2018 4:03 pm

Even some LTE networks use TDD based TDMA.
Which LTE networks?

Seriously?

https://en.wikipedia.org/wiki/LTE_(tele ... of_LTE-TDD

Each LTE "band" is designated by definition to be either FDD or TDD: https://en.wikipedia.org/wiki/LTE_frequency_bands

We run a LTE-TDD Band 43 network in our little corner of the United States. Equipment supplied by these guys. And, actually...it's pretty awesome.

I've been trying to advocate for MT to build a fixed-install TDD Band 43 CPE not unlike SXT LTE (and hopefully at a similar pricepoint!) but so far they haven't indicated they have any interest.

-- Nathan

InoX · Fri Jun 15, 2018 8:08 pm

“Telrad provides a software-defined solution. We don’t have to send anyone up the towers to replace equipment when there is an upgrade or change; we simply do a software upload – which is huge cost savings for the city,” added Joyce.

Now that's really really funny.
So they have invented software upload...

NathanA · Fri Jun 15, 2018 9:02 pm

Now that's really really funny.
So they have invented software upload...

Hah, I'm not sure where you pulled that quote from, but what they were undoubtedly referring to was the fact that it's an FPGA-based radio head ("software-defined radio"). So to use an example that you could relate to, this would be more like if you had an AP hardware platform that could go from being 802.11n to 802.11ac with just a software load and without any hardware changes. It actually started out life as a WiMAX product, and once it was clear that was a dead-end, they pivoted and released an LTE software load for the existing platform...

-- Nathan

solelunauno · Mon Jul 02, 2018 9:43 pm

There is a very unbearable issue with Routeros 6.42 and NV2 wireless wds network. I attached a screenshot and a simple diagram to show what I mean.
I've a simple NV2 WDS network with one WDS AP bridge and some wds stations; If I put a dhcp client on the wds bridge interface in a station, I obtain the message:
"wlan1: bridge port received packet with own address as source address (mac address), probably loop" and the interface will be often blocked.
The same happens if I've the dhcp client on a VLAN in the same bridge.
With previous Routeros (for example I tested on a NV2 network with 6.37.1) this issue is not present.
So I broke some networks after 6.42.X update and I temporarily solved switching to Nstreme.
Does anyone else noticed the same serious issue?
Thanks

Redmor · Thu Jul 12, 2018 8:53 am

I want more details in changelog, I can't upgrade all my APs everytime I see "Nv2 improvements".

solelunauno · Wed Jul 18, 2018 5:07 pm

I want more details in changelog, I can't upgrade all my APs everytime I see "Nv2 improvements".

Do not upgrade if you use WDS.

Redmor · Sun Aug 05, 2018 10:21 am

I want more details in changelog, I can't upgrade all my APs everytime I see "Nv2 improvements".
Do not upgrade if you use WDS.

I'm not using WDS, but I would like to see an improvement in Nv2 sync too.
Support said that if a client sees two APs in sync, throughput will be terrible.
How am I supposed to make a client see only one AP on each tower? If I have a client facing the tower north-west, it will see north AP and also west one.
And after upgrading I didn't saw so much improvement, Nv2 isn't acting as a very powerful TDMA.

fiberwave · Sat Oct 06, 2018 6:27 pm

We're using NV2 for 4years now (all APs and CPs), and it's enough.
We had enough of this kind of "business model".

Now we're deploying Cambium epmp2000s that worth every penny, with perfect support.

Cheers

mistry7 · Sat Oct 06, 2018 9:59 pm

the try out series of about 20 possible hotfixes in the last 10 month for ARM NV2, shows only that it either does not work (hardware problem), or issue is not found.

No matter, you can not satisfy a WISP with try an error, we rebuild cells and use the old cpe for customers in areas that we not Upgrade anymore, because the new CPEs (ARM) are not useable in our network. And we do not going back to 802.11n

steen · Fri Nov 02, 2018 12:36 pm

the try out series of about 20 possible hotfixes in the last 10 month for ARM NV2, shows only that it either does not work (hardware problem), or issue is not found.

No matter, you can not satisfy a WISP with try an error, we rebuild cells and use the old cpe for customers in areas that we not Upgrade anymore, because the new CPEs (ARM) are not useable in our network. And we do not going back to 802.11n

Same story here... we have used NV2 since it came out, before that nstreme and prior to that 802.11.
The latter become completely useless in our environment.
Nstreme suffered from cyclic latency problems and connection losses.
NV2 has been _rock solid_ till now. We are cycling out old cpe:s and basestations but it will take years to complete. So upgrading is freezed till further.

leonix · Wed Nov 14, 2018 9:37 am

For my experiences the new NV2-Modes "dynamic downlink" are making the PtMP-Links more sensitive in case one of the clients is weak.
After installing 6.40.9 (before 6.36.2) I was wondering about the loss on the weaker link. Ping looks like below (in case there is some MBit traffic on the other better clients of the accesspoint). Accesspoint is a QRT with N-Hardware, not AC-Hardware:

Code: Select all


   12 192.168.23.xx                              56  64 4ms  

   13 192.168.23.xx                              56  64 33ms 

   14 192.168.23.xx                              56  64 669ms

   15 192.168.23.xx                              56  64 5ms  

   16 192.168.23.xx                              56  64 4ms  

   17 192.168.23.xx                              56  64 4ms  

   18 192.168.23.xx                                           timeout                                                                         

   19 192.168.23.xx                              56  64 128ms

    sent=20 received=19 packet-loss=5% min-rtt=2ms avg-rtt=50ms max-rtt=669ms

After changing the NV2-mode form the default "dynamic downlink" to "fixed downlink" and ratio 50, and setting TDMA period size from 1ms (or auto) to 3ms it was like before with the 6.36.2.

It saves trouble not to have weak links (mine hast SNR: 45, compared to >55dB on the other clients), but sometimes you do not have an option

.
Other useful setting for this scenario (of some weak clients) are:
- set data rate to "configured"
- reduce the connect rate to e.g. 120Mbps by disabling "HT supported MCS" MCS4-MCS7, MCS12-MCS15, MCS16-MCS19, all other must be enabled

With this settings the clients will connect with 120MBps or lower and never higher, resulting in >90% CCQ and lower packet jitter

Here you see: only connect-rates up to 120MBps and good CCQ>90, (however at least for the downlink (TX)).

Just my thoughs,

Leo.

n21roadie · Wed Nov 14, 2018 8:47 pm

@leonix - Not sure why HT supported MCS rates 16-19 are enabled when they require 3 spatial streams and QRT is dual chain?

WirelessRudy · Fri Jan 25, 2019 11:31 am

@leonix; What speeds do you get? I made now extensive tests on at least 6 different P2MP networks of mine (all Mikrotik, some 'ac' only, other mixed. All have mipsbe and arm devices mixed, AP's are either NetMetal or SXT-SA device. Some work in 20Mhz and some in 40Mhz band. Some have data rates fixed, some 'auto'. )
In each and every case I can put twice as much speed to clients and total thoughput on either nstreame or 802.11 as in NV2.

What are your typical NV2 settings? I tried virtually all possible setting to no avail in each of the networks. Everytime NV2 looses big time.....
So it would be interesting to learn about your settings and environment. We always have many other AP's working in the region so interference or high noise levels are common.

Who is online