Significant improvement for wireless Nv2 PtMP

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