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

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

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

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

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

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

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

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

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

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

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

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

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

Sent from my ONEPLUS A5010 using Tapatalk

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

Sent from my ONEPLUS A5010 using Tapatalk

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

Sent from my ONEPLUS A5010 using Tapatalk

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

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

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

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

NV2 is still very bad.

802.11:

nv2 2ms dynamic:

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

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

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

NV2 is designed to overcome problems in P2manyP networks. So it would be a complete failure if that would not be the case.

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

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

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

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

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

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

Full modulation, max speed, highest modulation.

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

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

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

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

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

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

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

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

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

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

I've noticed a big increase on WLAN throughput

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

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

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

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

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

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

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

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

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

We tried ROSv 6.40.5, 6.40.7, 6.41.3 and last 6.42

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Replying to Uldis,

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

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

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

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

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

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

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

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

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

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

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

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,

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.

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

@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?

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

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.

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.

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.

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?

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

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

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.

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.

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?

/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

/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

AP: mANTBox 15s

Code: Select all

/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

Code: Select all

/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?

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

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

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

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.

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.

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.

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!

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!

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.

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

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.

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;

Even some LTE networks use TDD based TDMA.

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.

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?

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

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

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

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

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 ?

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 ?

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

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

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.

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

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.

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

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

• 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?

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

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.

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

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

Even some LTE networks use TDD based TDMA.

Which LTE networks?

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

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

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.

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