NV2 Real life PTMP migration and stability

steen · Wed Feb 09, 2011 6:05 pm

A discovery, wi do have a large number of CPE with radioboards which appair to be so old that Nv2 does not support them.

/system resource pci print
Atheros Communications, Inc. AR5006X 802.11abg NIC

But they were never observed to be any problems since they are told to
be Atheros 5413 board when using winbox.

I am comfused, which is correct, will they work with NV2 ?

chadd · Wed Feb 09, 2011 8:49 pm

same results here. I did 18mbps and higher also in order for nv2 to work. Same results on the rb133's also. Once there online you really cant manage the rb133 to well but it works. You can NOT get full bandwidth with nv2 on the rb133 but however it is still very good.

I have the NV2 package running on several 133 boards, and although the are a bit slow I don't have any issues with lockups or management issues on them. You need to make sure you don't have any packages installed that you don't need because they don't have much memory.

steen · Sat Feb 12, 2011 4:46 pm

Hello Folks!

I have problems with switching between wireless and wireless-nv2.

I did switch the lab AP to wireless-nv2 to test all nitty gritty there.

Then I did switch back to wireless, and disabled the R52n-m and enabled the second wireless board which is a standard R52H.

It was configured exactly as all our AP:s elsewhere.
The R52 based clients are configured exactly as the working ones elsewhere in our network.
No clients using R52 can connect to it anymore, I got over and over again:

15:24:57 wireless,debug wlan1: 00:0C:42:64:11:4C attempts to associate
15:24:57 wireless,debug wlan1: 00:0C:42:64:11:4C not in local ACL, by default accept
15:24:57 wireless,info 00:0C:42:64:11:4C@wlan1: connected
15:25:02 wireless,info 00:0C:42:64:11:4C@wlan1: disconnected, unicast key exchange timeout
15:25:04 wireless,debug wlan1: 00:0C:42:64:11:4C attempts to associate
15:25:04 wireless,debug wlan1: reject 00:0C:42:64:11:4C, banned (last failure - unicast key exchange timeout)
15:25:04 wireless,info wlan1: data from unknown device 00:0C:42:64:11:4C, sent deauth
15:25:16 wireless,debug wlan1: 00:0C:42:64:11:4C attempts to associate
15:25:16 wireless,debug wlan1: reject 00:0C:42:64:11:4C, banned (last failure - unicast key exchange timeout)
15:25:16 wireless,info wlan1: data from unknown device 00:0C:42:64:11:4C, sent deauth
15:25:28 wireless,debug wlan1: 00:0C:42:64:11:4C attempts to associate
15:25:28 wireless,debug wlan1: reject 00:0C:42:64:11:4C, banned (last failure - unicast key exchange timeout)
15:25:28 wireless,info wlan1: data from unknown device 00:0C:42:64:11:4C, sent deauth
15:25:40 wireless,debug wlan1: 00:0C:42:64:11:4C attempts to associate
15:25:40 wireless,debug wlan1: 00:0C:42:64:11:4C not in local ACL, by default accept
15:25:40 wireless,info 00:0C:42:64:11:4C@wlan1: connected
15:25:45 wireless,info 00:0C:42:64:11:4C@wlan1: disconnected, unicast key exchange timeout
15:25:45 wireless,info wlan1: data from unknown device 00:0C:42:64:11:4C, sent deauth

I do not know where to begin looking, all I know is checked against working APs and Clients, something is screwed up.

Swicthing between wireless packages, do you loose configuration or what is going on.

I am forced to postpone migration to NV2, again.

Anyone who knows ?

steen · Sat Feb 12, 2011 6:59 pm

Hello Folks!

I have problems with switching between wireless and wireless-nv2.

I did switch the lab AP to wireless-nv2 to test all nitty gritty there.

Then I did switch back to wireless, and disabled the R52n-m and enabled the second wireless board which is a standard R52H.

It was configured exactly as all our AP:s elsewhere.
The R52 based clients are configured exactly as the working ones elsewhere in our network.
No clients using R52 can connect to it anymore, I got over and over again:

15:24:57 wireless,debug wlan1: 00:0C:42:64:11:4C attempts to associate
15:24:57 wireless,debug wlan1: 00:0C:42:64:11:4C not in local ACL, by default accept
15:24:57 wireless,info 00:0C:42:64:11:4C@wlan1: connected
15:25:02 wireless,info 00:0C:42:64:11:4C@wlan1: disconnected, unicast key exchange timeout
15:25:04 wireless,debug wlan1: 00:0C:42:64:11:4C attempts to associate
15:25:04 wireless,debug wlan1: reject 00:0C:42:64:11:4C, banned (last failure - unicast key exchange timeout)
15:25:04 wireless,info wlan1: data from unknown device 00:0C:42:64:11:4C, sent deauth
15:25:16 wireless,debug wlan1: 00:0C:42:64:11:4C attempts to associate
15:25:16 wireless,debug wlan1: reject 00:0C:42:64:11:4C, banned (last failure - unicast key exchange timeout)
15:25:16 wireless,info wlan1: data from unknown device 00:0C:42:64:11:4C, sent deauth
15:25:28 wireless,debug wlan1: 00:0C:42:64:11:4C attempts to associate
15:25:28 wireless,debug wlan1: reject 00:0C:42:64:11:4C, banned (last failure - unicast key exchange timeout)
15:25:28 wireless,info wlan1: data from unknown device 00:0C:42:64:11:4C, sent deauth
15:25:40 wireless,debug wlan1: 00:0C:42:64:11:4C attempts to associate
15:25:40 wireless,debug wlan1: 00:0C:42:64:11:4C not in local ACL, by default accept
15:25:40 wireless,info 00:0C:42:64:11:4C@wlan1: connected
15:25:45 wireless,info 00:0C:42:64:11:4C@wlan1: disconnected, unicast key exchange timeout
15:25:45 wireless,info wlan1: data from unknown device 00:0C:42:64:11:4C, sent deauth

I do not know where to begin looking, all I know is checked against working APs and Clients, something is screwed up.

Swicthing between wireless packages, do you loose configuration or what is going on.

I am forced to postpone migration to NV2, again.

Anyone who knows ?

I now quite myself

But I found something.
Both LAB AP and client run routeros 4.16 (whole our network do).
Security profiles are the same for both client and ap.

Client:
WPA2 PSK
tkip
WPA Pre-shared Key:abc123

AP:
WPA2 PSK
tkip
WPA Pre-shared Key: abc123

When I put security profile: default it connects. Hmmmmm........

So it is either a BUG or some else shit.

Next I did make a new security profile with same crypto in and tested and guess what, now it works again.

But this kind of scary behavor will demand visiting the antenna with all that hassle...

n21roadie · Sat Feb 12, 2011 9:07 pm

Client:
WPA2 PSK
tkip
WPA Pre-shared Key:abc123

AP:
WPA2 PSK
tkip
WPA Pre-shared Key: abc123

From other posts aes ccm is better for performance than tkip,

steen · Sat Feb 12, 2011 9:17 pm

Migration tests and other without visiting antennas, Finally sucessfull in lab!

Basestation & Client's are using wireless package and nstreme.
Basestations wireless interfaces: wlan1 (R52H), wlan2 (R52n-m), wlan3(R52n-m), wlan4(R52)
Client's wireless interfaces: wlan1 (R52)

1. At clients:
/system package enable wireless-nv2 ; /system reboot
(after reboot wireless-protocol=unspecified, but client connects anyway)

Wait and see that client connects again (nstreme should still work).

2. At clients (to be able switching protocols):
/interface wireless set wlan1 nv2-security=enabled nv2-preshared-key=test123 wireless-protocol=nv2-nstreme
/interface wireless set wlan1 nv2-security=enabled nv2-preshared-key=test wireless-protocol=nv2-nstreme

Wait and see that client connects again (nstreme should still work).

3. At basestation (change to wireless-nv2 package):
/system package enable wireless-nv2 ; /system reboot
(after reboot wireless-protocol=unspecified, but client connects anyway)

Wait and see that client connects again (nstreme should still work).

4. At basestation (only wlan1 and 2 is used).:
/interface wireless set wlan1 nv2-security=enabled nv2-preshared-key=test123 wireless-protocol=nv2
/interface wireless set wlan2 nv2-security=enabled nv2-preshared-key=test wireless-protocol=nv2

Wait and see that client connects again (nv2 should still work).
Now you can switch between nv2 and nstreme.

I did this without loosing TCP connection

several times.

It seems like MT have missed that we in sweden has 802.11A TURBO (108MHz).
R52/R52H, picking Country Sweden fails to then switch to 40MHz bandwith (frequency becomes unknown), well we have TURBO for 5GHz band in Sweden. Mikrotik has to fix this bug please. So I am stuck to 20MHz.
Anyone who knows ?

steen · Sat Feb 12, 2011 10:43 pm

Client:
WPA2 PSK
tkip
WPA Pre-shared Key:abc123

AP:
WPA2 PSK
tkip
WPA Pre-shared Key: abc123
From other posts aes ccm is better for performance than tkip,

Okey, I will look on that.
Original configuration of our network was several years ago by MT Engineers, we did leave it as is.

steen · Sat Feb 12, 2011 10:56 pm

Client:
WPA2 PSK
tkip
WPA Pre-shared Key:abc123

AP:
WPA2 PSK
tkip
WPA Pre-shared Key: abc123
From other posts aes ccm is better for performance than tkip,
Okey, I will look on that.
Original configuration of our network was several years ago by MT Engineers, we did leave it as is.

Thank you very much, it worked, performance increased most on small RB411 boards, less CPU and better throughput!

Mon Feb 14, 2011 12:11 pm

great to know that Nv2 is working for you.
About the Sweden turbo mode. Can you forward some government document that says it support turbo band?

steen · Mon Feb 14, 2011 9:41 pm

great to know that Nv2 is working for you.
About the Sweden turbo mode. Can you forward some government document that says it support turbo band?

Okey, I will ask the Swedish authority for Radio Frequencies.

They are called Kommunikationsmyndigheten PTS, Box 5398, 102 49 Stockholm, tel. 08-678 55 00, pts@pts.se

All their papers is in Swedish so I guess it fall back to my desk and also to consult some translator etc..., I have asked them today in email (48 hours service).

I will be back with what they say.

steen · Mon Feb 14, 2011 9:45 pm

We have today started to deploy NV2 sector by sector. So far nobody have noticed anything, basestations has lower CPU and ping times was also lowered everywhere.

let's now see what pts say, I asked them today if we can use 802.11a Turbo in Sweden ?
* If they say yes, we have 108 Mbit/s links

* If they say no, then we change all radioboards from R52 to R52n-M instead.

)

steen · Wed Feb 16, 2011 12:06 am

Hello Folks and MT!

I did send in to support@microtik.com about the so called 802.11a Turbo mode in Sweden, I did get some help from PTS to find the juridical documents.

I must confess, I did not understand to much about it, some documents say yes 20MHz plus upper 20MHz channel or lower channel.

Some document called: EN 301 893 exist in version 1.2.3 up to 1.5.1.
1.2.3 does not mention bandwidth, exept in a spectral diagram +/- 9MHz = 20MHz.
1.5.1 say 5-40MHz nominal bandwidth, and some wording about 20MHz plus upper/lower channel. Also there is provided a spectral diagram, now instead with a small formula multiplying nominal bandwidth with a value.

See for yourself, the Swedish WLAN frequencies without licence requests:
2400 2483,5 Dataöverföring Trådlösa nätverk
Undantag från tillståndsplikt 2006/771/EG
2400 2483,5 Dataöverföring Trådlösa nätverk
EN 300 440-2 EN 300 328 PTSFS 2004:8 Undantag från tillståndsplikt 2006/771/EG
5150 5250 Dataöverföring Trådlösa nätverk
EN 301 893 v1.2.3 ECC/DEC(04)08 PTSFS 2004:8 ETS 300 836-1 ed.1 Undantag från tillståndsplikt 2005/513/EG
5250 5350 Dataöverföring Trådlösa nätverk
EN 301 893 v1.2.3 ECC/DEC(04)08 PTSFS 2004:8 Undantag från tillståndsplikt 2005/513/EG
5470 5725 Dataöverföring Trådlösa nätverk
EN 301 893 ERC/DEC(99)23 PTSFS 2004:8 Undantag från tillståndsplikt 2005/513/EG
5470 5725 Dataöverföring Trådlösa nätverk
Undantag från tillståndsplikt 2005/513/EG
5470 5725 Dataöverföring Trådlösa nätverk
Undantag från tillståndsplikt 2005/513/EG
17100 17300 Dataöverföring Trådlösa nätverk
Undantag från tillståndsplikt ERC/REC 70-03 Annex 3 d)
17100 17300 Dataöverföring Trådlösa nätverk
Undantag från tillståndsplikt ERC/REC 70-03 Annex 3 d)
57000 66000 Dataöverföring Trådlösa nätverk
Undantag från tillståndsplikt 2006/771/EG
57000 66000 Dataöverföring Trådlösa nätverk
Undantag från tillståndsplikt 2006/771/EG
57000 66000 Dataöverföring Trådlösa nätverk
Undantag från tillståndsplikt 2006/771/EG
57000 66000 Dataöverföring Trådlösa nätverk
Undantag från tillståndsplikt 2006/771/EG
57000 66000 Dataöverföring Trådlösa nätverk
Undantag från tillståndsplikt 2006/771/EG
57000 66000 Dataöverföring Trådlösa nätverk
Undantag från tillståndsplikt 2006/771/EG

Wed Feb 16, 2011 10:04 am

This is not a Swedish requirement, "ETSI EN 301 893" (1.2.3 up to 1.5.1.) is a EU standard, and several of our products are compliant with it.

steen · Wed Feb 16, 2011 2:17 pm

This is not a Swedish requirement, "ETSI EN 301 893" (1.2.3 up to 1.5.1.) is a EU standard, and several of our products are compliant with it.

Yes that is true.

I am newbee here

you boys and girls are the experts here and in this subjects, I do not understand all this, only I can see that PTS authority referes to the EU documents in law text and that Sweden is normalizing towards the EU regulations, and that is the documents above.
Sorry if I am missleading, I try my best to get clearyfied this.

So I will call PTS again to try them write something in clear text and put their stamps on it togeather with contact persons in Swedish authority PTS, it will take some time however, they are not fast, but I am not in hurry at all either.

steen · Sat Feb 19, 2011 4:54 pm

Hello Folks!

IP PACKING.

I did not realise that you needed to have neighbors activated in order to have it working.

So I did enable neighbors on wlan interfaces using n-streme, routeros is 4.16 and basestation is rb600 and lients rb411.

Now it start happen things.

1. Ping times rises from 1-3ms to steady 31ms on all nodes. I did expect something like this.
2. In some moment, The Dude start to yell, XYZ down, cpu down etc.

Trying to ping devices now show lot of timeouts, unstable links ??

I had to quickly disable ip packing to stabilize the network segment and hopefully nobody saw something.

Can anyone explain this for me, am I doing something wrongly ?

steen · Sun Feb 20, 2011 12:12 pm

I did change cryptation from tkip to aes-ccm on suggestion to achieve little more performance.

In order to change cryptation without loosing connection to clients the sfollowing steps were used:
1. Add aes-ccm on all clients in sector.
2. Add aes-ccm on AP in that sector.
3. Remove tkip on AP in that sector.
4. Remove tkip on clients in that sector.

After each step above clients reconnect is observed.

Result lower CPU)
Client's (RB411) from 11%-15% to 8%-9%.
AP (RB600) 20-30% to 18-27%

Not much but little anyway.

steen · Sat Mar 05, 2011 10:37 am

Hello Folks!

So far no problem with nv2 in our environment, all system has been rock solid since last post in this thread.
No customer complainments regarding mikrotik devices (knock on wood).

We are evaluating ROS4.17 in lab, so far all has been working perfectly using RB411 client board with R52 and R52n-m, RB433 basestations with R52 and R52n-m and as routers RB333 plus RB750.

I will be back on real life implementation result.

WirelessRudy · Sat Mar 05, 2011 3:00 pm

Hi Steen,

Can you tell me, are you deploying your networks in a heavy use (spectrum) environment or are you the sole user.

I have 4.16NV2 deployed on some towers now and also some back hauls but have still some problems with regular, but random intervals, disconnection of some back haul units.

I also found that in my area where I basically use all 12 5Ghz channels before with normal 802.11 I had no interference problems. My problems were more many hidden node clients.

But now I found I have to separate most close proximity radio's by at least 40Mhz to keep stable.
Links that before were stable with only 20Mhz distance became unstable when one of the links started to use NV2. After separating freq's more problem disappeared.

With "unstable" I refer to the fact the links were regularly at random intervals, disconnecting to re-connect immediately again. Signals and CCQ's were perfect so the only reason I could think of is interference of the nv2 protocol with other links.

You have any experiences of this kind?

steen · Sat Mar 05, 2011 5:17 pm

Hi Steen,

Can you tell me, are you deploying your networks in a heavy use (spectrum) environment or are you the sole user.

I have 4.16NV2 deployed on some towers now and also some back hauls but have still some problems with regular, but random intervals, disconnection of some back haul units.

I also found that in my area where I basically use all 12 5Ghz channels before with normal 802.11 I had no interference problems. My problems were more many hidden node clients.

But now I found I have to separate most close proximity radio's by at least 40Mhz to keep stable.
Links that before were stable with only 20Mhz distance became unstable when one of the links started to use NV2. After separating freq's more problem disappeared.

With "unstable" I refer to the fact the links were regularly at random intervals, disconnecting to re-connect immediately again. Signals and CCQ's were perfect so the only reason I could think of is interference of the nv2 protocol with other links.

You have any experiences of this kind?

Hello WirelessRudy!

I am the deployer of our two community networks yes!
Althought I am newbee, so my experience is a bit limited

Our similar problems to yours boiled down to radio interference from myself and client devices, misaligned antennas, electrical power problem, plus tons of beginner errors

We migrated from nstreme to nv2, 802.11abg was abandoned 3 years ago here.

We do not have any wireless backbones, all our towers are cabled, rb600 and rb333 based.
Clients are ric522C (rb411 based). We are starting to use the new SXT, little to less gain in antenna sadly.

Thanks to others in the forums we did the below work.
Hardware adjustments:
1. Directional antennas with good gain and narrow opening window both in H/V at all clients.
2. Well sectorized towers, good directional antennas with good gain, flattering out the opening window to horizontal plane. (4-8 sectors and one omni for failback).
3. Removing all freznel zones and mounting all antennas outdoor.
4. Horizontal polarisation for r52 antennas, and H/V for the r52n-m antennas.
I would like to have antennas with circular polarization, I guess they will increase the quality even more.
5. Reduce impact of splatter: separate all basestations about 80-100MHz.
6. UPS and power line filters on all basestations and client devices.

Software adjustments:
7. Use aes ccm instead of tkip, it lowered the CPU load in all network, more cpu over for other things.
8. Disabled ip-packing, it was causing timeouts and strange communication lockups.
9. Routing no bridging, reducing junk traffic.
10. Queues and firewall settings in client devices to reduce junk traffic even more.

So we are fine for now, we did have problems with snow and climate conditions, antenna polarization was "disturbed" by our weather, we had to tilt some antennas right and left during the winter, clients were dropping out and s/n levels ccq went down. Very annoying, circular polarization antennas would reduce this drawback.

WirelessRudy · Sun Mar 06, 2011 2:25 am

Hi, some questions;

2. Well sectorized towers, good directional antennas with good gain, flattering out the opening window to horizontal plane. (4-8 sectors and one omni for failback).

What type of sector antenna's do you use? "flattering out ...."; something you do? Or result of using this type of antenna?

3. Removing all freznel zones ..................

What do you mean with this? A freznel is something that comes with a radio link. You can make it bigger or smaller by using type of antenna and off course freznel is result of frequency times distance. Nothing can be done about that last...

4. Horizontal polarisation for r52 antennas,..

You started your network with HP? I have 125 antenna's on 5 AP's in urbanized area. It's going to be complicated to change their polarity fm V to H. Any advices on this..?

5. Reduce impact of splatter: separate all basestations about 80-100MHz.

? Outdoor usable 5ghz band in Europe is only 200Mhz wide. (5500-5700Mhz)This way you can only use 3 basestations.. I have 5 AP's with all interconnected backhauls and some backhauls leaving this aera so I use all available 11 channels anyway. Some of my backhauls are ´n´ with 40Mhz channel wide so I already have to consider very precise where to use which freq's. The whole area is only 2km radius at max. Only because of topology I have to use 5 AP's

6. UPS and power line filters on all basestations and client devices.

Even on client devices? This is very expensive! Clients have adapter and when it breaks they get first one for free, next ones they pay replacement costs. If they have a power failure, they won't use internet access anyway so no need for UPS on client side...

8. Disabled ip-packing, it was causing timeouts and strange communication lockups.

"ip-packing"? What is that? And it is bad? And what to do about it when it is bad?

9. Routing no bridging, reducing junk traffic.

Routing is faster anyway under heavy traffic conditions.

10. Queues and firewall settings in client devices to reduce junk traffic even more.

What do you consider to be "junk traffic"? Any examples of the firewall rules. I have still many 133C's in my network and with 4.16NV2 package they can't have any extra tasks like mangle and firewall and queuing..

So we are fine for now, we did have problems with snow and climate conditions, antenna polarization was "disturbed" by our weather, we had to tilt some antennas right and left during the winter, clients were dropping out and s/n levels ccq went down. Very annoying, circular polarization antennas would reduce this drawback.

I am surpriced to read about the weather influences you have seen. I live in a very tranquil climate and apart from an occasional downpour in the summer and maybe some snow flakes in some winters it is always relatively reasonable weather here. My biggest concern is wind. It can be very gusty here at time with many whirls from the mountains around us. All outdoor equipments have to be very sturdy fit to withstand really severe gusts..

eivind · Thu Mar 10, 2011 1:05 pm

I have just changed all my AP's into nv2, and it solved more problems than it created. RB133c is on the cpu/mem-limit, thats for sure. After upgrading to v4.16/17 it gets very busy for a long time, but when it calms down I managed to change wireless protocol. Sometimes I had to deactivate ether1 to be able to work on it, and sometimes telnet instead of winbox had been the solution. I have about 80 of these boards and if they are not outdatet just now, they will be very soon. I will gladly replace them with RB411/711 to stay on top.
I had a customer on the phone, and he was measuring lower bandwidth than before. I did a btest from his rb and got full speed. I cannot believe that nv2 will make any difference in measures from routerboard compared to ether1. I may be because I was logged on og higher cpu-load (50%) while measuring. In one of my networks I have only RB411/711 and its running perfect even width advanced QoS and up to 5,5 Mbps customer bandwidth!
My conclution is, go for nv2 and do the neccessary upgrades to better RB's!
Here is what happened when starting nv2... The 133c rised about 8% in cpu-load, and one of the clients antenna got "stressed" for a couple of hours. I can see cpu-loads up to 30%-40% on rb's while customer is surfing or downloading.

cpu-graph.jpg

WirelessRudy · Thu Apr 07, 2011 2:00 am

steen, airnet,
We are now in april and with v5.0 with nv2 embedded. Do you guys have some new updates for us?
Both mentioned some aspects where not 100% clear to you guys. You already learned more?

What are your experiances with nv2 now so far on this moment? (And with the new 5.0ros?)
I have it running now on some of my networks, not all.
I have had lots of issues with mixed PtMP networks but found some ´hardening´ procedures for stabilizing. (Fixe freq. scan, mentioning of both SSID and mac in ´connect to´ option) and by degreasing channel bandwiths whereever possible (ongoing process) from 20 to 10Mhz and limiting data rate to 18Mbps (which makes 9Mb in 10Mhz channels) I manage to get most issues under control.

In previous post I distilled two questions that are still not clear to me:

1. NV2 or TDMA makes AP sends at full power when transmitting 24/7 even on idle link while 802.11 would only do when really transmitting data? Would this not shorten the live of the radio and would it not consume lots more power? Important to know for battery powered installations. If capacity was calculated for 802.11 situation same might now prove to be short falling.

2. I have been learned on this forum and/or support/3rd party tutor, that in 802.11 you can set data rates (for AP, leave CPE at default) to fixed level but you always need at least two more data rates set. One as a fall back in case the set one can't sustain and the lowest one since that one is needed to allow the basic rate. Is this in NV2 now not the best scenario? I read in the posts of airnet that nv2 more asks for a setting of one and one data rate only? (And should the basic rate then be set to the same?)

I hope you guys can come up with a follow up on the nv2. Together we can then decide to edit the Wiki in such that it is more clear what the differences between the 3 protocols are and what is the best suggested configuration for nv2.

steen · Sat Apr 09, 2011 6:57 pm

steen, airnet,
We are now in april and with v5.0 with nv2 embedded. Do you guys have some new updates for us?
Both mentioned some aspects where not 100% clear to you guys. You already learned more?

What are your experiances with nv2 now so far on this moment? (And with the new 5.0ros?)
I have it running now on some of my networks, not all.
I have had lots of issues with mixed PtMP networks but found some ´hardening´ procedures for stabilizing. (Fixe freq. scan, mentioning of both SSID and mac in ´connect to´ option) and by degreasing channel bandwiths whereever possible (ongoing process) from 20 to 10Mhz and limiting data rate to 18Mbps (which makes 9Mb in 10Mhz channels) I manage to get most issues under control.

In previous post I distilled two questions that are still not clear to me:

1. NV2 or TDMA makes AP sends at full power when transmitting 24/7 even on idle link while 802.11 would only do when really transmitting data? Would this not shorten the live of the radio and would it not consume lots more power? Important to know for battery powered installations. If capacity was calculated for 802.11 situation same might now prove to be short falling.

2. I have been learned on this forum and/or support/3rd party tutor, that in 802.11 you can set data rates (for AP, leave CPE at default) to fixed level but you always need at least two more data rates set. One as a fall back in case the set one can't sustain and the lowest one since that one is needed to allow the basic rate. Is this in NV2 now not the best scenario? I read in the posts of airnet that nv2 more asks for a setting of one and one data rate only? (And should the basic rate then be set to the same?)

I hope you guys can come up with a follow up on the nv2. Together we can then decide to edit the Wiki in such that it is more clear what the differences between the 3 protocols are and what is the best suggested configuration for nv2.

Hello Veteran's!
We are currently using routeros 4.16 in whole network with NV2. In our situation is is very stable now. About power consumptions, what we noticed so far is that reported link speed goes down when there is no traffic an immediate goes up when traffic is present. I have no idea if that also indicates that power consumption also goes down and up. But good idea, I will check it by putting amp meter on some installations to see. All configuration is out of the box, see previous posts in this topic. Look and feel does not indicte any more heat generated from radios and boards, looks exactly the same as before. Classic 802.11 we did abandon years ago due to hidden node problems.

mperdue · Sun Apr 10, 2011 1:19 am

I have close to 200 clients on 12 relays. All AP's are RB 433AH's. Client units are rb411(80%), rb133(18%), and rb133(2%). Most cards in use on the network are Enginuis 8602-s Plus cards. With a few r52, xr2's, and two DBII F-20 cards.

All units were upgraded to 4.17 and clients were set to accept "any" protocol.

My smallest relay (and newest) has 3 clients on it. It's a solar powered system at 2,800 ft.
My largest has 65 clients located at 2500ft.
My smallest radius relay is downtown which has 18 clients within 1 mile radius.
Most other relays have has 10-15 clients.

Switched everything over to NV2 two weeks ago. And had to return to 802.11 yesterday.

The biggest issue I had was disconnects, some units including my home unit simply would not stay connected. It's an RB411 with a DBII card. It would drop every few minutes with frame time out error. This same unit stays connected for weeks on 802.11. It's 7km from tower with a -61 signal and -98 to -101 noise floor.

The second issue I had was that I really didn't see any improvement in the system to handle congestion. I know using 802.11 that some users seemed to be able to use alot of bandwidth and others get very little. And the way I thought I understood the NV2 was that it would allow for more even distribution of bandwith.

With this said, I had good contact with Mikrotik support and have sent me several upgrades and package to fix the disconnect issue. I did mange to reduce the amount of disconnects somewhat but not to the point that customers could accept. I finally decided to switch back to 802.11 and now 95% of my people don't disconnect anymore. I knew I had a few people that needed some adjustments on there units and would have to be adjusted but I was able to compaire it against many customers who never disconnect including the unit at my own home.

In a few days I will upgrade all the units to the 5.x version and try a few towers.

-Michael

n21roadie · Sun Apr 10, 2011 8:17 pm

8. Disabled ip-packing, it was causing timeouts and strange communication lockups.

What is "ip-packing"?

steen · Sun Apr 17, 2011 4:47 pm

8. Disabled ip-packing, it was causing timeouts and strange communication lockups.
What is "ip-packing"?

It packs/compresses IP packets before sending them away, all the time try to fill full the transport MTTU, and send them away.

The manual say this about ip packing:
http://wiki.mikrotik.com/wiki/Manual:IP/Packing

Unfortunaly ip packing has not been working to a satisfactory level in our environment after stepping up from Router OS3.X to Router OS 4.X. Observations regarding nstreme is also that noice toleranse went down when going from 3.X to 4.X. For us link delay increased from 1-4 ms in 3.X and suddenly it was up to 10ms all the time. Shortly after we got the catastrophe, random network lockups no link lost, but network freezes about one time per minute or more for some seconds. IP packing was then disabled all over here, maby we try it in some future.

dallas · Sun Apr 17, 2011 8:46 pm

Ip packing only makes sence to increase ping. Your trading bandwidth for latency.

steen · Sun May 08, 2011 10:34 am

Hello Folks!

We have the past weekend started to migrate LAB networks towards ROS5.2 from ROS4.16 and ROS4.17.

ROS4.16 and ROS4.17 is ROCK SOLID at our sites.

Notices regarding upgrading ROS4.16 and ROS4.17to ROS5.2 not using package wireless will end up with same situation as when switching to wireless-nv2. The wireless interface will be set to wireless protocol UNKNOWN, so far all still work, but we needed to change them to nv2-nstreme.

Notices regarding ROS5.2 is that CPU goes much higher after upgrading for some time, then it calms down and LESS cpu is used, at least while the device is in rest.

No other noticed problems so far, but we will wait with production till at least 5.3 or 5.4 is out.

WirelessRudy · Mon May 09, 2011 3:28 am

Hi Steen,

I upgraded all my 220+ units to 5.1 and some to 5.2. No problems whatsoever. Wherever possible (some mixed 2nd make devices networks still around) I also started to use nv2. Had to re arrange some freq's somewhere but in general it works fine.
Had no issues in doing the upgrade, not even the wireless remote units.

I can confirm that on 133C's that before went very slow on the early ros versions with the nv2 packages the gained some of their speeds back on the new 5.x versions... I put even some of these boards back in use!

eivind · Mon May 09, 2011 11:20 am

Upgraded a live RB133 running nv2 from ROS4.16 to 5.2 for testing.
Before upgrading the bottom line cpu-usage was about 9%, and rised to about 11%. Opening "new terminal" still gives a cpu-load at 100% for a while but seems to calm down a little bit earlier than before. Don't try to open new terminal while Your customer is online!!
I compared one RB411(with running QoS) and this RB133 by sending ping from one location and running btest in both directions (50% of delivered capasity) from another. No difference in latency...
So it seems to work well, but maybe hard to manage if the customer is online. I still want to change to RB411 with QoS to set local priority for "important" traffic to get more happy customers and less service calls coursed by p2p. It works exellent in RB411/711.

Mon May 09, 2011 11:22 am

just a small note - RB133 is not the fastest model, an Nv2 does need resources. So if you got it working at all, that's already great

WirelessRudy · Mon May 09, 2011 3:54 pm

Upgraded a live RB133 running nv2 from ROS4.16 to 5.2 for testing.
Before upgrading the bottom line cpu-usage was about 9%, and rised to about 11%. Opening "new terminal" still gives a cpu-load at 100% for a while but seems to calm down a little bit earlier than before. Don't try to open new terminal while Your customer is online!!
I compared one RB411(with running QoS) and this RB133 by sending ping from one location and running btest in both directions (50% of delivered capasity) from another. No difference in latency...
So it seems to work well, but maybe hard to manage if the customer is online. I still want to change to RB411 with QoS to set local priority for "important" traffic to get more happy customers and less service calls coursed by p2p. It works exellent in RB411/711.

I am all with you. I am sailing in the same direction. But most probably I am in the same boat as many of us, plenty of 133C's (and even 122's?) in my network around. Just to replace them all at once to run nv2 and QoS is becoming a bit costly so it has to happen over time....

steen · Sat Aug 27, 2011 6:45 pm

Hello Folks!

Now at ros5.6 we started to go live in production, leaving the lab.
Two sectors so far and no problems.
All settings is the default from factory, exept authentication.

Lets see now, there is a lot of fuzz in mikrotik forums about connection losses.
All our antennas have high SN and gain exept very few of them which we will build new sectors for later.

At 4.16 we did have success i lab, but breakdown in real world both with migration to 5.x and nv2.

n21roadie · Sat Aug 27, 2011 9:38 pm

Hello Folks!

Now at ros5.6 we started to go live in production, leaving the lab.
Two sectors so far and no problems.
All settings is the default from factory, exept authentication.

Lets see now, there is a lot of fuzz in mikrotik forums about connection losses.
All our antennas have high SN and gain exept very few of them which we will build new sectors for later.

At 4.16 we did have success i lab, but breakdown in real world both with migration to 5.x and nv2.

AP'S are most effected by NV2 disconnections which all clients cannot have high SNR, PTP is less effected theory being narrower antenna TX/RX beamwidth less pickup of interference, single AP on a mast generally no problems but have a stack of sector AP's then disconnections could occur, one setting most important is on the clients is wireless protocol "nv2 nstreame 802.11" and not "Any" this way you can quickly switch between protocols should disconnections occur also to enable nv2 security.

steen · Sun Aug 28, 2011 9:32 am

Hello Folks!

Now at ros5.6 we started to go live in production, leaving the lab.
Two sectors so far and no problems.
All settings is the default from factory, exept authentication.

Lets see now, there is a lot of fuzz in mikrotik forums about connection losses.
All our antennas have high SN and gain exept very few of them which we will build new sectors for later.

At 4.16 we did have success i lab, but breakdown in real world both with migration to 5.x and nv2.
AP'S are most effected by NV2 disconnections which all clients cannot have high SNR, PTP is less effected theory being narrower antenna TX/RX beamwidth less pickup of interference, single AP on a mast generally no problems but have a stack of sector AP's then disconnections could occur, one setting most important is on the clients is wireless protocol "nv2 nstreame 802.11" and not "Any" this way you can quickly switch between protocols should disconnections occur also to enable nv2 security.

Confirmed! We did exactly that and now in production, two sectors, 16 hours no disconnections.
If it stays like that for a week, then we will do all the other sectors to.

Directional antennas, horizontal polarisation.
Basestation has this antennas: http://www.routerboard.se/shop/products ... ntell.html and also this http://www.routerboard.se/shop/products ... 19DBI.html.

Client's are mixed lots of rb522c and some few http://www.routerboard.se/shop/products ... %A4nk.html Ric522c has been very very successful at our sites, never a problem.

Also we noticed a reduction in CPU load exactly at 16:00 when we changed the basestation protocol from nstreme to nv2, this was unexpected, see picture:

steenbas-cpu.jpg

As in lab, we also see the link speed varies, when antennas are silent they go down to 9Mbit/s and immediate at traffic they go up to 54Mbit/s. All CPE antenna's S/N is from 45 - 62, CCQ varies from 97-100 at traffic but goes down to very low values when no traffic is passed, around 20. When using nstreme it was rock solid 54Mbit/s at all time and CCQ was 98-99 all time. Anyway I have not had any complainments from customers but why this behavor ?

Is there any reason to "lock" speeds to 54Mbit ?

We plan to start use 108Mbit to get more speed when the gitabit links arrives to central site, what about that ?

SXT is not yet an option here, it's antenna is to weak in our noicy environment.

n21roadie · Sun Aug 28, 2011 7:55 pm

As in lab, we also see the link speed varies, when antennas are silent they go down to 9Mbit/s and immediate at traffic they go up to 54Mbit/s. All CPE antenna's S/N is from 45 - 62, CCQ varies from 97-100 at traffic but goes down to very low values when no traffic is passed, around 20. When using nstreme it was rock solid 54Mbit/s at all time and CCQ was 98-99 all time. Anyway I have not had any complainments from customers but why this behavor ?

Is there any reason to "lock" speeds to 54Mbit ?

That is normal for NV2, i think ccq is calculated with actual traffic being passed so no traffic ccq will read very low and also it is advised for say antenna alignment to ping address of units beyond (ptp or Ap -Cpe) and not just the ptp (or AP) ip address's and with nv2 ccq responds much slower after adjustment so adjust and wait.

n21roadie · Sun Aug 28, 2011 8:02 pm

We plan to start use 108Mbit to get more speed when the gitabit links arrives to central site, what about that ?

SXT is not yet an option here, it's antenna is to weak in our noicy environment.

http://forum.mikrotik.com/viewtopic.php?f=3&t=52966

more nv2 fuzz

http://forum.mikrotik.com/viewtopic.php?f=7&t=54077

Sun Aug 28, 2011 9:25 pm

Very good topic. Its of great interest for our business to get this stuff
working. I'll wait for 5.7 to do our next tests.

As we're in ETSI we've the problem of power regulation so we cant
avoid weak clients. All tests until know leads to the result that
plain 802.11 gave the best results in PTMP. So we need NV2 handle
some weak clients per sector.

We've started deploying dualpol sectors for a while now. We use the
same approach as UBNT does with their sectors. One router, one wireless
card per Sector Antenna in a separate housing:
(http://www.stelladoradus.com/dual.polarity.antennas.php)
So we've a quite good separation between sectors and enough
performance (RB411AH).
This gives great performance on small scale sites with SXT and 802.11.

Our target is to work with 20MHz Dual pol and see 50-100MBit/sector
with stable latency (<50ms at full loaded sector).

steen · Mon Aug 29, 2011 1:12 am

Hello Folks!

I have good news!

nv2 now for whole weekend in two sectors, all looking good, not a single network glitch.
We decided to let it continue running the whole upcoming week.

If all goes well, we will move over rest of sectors to nv2 coming weekend.

After that we need to migrate over to something faster than R52 boards and finalize it within one year.

WirelessRudy · Mon Aug 29, 2011 2:35 am

After that we need to migrate over to something faster than R52 boards and finalize it within one year.

You mean the RIC522C units?
I have some 120+ of these still in use. The old ones with 133c's I am replacing the boards for new 711's and the ones with 411 I am going to change the radio's for units that are able to work with ´n´ protocol.
I find these RIC units are still about the top CPE units I ever came across looking at Rx/Tx characteristics and resistance to interferences. Its obviously the engineers that designed these RIC's had more knowledge about delivering a good antenna than the ones that engineered the SXT!

(The early RIC series had problems with departing front covers. Out of the 130+ I bought in the last 5 years, only saw 2 early ones have that happening. But I know from other earlier users it was a bigger problem before.)

Since these RIC's are not available any more I now use SXT in locations where interference is not an issue or started recently to use groove's on mesh antenna's. Wrapped the groove with alu tape and together with 21 or 25dB gain mesh antenna's or similar gain reduced side lobs (http://www.elboxrf.com/EN/p14/TetraAnt_ ... _RSLL.html) they give me very good performances.

WirelessRudy · Mon Aug 29, 2011 2:43 am

Hi Steen,

I have been looking at these antenna's you refer too in your earlier posts. I can only hope you get some good discounts there. Their prices are very high...

steen · Mon Aug 29, 2011 7:56 pm

Hi Steen,

I have been looking at these antenna's you refer too in your earlier posts. I can only hope you get some good discounts there. Their prices are very high...

I got them from Leo at Limmared, no discount 's and for Sweden it is good prices.
But I would just love to get dual band directional antennas with 19-23dbi. Also I would like to get with circular polarization, H-Circ and V-Circ.

steen · Mon Aug 29, 2011 8:08 pm

After that we need to migrate over to something faster than R52 boards and finalize it within one year.
You mean the RIC522C units?
I have some 120+ of these still in use. The old ones with 133c's I am replacing the boards for new 711's and the ones with 411 I am going to change the radio's for units that are able to work with ´n´ protocol.
I find these RIC units are still about the top CPE units I ever came across looking at Rx/Tx characteristics and resistance to interferences. Its obviously the engineers that designed these RIC's had more knowledge about delivering a good antenna than the ones that engineered the SXT!

(The early RIC series had problems with departing front covers. Out of the 130+ I bought in the last 5 years, only saw 2 early ones have that happening. But I know from other earlier users it was a bigger problem before.)

Since these RIC's are not available any more I now use SXT in locations where interference is not an issue or started recently to use groove's on mesh antenna's. Wrapped the groove with alu tape and together with 21 or 25dB gain mesh antenna's or similar gain reduced side lobs (http://www.elboxrf.com/EN/p14/TetraAnt_ ... _RSLL.html) they give me very good performances.

Yes RIC522C rocks!
All our RIC522C is with RB411 exept a few, they have R52 boards, also some has R52Nm.
We had thought to start use Groove with external antenna (http://www.routerboard.se/shop/products ... 19DBI.html or http://www.routerboard.se/shop/products ... 23DBI.html). But we like better the idea of one unit, board and antenna like RIC522. Maby we do something like ric522c on our own at later time.

WirelessRudy · Mon Aug 29, 2011 8:18 pm

Hi Steen,

I have been looking at these antenna's you refer too in your earlier posts. I can only hope you get some good discounts there. Their prices are very high...
I got them from Leo at Limmared, no discount 's and for Sweden it is good prices.
But I would just love to get dual band directional antennas with 19-23dbi. Also I would like to get with circular polarization, H-Circ and V-Circ.

http://www.interprojekt.com.pl/jirous-j ... -1091.html
Very good antenna! I use them already for over a year. They ship world wide. Is Sweden in EUU or fiscal unity? In that case purchase without VAT. Save even more!

Look at these too:
Reduced side lob: http://www.interprojekt.com.pl/tetraant ... p-101.html

Find many more of the RSLL stuff from them: http://www.interprojekt.com.pl/antennas ... 31_91.html

I am very pleased with these RSLL antenna's and you can hang the groove's directly on them. Wrap a little bit of alu tape around the groove after aligning and you have a very compact high interference resistant unit!
To reduce the visual impact even more where interference is a lesser issue a mesh antenna with that same groove is also very good.
But I still nurse my RIC's. After 5 years they have by far best price-perfomance rating build up so far

steen · Mon Aug 29, 2011 8:28 pm

Hi Steen,

I have been looking at these antenna's you refer too in your earlier posts. I can only hope you get some good discounts there. Their prices are very high...
I got them from Leo at Limmared, no discount 's and for Sweden it is good prices.
But I would just love to get dual band directional antennas with 19-23dbi. Also I would like to get with circular polarization, H-Circ and V-Circ.
http://www.interprojekt.com.pl/jirous-j ... -1091.html
Very good antenna! I use them already for over a year. They ship world wide. Is Sweden in EUU or fiscal unity? In that case purchase without VAT. Save even more!

Look at these too:
Reduced side lob: http://www.interprojekt.com.pl/tetraant ... p-101.html

Find many more of the RSLL stuff from them: http://www.interprojekt.com.pl/antennas ... 31_91.html

I am very pleased with these RSLL antenna's and you can hang the groove's directly on them. Wrap a little bit of alu tape around the groove after aligning and you have a very compact high interference resistant unit!
To reduce the visual impact even more where interference is a lesser issue a mesh antenna with that same groove is also very good.
But I still nurse my RIC's. After 5 years they have by far best price-perfomance rating build up so far

NICE antennas!

RIC ROCKS! and i found a distrubutor in Sweden who still sell them, they have an old stock equipped with RB133, we usally replace them with rb411 or rb711 depending on what is on shelf that day.

Sweden is not in EMU, it has "krown" so I can buy without VAT. I will order some to try with directly!

wolfeyes · Thu Sep 01, 2011 5:48 pm

Hello Folks!

Now at ros5.6 we started to go live in production, leaving the lab.
Two sectors so far and no problems.
All settings is the default from factory, exept authentication.

Lets see now, there is a lot of fuzz in mikrotik forums about connection losses.
All our antennas have high SN and gain exept very few of them which we will build new sectors for later.

At 4.16 we did have success i lab, but breakdown in real world both with migration to 5.x and nv2.
AP'S are most effected by NV2 disconnections which all clients cannot have high SNR, PTP is less effected theory being narrower antenna TX/RX beamwidth less pickup of interference, single AP on a mast generally no problems but have a stack of sector AP's then disconnections could occur, one setting most important is on the clients is wireless protocol "nv2 nstreame 802.11" and not "Any" this way you can quickly switch between protocols should disconnections occur also to enable nv2 security.
Confirmed! We did exactly that and now in production, two sectors, 16 hours no disconnections.
If it stays like that for a week, then we will do all the other sectors to.

Directional antennas, horizontal polarisation.
Basestation has this antennas: http://www.routerboard.se/shop/products ... ntell.html and also this http://www.routerboard.se/shop/products ... 19DBI.html.

Client's are mixed lots of rb522c and some few http://www.routerboard.se/shop/products ... %A4nk.html Ric522c has been very very successful at our sites, never a problem.

Also we noticed a reduction in CPU load exactly at 16:00 when we changed the basestation protocol from nstreme to nv2, this was unexpected, see picture:
steenbas-cpu.jpg
As in lab, we also see the link speed varies, when antennas are silent they go down to 9Mbit/s and immediate at traffic they go up to 54Mbit/s. All CPE antenna's S/N is from 45 - 62, CCQ varies from 97-100 at traffic but goes down to very low values when no traffic is passed, around 20. When using nstreme it was rock solid 54Mbit/s at all time and CCQ was 98-99 all time. Anyway I have not had any complainments from customers but why this behavor ?

Is there any reason to "lock" speeds to 54Mbit ?

We plan to start use 108Mbit to get more speed when the gitabit links arrives to central site, what about that ?

SXT is not yet an option here, it's antenna is to weak in our noicy environment.

I have noticed same behavior with traffic going up and down in a similar environment, but using sxt as cpe.

54Mbit is the aggregate speed for all cpe's?
How many cpe's were bound on the sector and produced the above results?
Which is the maximum data rate with your configuration?

tnx

n21roadie · Thu Sep 01, 2011 6:23 pm

Hello Folks!

Now at ros5.6 we started to go live in production, leaving the lab.
Two sectors so far and no problems.
All settings is the default from factory, exept authentication.

Lets see now, there is a lot of fuzz in mikrotik forums about connection losses.
All our antennas have high SN and gain exept very few of them which we will build new sectors for later.

At 4.16 we did have success i lab, but breakdown in real world both with migration to 5.x and nv2.
AP'S are most effected by NV2 disconnections which all clients cannot have high SNR, PTP is less effected theory being narrower antenna TX/RX beamwidth less pickup of interference, single AP on a mast generally no problems but have a stack of sector AP's then disconnections could occur, one setting most important is on the clients is wireless protocol "nv2 nstreame 802.11" and not "Any" this way you can quickly switch between protocols should disconnections occur also to enable nv2 security.
Confirmed! We did exactly that and now in production, two sectors, 16 hours no disconnections.
If it stays like that for a week, then we will do all the other sectors to.

........

Another consideration about NV2 is while it was working flawlessly for me 4 sectors + 2 PtP links on one mast added 2ptp links and just like a house of cards NV2 just fell over with regular disconnects and the strange bit was even powering down the 2 PtP's that was added still had disconnects, so my theory is they were acting like passive radiators/reflectors and bouncing signals onto an AP which would in part explain why some sectors were more effected than others.

steen · Thu Sep 01, 2011 9:28 pm

Hello folks!

All our sectors are now NV2, we did add the last sectors, so far not a single dissconnect from any cpe. I am crossing fingers now.

All CPE connects at 54MBit seconds after changing to nv2.
Each sector has 10-12 CPE:s.
Our Internet here is 100Mbit fdx dual lines, speed is limited to 24MBit/s down and 5MBit/s up on each CPE and central router.
Dual rb333 act central routers and dual rb450g, bases are rb600a, cpe's is rb411 (RIC522C).
Basestations with sectors is not limited, they act as pure router and bridge for the wifi boards.
Each basestation has 3 directional sectors and one omni for 2.4GHz classic 802.11b.

All configuration is out of the box regarding nv2.

rb450g missbehave by 100% cpu now and then, restart helps.
All is ros5.6 monitored by the dude 3.6

Load on our basestation was lowered a lot by introduce nv2, also cpe show same result, as average 40-60% lower cpu usage.
Here is steenbas2 right after changing to nv2 around 19:46 :

steenbas2.jpg

wolfeyes · Fri Sep 02, 2011 1:38 am

Hello folks!

All our sectors are now NV2, we did add the last sectors, so far not a single dissconnect from any cpe. I am crossing fingers now.

All CPE connects at 54MBit seconds after changing to nv2.
Each sector has 10-12 CPE:s.
Our Internet here is 100Mbit fdx dual lines, speed is limited to 24MBit/s down and 5MBit/s up on each CPE and central router.
Dual rb333 act central routers and dual rb450g, bases are rb600a, cpe's is rb411 (RIC522C).
Basestations with sectors is not limited, they act as pure router and bridge for the wifi boards.
Each basestation has 3 directional sectors and one omni for 2.4GHz classic 802.11b.

All configuration is out of the box regarding nv2.

rb450g missbehave by 100% cpu now and then, restart helps.
All is ros5.6 monitored by the dude 3.6

Load on our basestation was lowered a lot by introduce nv2, also cpe show same result, as average 40-60% lower cpu usage.
Here is steenbas2 right after changing to nv2 around 19:46 :
steenbas2.jpg

Nice configuration. Have you tried to apply any kind of stress test on sectors in terms of data traffic.
For example, set 7-8 clients simultaneously downloading data.
Which is the maximum data rate per client on this case?

steen · Fri Sep 02, 2011 11:18 pm

Hello folks!

All our sectors are now NV2, we did add the last sectors, so far not a single dissconnect from any cpe. I am crossing fingers now.

All CPE connects at 54MBit seconds after changing to nv2.
Each sector has 10-12 CPE:s.
Our Internet here is 100Mbit fdx dual lines, speed is limited to 24MBit/s down and 5MBit/s up on each CPE and central router.
Dual rb333 act central routers and dual rb450g, bases are rb600a, cpe's is rb411 (RIC522C).
Basestations with sectors is not limited, they act as pure router and bridge for the wifi boards.
Each basestation has 3 directional sectors and one omni for 2.4GHz classic 802.11b.

All configuration is out of the box regarding nv2.

rb450g missbehave by 100% cpu now and then, restart helps.
All is ros5.6 monitored by the dude 3.6

Load on our basestation was lowered a lot by introduce nv2, also cpe show same result, as average 40-60% lower cpu usage.
Here is steenbas2 right after changing to nv2 around 19:46 :
steenbas2.jpg
Nice configuration. Have you tried to apply any kind of stress test on sectors in terms of data traffic.
For example, set 7-8 clients simultaneously downloading data.
Which is the maximum data rate per client on this case?

Since it is production I did not do any stress test by myself, need persmission from the business first

I can tell, business was shaking knees and become swetty, when switching over to NV2. I did here the classic wording: dont change something that works etc.
I will try to arange stress test.

I have some vague hint on performance. First, no customer did even notice the switchover, a good sign.
Secondly, when several customers (5-6) start filesharing or downloading I see traffic vary among nodes, stable traffic at 2-5Mbit/s for hours, common peaks up to 15Mbit/s at some clients, rare peaks to 24Mbit/s never higher. Ping time at all time is less than 32ms.
After all my sector's is maxim 54Mbit/s half duplex

Performance seems to be like before, but ping is more constant and bandwith distribution is more equal during load.

The best observable "gain" so far is the CPU load on basestations and clients. In average CPU load was lowered by 2/3 all over system at all time.

Next will be the stress test and then later increase bandwith from 20MHz to 40MHz and see how it works then. I will come back with the test results.

steen · Fri Sep 02, 2011 11:29 pm

Hello Folks!

I saw my load from basestation2 was not visable here it comes:

steenbas2.jpg

As one can see, in eavening 1 Sept we did change from nstreme to nv2, the big jump down in load.

wolfeyes · Sat Sep 03, 2011 1:48 am

Next will be the stress test and then later increase bandwith from 20MHz to 40MHz and see how it works then. I will come back with the test results.

Looking forward for the test results!

dallas · Wed Sep 07, 2011 6:59 pm

I am on 5.7 routeros and its very stable. I have 0 complaints. I have been on it for over a week.

steen · Wed Sep 07, 2011 11:31 pm

Hello Folks!

All still working fine all over network, now with normal load from all customers, load spreads out equal over the nodes, 2-3Mbit/customer and sector when all customers are filesharing, ping never exeeds 16ms no timeouts and no dropouts.

ROS 5.7 ? is that out or is it some interim release ?

dallas · Wed Sep 07, 2011 11:35 pm

I worked with Mikrotik to help fix the bug before releasing it.

WirelessRudy · Thu Sep 08, 2011 1:09 am

I worked with Mikrotik to help fix the bug before releasing it.

Which bug?

n21roadie · Thu Sep 08, 2011 3:29 pm

I worked with Mikrotik to help fix the bug before releasing it.
Which bug?

Yes what bug are you referring to, is it NV2 disconnects or some other issue that was resolved by 5.17?

WirelessRudy · Thu Sep 08, 2011 3:48 pm

Don't know. First he reacts in several topics his network is not having the problems others mention.
And now he is supposed to be the one helping MT in repairing "the bug"?

I don't know, lets wait to see what 5.7 brings and we all have to test it and find out the hard way what issues are improved and which new ones introduced or old ones not solved.
Change log is not always very helpful in that neither.

n21roadie · Thu Sep 08, 2011 4:13 pm

What i don't understand if the "bug ?" was fixed and i assume MT gave 5.17 to others to test, why we haven't read such good news on the forum from others?

Thu Sep 08, 2011 5:48 pm

What i don't understand if the "bug ?" was fixed and i assume MT gave 5.17 to others to test, why we haven't read such good news on the forum from others?

The way it goes is like this:

1. You've a problem with the actual release
2. You mail to support@mikrotik.com with .rif
3. They see it may be a bug, do a patch to their hot development source tree
4. They give you the hot shot of the moment

So then you may be lucky or you may step into a problem one of the developers
coded into last night. If another customer does the same he might get the
next hot shot including the fixes for your problem...

So let them some time to mature changes and dont urge them to release version
which are between the normal ones.

n21roadie · Thu Sep 08, 2011 6:17 pm

What i don't understand if the "bug ?" was fixed and i assume MT gave 5.17 to others to test, why we haven't read such good news on the forum from others?
The way it goes is like this:

1. You've a problem with the actual release
2. You mail to support@mikrotik.com with .rif
3. They see it may be a bug, do a patch to their hot development source tree
4. They give you the hot shot of the moment

So then you may be lucky or you may step into a problem one of the developers
coded into last night. If another customer does the same he might get the
next hot shot including the fixes for your problem...

So let them some time to mature changes and dont urge them to release version
which are between the normal ones.

I agree but there is one important omission you have forgotten to mention about leaving them time to mature the changes and that is it should only apply to issues they can reproduce on the test bench, issues they cannot reproduce on the test require a totally different approach to achieving a solution.

Thu Sep 08, 2011 6:29 pm

What i don't understand if the "bug ?" was fixed and i assume MT gave 5.17 to others to test, why we haven't read such good news on the forum from others?
The way it goes is like this:

1. You've a problem with the actual release
2. You mail to support@mikrotik.com with .rif
3. They see it may be a bug, do a patch to their hot development source tree
4. They give you the hot shot of the moment

So then you may be lucky or you may step into a problem one of the developers
coded into last night. If another customer does the same he might get the
next hot shot including the fixes for your problem...

So let them some time to mature changes and dont urge them to release version
which are between the normal ones.
I agree but there is one important omission you have forgotten to mention about leaving them time to mature the changes and that is it should only apply to issues they can reproduce on the test bench, issues they cannot reproduce on the test require a totally different approach to achieving a solution.

Yes. This could be done with a nv2_test package. They've done this with wireless test
packages earlier.

Fri Sep 09, 2011 9:52 am

are you guys talking about actual problems you have, or only about theory?

we only have 2-3 people in support with open tickets about wireless nv2 issues. if you are not one of them, don't blame mikrotik for not fixing your issue. most people use nv2 without issues. the discussion about the "bug" is about very specific issues that affect very few people.

Fri Sep 09, 2011 10:01 am

are you guys talking about actual problems you have, or only about theory?

we only have 2-3 people in support with open tickets about wireless nv2 issues. if you are not one of them, don't blame mikrotik for not fixing your issue. most people use nv2 without issues. the discussion about the "bug" is about very specific issues that affect very few people.

You're kidding. With 5.7 I'll do my next PTMP/nv2 tests. With all tests so far
I switched back to plain 802.11 as it performed better in terms of stability.

Fri Sep 09, 2011 10:04 am

what is stability? did you get disconnections, inconsistent signal, changing data rates? what's the ticket number?

Fri Sep 09, 2011 10:16 am

what is stability? did you get disconnections, inconsistent signal, changing data rates? what's the ticket number?

Instable data rates (going down into the kbit/s range) and instable latency.
I did not send a ticket. I've heard the same problems here in the forum so
I waited for nv2 to mature. It looks like it is working now for some here so
I do my next try with the next release as it promises to increased routing
performance, too.

WirelessRudy · Fri Sep 09, 2011 11:13 am

what is stability? did you get disconnections, inconsistent signal, changing data rates? what's the ticket number?
Instable data rates (going down into the kbit/s range) and unstable latency.
I did not send a ticket. I've heard the same problems here in the forum so
I waited for nv2 to mature. It looks like it is working now for some here so
I do my next try with the next release as it promises to increased routing
performance, too.

I think you have to give us a bit more info here. I am amongst others that persistently complained about NV2's issues in previous versions. I have been reading almost all post in this regard.
I found that not only for me, but for several others too, 5.6 definitely improved the wireless a lot to an almost complete solution.
If you still have the kind of problems you tell us you should give us more info. Maybe you just have other issues that have nothing to do with NV2.
A fresh pair of eyes into your configs might give some answers?

Fri Sep 09, 2011 11:43 am

what is stability? did you get disconnections, inconsistent signal, changing data rates? what's the ticket number?
Instable data rates (going down into the kbit/s range) and unstable latency.
I did not send a ticket. I've heard the same problems here in the forum so
I waited for nv2 to mature. It looks like it is working now for some here so
I do my next try with the next release as it promises to increased routing
performance, too.
I think you have to give us a bit more info here. I am amongst others that persistently complained about NV2's issues in previous versions. I have been reading almost all post in this regard.
I found that not only for me, but for several others too, 5.6 definitely improved the wireless a lot to an almost complete solution.
If you still have the kind of problems you tell us you should give us more info. Maybe you just have other issues that have nothing to do with NV2.
A fresh pair of eyes into your configs might give some answers?

Thanks for your offer. I'll start doing tests again with the upcoming 5.7.
I'll report back and let's see if things matured.
I've bad conditions as due to ETSI power restrictions I've customers with
weak signal even to a point where they drop off. Let's see how nv2
handles this compared to plain 802.11.
I've a wide range of AP-hardware out there starting with RB5xx,RB6xx,RB3xx,RB4xx.
Cards are most R52,R52nM since availability. CPEs start at RB1xx.

WirelessRudy · Fri Sep 09, 2011 12:02 pm

I've bad conditions as due to ETSI power restrictions I've customers with
weak signal even to a point where they drop off. Let's see how nv2
handles this compared to plain 802.11.

Well, here we already have a clue. NV2 needs relative stably connected clients. Preferably in the -50 to -70 range.
If some of your clients are in such a low signal range NV2 probably is not going to do it for you.
NV2 is TDMA which means every associated client is assigned with a sort of ´time slot´ to communicate. If now a client is disassociated because the link drops due poor signal, the AP has to acknowledge the disconnection and remove the timeslot it reserved for that CPE. Next time, if the client just got a bit more signal and wants to associate again, the AP has to arrange for a new timeslot in the sequence. It is clear that is not doing the whole TDMA process any good if this happens on a very regular base.
Under these situations legacy 802.11 (or nstreme) might indeed give better results.
Also because NV2 seems to be more prone to interferences than normal 802.11 and with low signals the link is prone to suffer more from interferences.

Fri Sep 09, 2011 12:30 pm

I've bad conditions as due to ETSI power restrictions I've customers with
weak signal even to a point where they drop off. Let's see how nv2
handles this compared to plain 802.11.
Well, here we already have a clue. NV2 needs relative stably connected clients. Preferably in the -50 to -70 range.
If some of your clients are in such a low signal range NV2 probably is not going to do it for you.
NV2 is TDMA which means every associated client is assigned with a sort of ´time slot´ to communicate. If now a client is disassociated because the link drops due poor signal, the AP has to acknowledge the disconnection and remove the timeslot it reserved for that CPE. Next time, if the client just got a bit more signal and wants to associate again, the AP has to arrange for a new timeslot in the sequence. It is clear that is not doing the whole TDMA process any good if this happens on a very regular base.
Under these situations legacy 802.11 (or nstreme) might indeed give better results.
Also because NV2 seems to be more prone to interferences than normal 802.11 and with low signals the link is prone to suffer more from interferences.

This might be the case. But keeping the signal in the -50 to -70 range is an ideal (lab) condition
in an ETSI country with 27db limit in 5,6. This are very short clear shots. If I would drop customers
with > -70 signal I would loose some hundred customers. So nv2 matures in a way it can handle this
difficult conditions or it is not the protocol I can use in my situation.
With 802.11 cpes can work up to -85 with fair behavior. Worse then -85 we say "don't do it" to
the customer.

steen · Sat Sep 10, 2011 12:22 am

Hello Folks!

NV2 two weeks now, so far not a single drop if link. Whole system is rock solid at all loads, we use ROS 5.6 all over. Also much reduced load on all AP:s and CPE:s, less than 1/3 than before. And yes, I am in middle of city like environment, much noice and obstacles, freznel links etc. Also I noticed som few distant CPE which had problems with dropouts before when using nstreme, now never dropout. Their Signal is about -68 to -87.

dzieva · Sat Sep 10, 2011 4:20 am

Hello Folks!

NV2 two weeks now, so far not a single drop if link. Whole system is rock solid at all loads, we use ROS 5.6 all over. Also much reduced load on all AP:s and CPE:s, less than 1/3 than before. And yes, I am in middle of city like environment, much noice and obstacles, freznel links etc. Also I noticed som few distant CPE which had problems with dropouts before when using nstreme, now never dropout. Their Signal is about -68 to -87.

Hi steen,

You are using dual chain, or only chain0?

Regards,
Dzieva

steen · Sat Sep 10, 2011 9:22 am

Hello Folks!

NV2 two weeks now, so far not a single drop if link. Whole system is rock solid at all loads, we use ROS 5.6 all over. Also much reduced load on all AP:s and CPE:s, less than 1/3 than before. And yes, I am in middle of city like environment, much noice and obstacles, freznel links etc. Also I noticed som few distant CPE which had problems with dropouts before when using nstreme, now never dropout. Their Signal is about -68 to -87.
Hi steen,

You are using dual chain, or only chain0?

Regards,
Dzieva

Hello Dzieva!
All is out of the box settings exept the authentication part and frequency.
We use only Wireless (Atheros AR5413) 20MHz BW, not yet 40MHz.

We do not have any "n" boards in production with chains.
In lab tests we used dual chains, not a problem for the month we were testing.

This is due to we have rebuild out entire infrastructure to do it, not an option at moment.

wolfeyes · Mon Sep 12, 2011 7:42 pm

Hello Folks!

NV2 two weeks now, so far not a single drop if link. Whole system is rock solid at all loads, we use ROS 5.6 all over. Also much reduced load on all AP:s and CPE:s, less than 1/3 than before. And yes, I am in middle of city like environment, much noice and obstacles, freznel links etc. Also I noticed som few distant CPE which had problems with dropouts before when using nstreme, now never dropout. Their Signal is about -68 to -87.
Hi steen,

You are using dual chain, or only chain0?

Regards,
Dzieva
Hello Dzieva!
All is out of the box settings exept the authentication part and frequency.
We use only Wireless (Atheros AR5413) 20MHz BW, not yet 40MHz.

We do not have any "n" boards in production with chains.
In lab tests we used dual chains, not a problem for the month we were testing.

This is due to we have rebuild out entire infrastructure to do it, not an option at moment.

Can you give us some tips regarding these out of the box settings gave you two weeks uptime without single drop on nv2?

chadd · Mon Sep 12, 2011 9:38 pm

We are still having disconnects even with the latest test packages, I have been sending support files to support so hopefully they get it figured out soon.

steen · Mon Sep 12, 2011 10:41 pm

Hello Folks!

Yet all working 100%, also during a heavy thunderstorm this weekend.

Here is the output for one sector and cpe. All we did was to activate the nv2 put a password on it and smile.
Note channel separation is important due to splatter and the lower noice immunity of TDMA.
Also my distributor Limmared confirms very high stability of NV2, he to has left nstreme.

Basestation settings:
name="wlan3" mtu=1500 mac-address=xx:xx:xx:xx:xx:xx arp=enabled disable-running-check=no
interface-type=Atheros AR5413 radio-name="xxxxxxxxxxxx" mode=ap-bridge ssid="xxxxxxxxxx" area=""
frequency-mode=manual-txpower country=sweden antenna-gain=0 frequency=5320 band=5ghz-a channel-width=20mhz
scan-list=default wireless-protocol=nv2 rate-set=default supported-rates-b=1Mbps,2Mbps,5.5Mbps,11Mbps
supported-rates-a/g=6Mbps,9Mbps,12Mbps,18Mbps,24Mbps,36Mbps,48Mbps,54Mbps basic-rates-b=1Mbps
basic-rates-a/g=6Mbps max-station-count=2007 distance=dynamic tx-power-mode=default noise-floor-threshold=default
nv2-noise-floor-offset=default periodic-calibration=default periodic-calibration-interval=60 burst-time=disabled
dfs-mode=none antenna-mode=ant-a wds-mode=disabled wds-default-bridge=none wds-default-cost=100
wds-cost-range=50-150 wds-ignore-ssid=no update-stats-interval=disabled bridge-mode=enabled
default-authentication=yes default-forwarding=yes default-ap-tx-limit=0 default-client-tx-limit=0
proprietary-extensions=post-2.9.25 wmm-support=disabled hide-ssid=no security-profile=steen2-5g1
disconnect-timeout=3s on-fail-retry-time=100ms preamble-mode=both compression=yes allow-sharedkey=no
station-bridge-clone-mac=00:00:00:00:00:00 tdma-period-size=2 nv2-queue-count=2 nv2-qos=default nv2-cell-radius=30
nv2-security=enabled nv2-preshared-key="xxxxxxxxxxx" hw-retries=10 frame-lifetime=0
adaptive-noise-immunity=client-mode hw-fragmentation-threshold=disabled hw-protection-mode=none
hw-protection-threshold=0 frequency-offset=0 rate-selection=legacy

cpe settings:
Flags: X - disabled, R - running
0 R name="wlan1" mtu=1500 mac-address=xx:xx:xx:xx:xx:xx arp=enabled disable-running-check=no interface-type=Atheros AR5413
radio-name="xxxxxxxxxxxx" mode=station ssid="xxxxxxxxxx" area="" frequency-mode=manual-txpower country=sweden
antenna-gain=0 frequency=5220 band=5ghz-a channel-width=20mhz scan-list=default wireless-protocol=nv2-nstreme
rate-set=default supported-rates-b=1Mbps,2Mbps,5.5Mbps,11Mbps
supported-rates-a/g=6Mbps,9Mbps,12Mbps,18Mbps,24Mbps,36Mbps,48Mbps,54Mbps basic-rates-b=1Mbps basic-rates-a/g=6Mbps
max-station-count=2007 distance=dynamic tx-power-mode=default noise-floor-threshold=default
nv2-noise-floor-offset=default periodic-calibration=default periodic-calibration-interval=60 burst-time=disabled
dfs-mode=none antenna-mode=ant-a wds-mode=disabled wds-default-bridge=none wds-default-cost=100 wds-cost-range=50-150
wds-ignore-ssid=no update-stats-interval=disabled bridge-mode=enabled default-authentication=yes
default-forwarding=yes default-ap-tx-limit=0 default-client-tx-limit=0 proprietary-extensions=post-2.9.25
wmm-support=disabled hide-ssid=no security-profile=steen2-5g1 disconnect-timeout=3s on-fail-retry-time=100ms
preamble-mode=both compression=no allow-sharedkey=no station-bridge-clone-mac=00:00:00:00:00:00 tdma-period-size=2
nv2-queue-count=2 nv2-qos=default nv2-cell-radius=30 nv2-security=enabled nv2-preshared-key="xxxxxxxxxxx"
hw-retries=4 frame-lifetime=0 adaptive-noise-immunity=none hw-fragmentation-threshold=disabled
hw-protection-mode=none hw-protection-threshold=0 frequency-offset=0 rate-selection=legacy

Regards //
// Peter Steen

chadd · Mon Sep 12, 2011 11:09 pm

Hello Folks!

Yet all working 100%, also during a heavy thunderstorm this weekend.

Just curious why you have Adaptive noise immunity set to client mode on the AP and don't have it set at all on the client?

Chadd

WirelessRudy · Tue Sep 13, 2011 2:54 am

Hello Folks!

Yet all working 100%, also during a heavy thunderstorm this weekend.

Just curious why you have Adaptive noise immunity set to client mode on the AP and don't have it set at all on the client?

Chadd

Probably because he uses the units ´out of the box´ as he calls it with minimum config settings.

I have the same question in relation to the use of authentication. It is on both AP and CPE set to default. Meaning if the NV2 security is not enabled it is not difficult for an intruder to enter his network and abuse it.
And if somebody would know the NV2 security key his network is all open.
It would be better to have a second (mac authentication) or even a 3rd level of security (fixed ARP table). Special in a city like environment it is only a matter of time before some starts to develop an interest in hacking his network. Might be a kid, might be a real criminal.

He also has several other settings that are either not used, or set and of no meaning:
- default forwarding is enabled on both AP and CPE. Unless you want your customers to communicate with each other this is better to be switched off. It could bring another security breach (virus spreading!) but it can also flood his network when users start communication with each other outside any traffic limiting process that usually only takes place at the border of his network.
- several 802.11 legacy setting are not set, so if AP for any reason has to switch back from NV2 to 802.11 legacy his network has by far optimum settings.
- yet he has a security profile set. This only has a meaning in legacy mode. Not in NV2

There are probably more small items that can be tweaked, but he says his networks runs fine, so maybe its ok than? But I would definitely set a lot more....

Muqatil · Tue Sep 13, 2011 4:16 pm

Just to add some points to NV2
It's been almost 6 months that we migrated all our network to NV2.
The migration was smooth and nice, we had no problems on clients. We had to replace some 133 (because we were using 4.16 at that time) but we had huge improvements
Nothing to complain.
I was following this thread but we didn't encounter all those problems... maybe because all our clients have at least 2.0 fresnel and signals between -50 and -75

Next step: 802.11n 2x2 PTMP!!!

steen · Wed Sep 14, 2011 9:11 pm

Hello Folks!

Yet all working 100%, also during a heavy thunderstorm this weekend.

Just curious why you have Adaptive noise immunity set to client mode on the AP and don't have it set at all on the client?

Chadd

As told, settings is out of the box, our distributor did configure our first devices (AP and CPE) years ago for nstreme, then we just cloned configuration.

If I change the settings, will I have better performance ?

steen · Wed Sep 14, 2011 9:27 pm

Hello Folks!

Yet all working 100%, also during a heavy thunderstorm this weekend.

Just curious why you have Adaptive noise immunity set to client mode on the AP and don't have it set at all on the client?

Chadd
Probably because he uses the units ´out of the box´ as he calls it with minimum config settings.

I have the same question in relation to the use of authentication. It is on both AP and CPE set to default. Meaning if the NV2 security is not enabled it is not difficult for an intruder to enter his network and abuse it.
And if somebody would know the NV2 security key his network is all open.
It would be better to have a second (mac authentication) or even a 3rd level of security (fixed ARP table). Special in a city like environment it is only a matter of time before some starts to develop an interest in hacking his network. Might be a kid, might be a real criminal.

He also has several other settings that are either not used, or set and of no meaning:
- default forwarding is enabled on both AP and CPE. Unless you want your customers to communicate with each other this is better to be switched off. It could bring another security breach (virus spreading!) but it can also flood his network when users start communication with each other outside any traffic limiting process that usually only takes place at the border of his network.
- several 802.11 legacy setting are not set, so if AP for any reason has to switch back from NV2 to 802.11 legacy his network has by far optimum settings.
- yet he has a security profile set. This only has a meaning in legacy mode. Not in NV2

There are probably more small items that can be tweaked, but he says his networks runs fine, so maybe its ok than? But I would definitely set a lot more....

I am very open to changes that can improve performance and security.

We did never use and do not plan to use 802.11, we have only used nstreme and now nv2, all working 100% perfect, not a drop in 3 weeks now.
Customers must communicate with eachother in our network. At all CPE we have firewall settings and pcq queues with limitations.
From beginning our network was meant to be open for all and free, when we moved to mikrotik devices we did introduce some security profile for nstreme and security for nv2. And yes, we are in city like environment.

In any case, network works 100% stable, never had a problem, and we have several critical business customers including our own company offices.

I learned adaptive noice immunity, how does this working, can it improve things ?
Is it a good idea to use mac acl and static arp tables, we have only permanent customers nowadays ?
Is there any more tweaking I can do ?

WirelessRudy · Thu Sep 15, 2011 12:52 am

OK,

ANI (Adaptive Noise Immunity) is an Atheros AR5212 and later chipset add on. Google on it but here is a link I found with in it another link to the Atheros patent doc on the technology: http://gregsowell.com/?p=3129
Off course you set for client only in the client, and for `AP and client` in the AP.

Authentication:
It won't make the network more stable, it is more an level in security.
By setting the AP's mac address in the ´connect-to´ list of the CPE you make sure that the CPE is only trying to associate with that AP only. In your setting an abuser/hijacker/intruder only needs to setup an AP that sends in the same Freq. and with the same SSID as yours and if his signal is stronger there is a good change your client CPE will jump over to his AP and your client is basically connected to somebody else's network. This is a clear security breach.
In setting the ´connect-to´ with a mac address your offender also needs to clone the mac of your AP so he first needs to sniff it. Not complicated but just an extra step on the security ladder.

In setting the ´access list´ in the AP you make sure only these mac addresses of your clients that are known and allowed will associate to your AP . Off course again an offender can try to clone the mac. of the client, but yet again, you step up the security with another (small level).

If you now also in the ARP list make mac-IP combinations fixed, and disable the auto function, in case an offender would now clone a mac, he also needs to give his unit the proper same IP as your CPE. If now both your client's CPE and the offender's CPE try to use same IP because they are shown both with same mac, it will be obvious you get strange behaviours on the network and if the network operator not notices, the client will definitely do!

If you never intend to use legacy 802.11 any more all the settings belonging to them can be left behind. But at times you might want to revert back to it with your network. If in this case your legacy settings are wrong or poor it might give problems for units to stay associated to the network and due ´flickering´ CPE's trying to associate and losing it again your network might become very unstable.

802.11 legacy settings that have no meaning in NV2 are (not complete):
- security profile
- Hw. Retries
- Hw. Fragmentation Threshold
- Hw. Protection Mode (RTS/CTS)
- Frame Lifetime
- Preamble (this I am not 100% sure off. MT has't answered my questions about it.)
- Disconnect Time-out
- On Fail Retry Time

In case of working with 10 or 5Ghz bandwidth in 5Ghz band I also would set the ´wireless scan list´. This shortens the time a CPE needs to scan for the freq. his assigned AP is working in. When connectivity is an issue this helps a lot in keeping CPE's as short as possible disconnected fm. AP. Instead of scanning the whole band, which can take noticeable time, CPE is already tuned to the desired frequency and can associate immediately.

Although most of these tweaks won't necessarily increase your network's stability if it is already good, it will help it keeping more stable when the wireless interconnectivity has issues. Special when you for what ever reason have to go back to legacy or nstreme mode for a while.

More important, relying on one wireless network security level only (NV2 security) is marginal. If you have a fixed customer network you can step up security level more. Maybe you never will benefit from it, but that is the same as a country having an army while there is never a war.

One thing that might improve your network stability if appropriate could also be setting the data rates fixed in the AP. Under marginal circumstances where radio's could have difficulties maintaining highest data rates setting these lower and fix them keeps your network much more stable under these marginal circumstances (snow storm, heavy rain, electrical storm, magnetic storm, external source of radio disturbances etc.)
As long as your chosen rate is set to double or next step higher than double than what the contractual client max. speed is you are not creating a bottle neck.

Thu Sep 15, 2011 9:53 am

802.11 legacy settings that have no meaning in NV2 are (not complete):
- security profile
- Hw. Retries
- Hw. Fragmentation Threshold
- Hw. Protection Mode (RTS/CTS)
- Frame Lifetime
- Preamble (this I am not 100% sure off. MT has't answered my questions about it.)
- Disconnect Time-out
- On Fail Retry Time

You're sure on "Disconnect Time-out" and "On Fail Retry time"?

WirelessRudy · Thu Sep 15, 2011 12:53 pm

802.11 legacy settings that have no meaning in NV2 are (not complete):
- security profile
- Hw. Retries
- Hw. Fragmentation Threshold
- Hw. Protection Mode (RTS/CTS)
- Frame Lifetime
- Preamble (this I am not 100% sure off. MT has't answered my questions about it.)
- Disconnect Time-out
- On Fail Retry Time
You're sure on "Disconnect Time-out" and "On Fail Retry time"?

I asked MT and they told me all these settings were of no meaning in NV2.
In TDMA AP assigns stations time slots to communicate. How long, what order (compared to other stations) etc.
How this actually has effect on these two I am not 100% sure of. I haven't test it and in normal use I don't see a difference.

I can imagine both. It still has a meaning in NV2, or not.
I asked MT in the early days of NV2 and actually got the ´feeling´ they didn't fully have all the ins and outs of it covered. So maybe their answer at the time was not completely right.

Maybe somebody else can shine more light on this?

n21roadie · Thu Sep 15, 2011 1:26 pm

802.11 legacy settings that have no meaning in NV2 are (not complete):
- security profile
- Hw. Retries
- Hw. Fragmentation Threshold
- Hw. Protection Mode (RTS/CTS)
- Frame Lifetime
- Preamble (this I am not 100% sure off. MT has't answered my questions about it.)
- Disconnect Time-out
- On Fail Retry Time
You're sure on "Disconnect Time-out" and "On Fail Retry time"?
I asked MT and they told me all these settings were of no meaning in NV2.
In TDMA AP assigns stations time slots to communicate. How long, what order (compared to other stations) etc.
How this actually has effect on these two I am not 100% sure of. I haven't test it and in normal use I don't see a difference.

I can imagine both. It still has a meaning in NV2, or not.
I asked MT in the early days of NV2 and actually got the ´feeling´ they didn't fully have all the ins and outs of it covered. So maybe their answer at the time was not completely right.
Maybe somebody else can shine more light on this?

I mentioned this before and one would assume MT would know how the NV2 proprietary protocol interacts with other wireless setting; they should have just greyed out setting having no effect when NV2 is enabled and stop all this unnecessary guess work?

WirelessRudy · Thu Sep 15, 2011 2:30 pm

I mentioned this before and one would assume MT would know how the NV2 proprietary protocol interacts with other wireless setting; they should have just greyed out setting having no effect when NV2 is enabled and stop all this unnecessary guess work?

I can't agree more.
It would help shorten the ´learning curve´ a lot for starters and avoids lots of confusion.
Both MT and users would benefit greatly from that.

steen · Thu Sep 15, 2011 8:03 pm

OK,

ANI (Adaptive Noise Immunity) is an Atheros AR5212 and later chipset add on. Google on it but here is a link I found with in it another link to the Atheros patent doc on the technology: http://gregsowell.com/?p=3129
Off course you set for client only in the client, and for `AP and client` in the AP.

Authentication:
It won't make the network more stable, it is more an level in security.
By setting the AP's mac address in the ´connect-to´ list of the CPE you make sure that the CPE is only trying to associate with that AP only. In your setting an abuser/hijacker/intruder only needs to setup an AP that sends in the same Freq. and with the same SSID as yours and if his signal is stronger there is a good change your client CPE will jump over to his AP and your client is basically connected to somebody else's network. This is a clear security breach.
In setting the ´connect-to´ with a mac address your offender also needs to clone the mac of your AP so he first needs to sniff it. Not complicated but just an extra step on the security ladder.

In setting the ´access list´ in the AP you make sure only these mac addresses of your clients that are known and allowed will associate to your AP . Off course again an offender can try to clone the mac. of the client, but yet again, you step up the security with another (small level).

If you now also in the ARP list make mac-IP combinations fixed, and disable the auto function, in case an offender would now clone a mac, he also needs to give his unit the proper same IP as your CPE. If now both your client's CPE and the offender's CPE try to use same IP because they are shown both with same mac, it will be obvious you get strange behaviours on the network and if the network operator not notices, the client will definitely do!

If you never intend to use legacy 802.11 any more all the settings belonging to them can be left behind. But at times you might want to revert back to it with your network. If in this case your legacy settings are wrong or poor it might give problems for units to stay associated to the network and due ´flickering´ CPE's trying to associate and losing it again your network might become very unstable.

802.11 legacy settings that have no meaning in NV2 are (not complete):
- security profile
- Hw. Retries
- Hw. Fragmentation Threshold
- Hw. Protection Mode (RTS/CTS)
- Frame Lifetime
- Preamble (this I am not 100% sure off. MT has't answered my questions about it.)
- Disconnect Time-out
- On Fail Retry Time

In case of working with 10 or 5Ghz bandwidth in 5Ghz band I also would set the ´wireless scan list´. This shortens the time a CPE needs to scan for the freq. his assigned AP is working in. When connectivity is an issue this helps a lot in keeping CPE's as short as possible disconnected fm. AP. Instead of scanning the whole band, which can take noticeable time, CPE is already tuned to the desired frequency and can associate immediately.

Although most of these tweaks won't necessarily increase your network's stability if it is already good, it will help it keeping more stable when the wireless interconnectivity has issues. Special when you for what ever reason have to go back to legacy or nstreme mode for a while.

More important, relying on one wireless network security level only (NV2 security) is marginal. If you have a fixed customer network you can step up security level more. Maybe you never will benefit from it, but that is the same as a country having an army while there is never a war.

One thing that might improve your network stability if appropriate could also be setting the data rates fixed in the AP. Under marginal circumstances where radio's could have difficulties maintaining highest data rates setting these lower and fix them keeps your network much more stable under these marginal circumstances (snow storm, heavy rain, electrical storm, magnetic storm, external source of radio disturbances etc.)
As long as your chosen rate is set to double or next step higher than double than what the contractual client max. speed is you are not creating a bottle neck.

Thank you very much! Very fine suggestions, we will start to fine tune our network with the suggested settings, at least the security parts and the onees that makes devices connect faster to AP:s. I have been thinking about several of them. Anyhow we did never change anything after our distributor helped us setting up our first basestations her years ago (2007), all has worked 100% to our satisfaction if we exclude some of my nice mistakes(2009) which is not MT fault. Our motto is do not change things that work.

We have been very careful with two things all time, first channel separation between sectors and AP:s and secondary, signal levels + signal quality at customer CPE must be as high as possible, allways keeping S/N > 40db.

steen · Thu Sep 15, 2011 8:07 pm

I mentioned this before and one would assume MT would know how the NV2 proprietary protocol interacts with other wireless setting; they should have just greyed out setting having no effect when NV2 is enabled and stop all this unnecessary guess work?
I can't agree more.
It would help shorten the ´learning curve´ a lot for starters and avoids lots of confusion.
Both MT and users would benefit greatly from that.

I agree fully, all winbox bars and knobs are comfusing at least for me, and yes I am kind of beginner here since we did have MC consultants setting things up for us. Would be most helpful to grey out some of them dependent on what you pick.

wolfeyes · Wed Oct 05, 2011 10:37 pm

Hi All,

We've been using nv2 on 5GHz-only-N more. For some bizarre reason mode 5GHz-A/N created disconnection problems.
Channel width set to 20/40MHz HT Below and we achieve 1 week periods uptime without a drop.
Signal levels on sxt cpes are -65 to -76 (and a single sxt with -80).

For Hw.Retries setting I've also read that this does not makes sense in nv2 but after setting to 9 or 10 then links become more stable.
Maybe latest releases improved stability performance and this setting is irrelevant.

Furthermore apart of the nv2 proprietary pre-shared key setting, clients are also authenticated using radius over pppoe (which also provides isolation).

In the current setup we utilize 12 clients per sector without congestion problems.
Is there any way to calculate and determine the maximum number of clients can be connected on a single sector??? (Without interference problems, data collisions etc)

WirelessRudy · Thu Oct 06, 2011 1:34 am

Hi All,

We've been using nv2 on 5GHz-only-N more. For some bizarre reason mode 5GHz-A/N created disconnection problems.

Search for "disconnections" and NV2" in this forum and you'll find tons of posts about it and what to do to avoid them as much as possible.

For Hw.Retries setting I've also read that this does not makes sense in nv2 but after setting to 9 or 10 then links become more stable.

The have no effect on NV2.

In the current setup we utilize 12 clients per sector without congestion problems.
Is there any way to calculate and determine the maximum number of clients can be connected on a single sector??? (Without interference problems, data collisions etc)

ROS can handle up 2007 stations.
Apart from that, is it depending on many factors:
Type of routerboard
Type of antenna
Type of clients
Distance between AP and clients
How much traffic up and down to and from clients.
Spectrum, quit or lots of other signals around that possibly could create interferences or have an effect on the noisefloor
Signal strenghts and SNR levels.
Protocol used
Bandwidth used
Etc. Etc.

I use up to 35 clients with 4/5Mb assigned traffic on a rb800 and I've heard guys going up to 50 or even higher.
I think I'll go to 40-45 but I need to see the average max. sustained CPU load to see how far I can go. When CPU runs for prolonged times (due heavy traffic) in ranges of 50-70% I would start thinking of upgrading my network.

wolfeyes · Thu Oct 06, 2011 11:44 am

I use up to 35 clients with 4/5Mb assigned traffic on a rb800 and I've heard guys going up to 50 or even higher.
I think I'll go to 40-45 but I need to see the average max. sustained CPU load to see how far I can go. When CPU runs for prolonged times (due heavy traffic) in ranges of 50-70% I would start thinking of upgrading my network.

OK.. RB800 is the absolute board if you can afford price.

We use 433 with R52Hn.
Which miniPCI adapter do you use?
And what type of sector antenna?

WirelessRudy · Thu Oct 06, 2011 8:15 pm

OK.. RB800 is the absolute board if you can afford price.
We use 433 with R52Hn.
Which miniPCI adapter do you use?
And what type of sector antenna?

I also started with 433's and 433AH's. Lots of us start small and cheap. But when you grow and AP are being populated more and more you'll learn that re-investing your money is going to be worth it.

Anyway, for just a couple of CPE's a rb433 is fine. I also use the R52Hn in some instances (although they ´burn´ easy) and further I use a whole range of mikrotik cards. I basically bought every available model over the years.

In relation to the sector antenna's; Here the same, I learned over time that its better to spend a couple of more bucks on good stuff than buy the cheapest I came across.
Also learned to take a good look at what the exact specs are of an antenna. Not only look at the gain, "the higher, the better" was my credo. But in fact I learned that at times it missed the purpose (literally!).
High gain sector usually have very narrow vertical beam so their footprint becomes smaller and thus smaller area can be served with the higher signal. More units miss that boat......

For example; I learned that the ubnt Airmax sectors are actually a big disappointment.
On the other hand, the Elboxrf antenna's with reduced side lob are very good. (http://www.elboxrf.com/EN/index.html)

Further more, it depends how many clients, at what distances, in what kind of terrain, from where etc. etc. you want to serve to pick the right antenna. Off course budget is also a factor, not seldom THE limiting factor!

(In the present "Internet era" it is easy to start searching for the best prices. You'll be amazed how much difference there can be in price for same product. Sometimes more than 100%!)

If your aim is to become a professional WISP than it is worthwhile to invest in good antenna's and start with cheaper boards. The antenna's have a much longer life-cycle than boards. Boards and software are being updated all the time, antenna's can go for many years as long as you don't swap to other frequency bands....

wolfeyes · Mon Nov 14, 2011 2:56 pm

Hi WirelessRudy! Back again....

Which is the typical distance between your clients and central AP? (Max?)
Can this distance affect total AP capacity in terms of clients count (if yes how?) or this is just depended on signal and noise levels?
(Of course as mentioned capacity affected by type of routerboard , type of antennas, type of clients etc...)
By all means talking about nv2 implementations...

Mon Nov 14, 2011 4:19 pm

Steen and others. There are drastic improvements in Nv2 which many people are already confirming. Write to support to get the v5.9 version with new Nv2

dnyl · Mon Nov 14, 2011 10:43 pm

Steen and others. There are drastic improvements in Nv2 which many people are already confirming. Write to support to get the v5.9 version with new Nv2

Where can i download 5.9?

cbrown · Mon Nov 14, 2011 11:16 pm

Write to support to get the v5.9 version with new Nv2

WirelessRudy · Mon Nov 14, 2011 11:25 pm

Hi WirelessRudy! Back again....

Which is the typical distance between your clients and central AP? (Max?)
Can this distance affect total AP capacity in terms of clients count (if yes how?) or this is just depended on signal and noise levels?
(Of course as mentioned capacity affected by type of routerboard , type of antennas, type of clients etc...)
By all means talking about nv2 implementations...

I have two 'typical' situations. One is in an heavy congested area where many clients are around in a circle of less then 2000mtrs. They are served with 5 AP's and even so some of them are almost 'full'. Interferences have been an factor to work with from the beginning...
Second instance is in an more open valley situation where I have several AP's. They all serve clients from some hundred of meters to some 5 km in general. But some rare clients are even served over 15km!

By using higher or lower gain antenna's/devices I try to get the signals of all AP's associated clients within a range of -50 to -75 in the valley where in the urbanised area some clients are -35 and some -78 (even with 5 AP's some are partially obstructed from LOS) Its in the last year and since NV2 I am changing CPE units for stronger or weaker ones on clients to get a smaller spread of signal strenghts. The goal in all situations is to get signals between -45 and -70. That works best with NV2 and prevents also best against interferences.

steen · Thu Nov 17, 2011 11:29 pm

Steen and others. There are drastic improvements in Nv2 which many people are already confirming. Write to support to get the v5.9 version with new Nv2

Ok thanks, I wait till it is released officially

I have learned not to be the first one and not be last one trying out the new. 5.6 work very well in our environments exept cpu goes 100% in some FLASH operations now and then in our routers.

Chronicaust · Sat May 12, 2012 7:20 am

Trying Nv2 on our first AP. Version 5.14 and looks very promising... will probably migrate all our cpe's to mikrotik after seeing this. Went from being able to push about 10-12 meg with good latency through a single chain G-mode 2.4ghz AP in 802.11 to being able to push 18-20 meg with good latency. Signals range from 60-73 on client rx with 9 clients right now. TDMA period set to 4 and cell radius set to 10.

steen · Mon May 14, 2012 11:48 am

Hello Folks!

We are pumping ptmp data through our nv2 "4 sector basestations" (RB600a RoS5.14) at a rate up to 35Mbit/s then CPU is 100%

latency is very low, 5-6ms and peaks up to 25ms. Standard AR5413 boards are used, and 5GHz band.

Link uptimes are till next RoS upgrade comes.

For success with NV2 as we understand it:
Use 5GHz band to have several channels to pick among.
Do not overpower, put bigger antenna instead.
Absolutely NO OVERLAPPING at all between channels, there must be space between!
Channel separation is very important in TDMA and margin for splatter. Cavity channel filters not tested, can improve a lot folks say.
High S/N ratio (we have 45-70) is also very important not to let in noice from nereby channels.
Directional antennas and polarisation is also cruical.
Put antennas high, we do put our CPE:s in customer TV antenna mast and similar.

Make frequency scans before and at regular basis.

steen · Mon May 14, 2012 12:51 pm

Trying Nv2 on our first AP. Version 5.14 and looks very promising... will probably migrate all our cpe's to mikrotik after seeing this. Went from being able to push about 10-12 meg with good latency through a single chain G-mode 2.4ghz AP in 802.11 to being able to push 18-20 meg with good latency. Signals range from 60-73 on client rx with 9 clients right now. TDMA period set to 4 and cell radius set to 10.

Impressive!
All our NV2 settings are out of the box, 100% stable in our "city like" environment now for 4-5 years.
We have between 4 - 11 CPE:s (RB411) to each 4 sector basestations (RB600) using directional antennas.
All is a IP routed network, no bridging etc. just plain access points and ip + routing on top.

We did migrate all our AP:s and CPE:s to mikrotik a couple of years ago. It has been a 100% success story I can tell! We also added monitoring program "the dude" upon it, then whole system become very nice to work with.

steen · Thu Nov 22, 2012 8:45 pm

One year plus later report!

All is still very stable!

We now got gigabit internet at basastations, our rb411 cpe:s devices is pumping data up to 20-25Mbit/s without any hassle, cpu 40%-45% and sxt goes up to 35Mbit/s and basastation with standard mt r52 radioboards. Pingtimes is less than 16ms all time.

steen · Sat Mar 09, 2013 10:13 pm

Hello Folks!

We got gigabit internet to our sites now and we want out customers to get more bang for the buck.

Problem is we do not have R52nm radioboards in all our RB411 and basestations which also uses single antenna, neither is sextant and sxt on very many places either. It will come afte some time, by phasing out older devices.

Meanwhile I want to get as much as possible so we today tested to use 40MHz channels instead of standard 20MHz on R52 based routers.

Changing first the R52 based CPE:s to 40MHz and last the basestation, then bang all boards directly connect at 40MHz and synced up to 108Mbit/s. TX/RX Signal strength= -38/-37 dBm, Signal To Noise=54 dB, TX/RX CCQ 100/100 %

We did then do bandwith test using TP-TEST on open internet, speed result was Upload 21Mbit/s Download 22Mbit/s.

That was a disappointing test result, I have expected at least 35-40Mbit/s. I do not know it it is some limitation in the RB411 boards or it is just like this.

This is not better than using 20MHz with the R52 radios, I have had exactly same result using them, exept Signal to Noise = 64dB and better Signal strength. Upload = 20Mbit/s Download 21Mbit/s.

From last summer when we started to implement SXT and SEXTANT in same networks as R52 based RB411 single antenna using 20MHz, we recieved 35Mbit/s Upload and 33Mbit/s Download. This could indicate that it is some limitation on the R411 boards or radios on SXT and SEXTANT is faster by some reason.

SXT and SEXTANT perform much better than RB411 + R52 althought we do not use 802.11n.

So for me it is no big deal to bend more on the R52 based boards and basestations.
We will let things be as is and speed up the replacement of older stuff with sextant and sxt.

kraic · Fri Feb 27, 2015 9:15 am

Hello,
I have bought 4 SXT ac, and planing using it as one AP to cover 120 degrees.
I worked with nv2 a lot before, for links from 1km to 55km. Now I wonna use it on ptmp.
What suggestions can You give me, for best results. Maybe some rate settings, TDMA settings, burst time, some chains settings. ?

I will use nv2, only-N, 20MHz channel, signals between -50 and -70dBm, both pol, and users will be 5/2 Mbps and 8/3 Mbps.

Thank You

WirelessRudy · Sun May 15, 2016 6:58 pm

@steen
Where are you today with your PtMP deployment? Still MT based and NV2? Would be interesting to know since capacity demand and supply have gone up (supply gone cheaper) since last posts in this tread. Lately I see many of us in the forum run into this limit of MT AP's. Hard to get more then 50Mbps aggregated traffic from clients.

We have several MtMP's with 10 up to 30 Mikrotik CPE's on them and even when the worst cpe's are within -50 - -60dB signal range I cannot generate more than 50Mbps to a client. At the same time I can 'push' another 150Mbps to the Netmetal that is serving these clients. So its not the backbone.
We tuned a lot on the NV2 settings, but it hardly makes a difference.

I was wondering how you managed the Mikrotik PtMP so far.....
Did you do anything on QoS at AP or CPE level?

WirelessRudy · Thu May 19, 2016 12:25 am

One year plus later report!

All is still very stable!

We now got gigabit internet at basastations, our rb411 cpe:s devices is pumping data up to 20-25Mbit/s without any hassle, cpu 40%-45% and sxt goes up to 35Mbit/s and basastation with standard mt r52 radioboards. Pingtimes is less than 16ms all time.

And where are you now? Still with MT? Still performing?

steen · Sat May 21, 2016 11:02 am

One year plus later report!

All is still very stable!

We now got gigabit internet at basastations, our rb411 cpe:s devices is pumping data up to 20-25Mbit/s without any hassle, cpu 40%-45% and sxt goes up to 35Mbit/s and basastation with standard mt r52 radioboards. Pingtimes is less than 16ms all time.
And where are you now? Still with MT? Still performing?

Hello!

Yes, we are still going strong, all works to satisfaction. We also have introduced several SXT 5 ac, QRT 5 and SEXTANT to get higher speeds in ptmp. We achieve easily sustainable speeds of 80-90Mbit/s in such networks and yet everything is stable, peaks up to 150Mbit/s has been observed. We do indeed have many RB411 based devices at customer's, we swap them to newer devices as they fail or customer experiences any problem.

2/3 of the times customers complains, it is their home router like some old netgear or drink device, that needed to be upgraded to a newer model. The rest of cases is something we missed during a firmware upgrade or in some few cases (3 cases to be exact) a mikrotik device failed due to thunder strike.

So conclusion is: nv2 and mikrotik is a success story!

WirelessRudy · Sat May 21, 2016 11:29 am

One year plus later report!

All is still very stable!

We now got gigabit internet at basastations, our rb411 cpe:s devices is pumping data up to 20-25Mbit/s without any hassle, cpu 40%-45% and sxt goes up to 35Mbit/s and basastation with standard mt r52 radioboards. Pingtimes is less than 16ms all time.
And where are you now? Still with MT? Still performing?
Hello!

Yes, we are still going strong, all works to satisfaction. We also have introduced several SXT 5 ac, QRT 5 and SEXTANT to get higher speeds in ptmp. We achieve easily sustainable speeds of 80-90Mbit/s in such networks and yet everything is stable, peaks up to 150Mbit/s has been observed. We do indeed have many RB411 based devices at customer's, we swap them to newer devices as they fail or customer experiences any problem.

2/3 of the times customers complains, it is their home router like some old netgear or drink device, that needed to be upgraded to a newer model. The rest of cases is something we missed during a firmware upgrade or in some few cases (3 cases to be exact) a mikrotik device failed due to thunder strike.

So conclusion is: nv2 and mikrotik is a success story!

Ok, that's nice!
How 'deep' is your network, seen from AC? Xms-tree alike, 2 levels, 3, 4?
How is you QoS made? At the AC only? Or also at AP and/or CPE level?

Reasons for asking is that we have a full MT network, up to 7 levels deep. Most of the AP's won't see no more than 60Mb aggregated client traffic in 20Mhz bands. Which is a bit disappointing if many other brands claim the be able to run many times more. 20 clients with 25Mb? We can only dream of something. 20 x 10 is already a problem for us......

Sat May 21, 2016 3:24 pm

And where are you now? Still with MT? Still performing?
Hello!

Yes, we are still going strong, all works to satisfaction. We also have introduced several SXT 5 ac, QRT 5 and SEXTANT to get higher speeds in ptmp. We achieve easily sustainable speeds of 80-90Mbit/s in such networks and yet everything is stable, peaks up to 150Mbit/s has been observed. We do indeed have many RB411 based devices at customer's, we swap them to newer devices as they fail or customer experiences any problem.

2/3 of the times customers complains, it is their home router like some old netgear or drink device, that needed to be upgraded to a newer model. The rest of cases is something we missed during a firmware upgrade or in some few cases (3 cases to be exact) a mikrotik device failed due to thunder strike.

So conclusion is: nv2 and mikrotik is a success story!
Ok, that's nice!
How 'deep' is your network, seen from AC? Xms-tree alike, 2 levels, 3, 4?
How is you QoS made? At the AC only? Or also at AP and/or CPE level?

Reasons for asking is that we have a full MT network, up to 7 levels deep. Most of the AP's won't see no more than 60Mb aggregated client traffic in 20Mhz bands. Which is a bit disappointing if many other brands claim the be able to run many times more. 20 clients with 25Mb? We can only dream of something. 20 x 10 is already a problem for us......

nv2 works reliable but dont scale. We dont see this 80-90MBit/s as soon there are more than 3-4 CPEs connected. And we dont see this with tcp. We always have a big difference between UDP and TCP Speeds with nv2. As you do backhauls with nv2 this sums up. We see this getting better with newer ROS releases.

We use different vendors and see how their promises come and go

). We're enthusiastic at the beginning and as time goes by most products dont hold up to their claims.

Esp. with backhauls we see wifi based products suffer somehow. So get rid of them in the center of your network. They are ok at the leaves. But 7 levels deep of wifi-based backhaul you'll never see good results regardless what vendor you use. There are some 5 GHz Products which are not wifi-based which do a very good job. But regardless what vendors claim. Full-Duplex Licensed links are far superior for backhaul. Reducing latency at the center links boosts your whole network.

WirelessRudy · Sat May 21, 2016 3:55 pm

Hello!

Yes, we are still going strong, all works to satisfaction. We also have introduced several SXT 5 ac, QRT 5 and SEXTANT to get higher speeds in ptmp. We achieve easily sustainable speeds of 80-90Mbit/s in such networks and yet everything is stable, peaks up to 150Mbit/s has been observed. We do indeed have many RB411 based devices at customer's, we swap them to newer devices as they fail or customer experiences any problem.

2/3 of the times customers complains, it is their home router like some old netgear or drink device, that needed to be upgraded to a newer model. The rest of cases is something we missed during a firmware upgrade or in some few cases (3 cases to be exact) a mikrotik device failed due to thunder strike.

So conclusion is: nv2 and mikrotik is a success story!
Ok, that's nice!
How 'deep' is your network, seen from AC? Xms-tree alike, 2 levels, 3, 4?
How is you QoS made? At the AC only? Or also at AP and/or CPE level?

Reasons for asking is that we have a full MT network, up to 7 levels deep. Most of the AP's won't see no more than 60Mb aggregated client traffic in 20Mhz bands. Which is a bit disappointing if many other brands claim the be able to run many times more. 20 clients with 25Mb? We can only dream of something. 20 x 10 is already a problem for us......
nv2 works reliable but dont scale. We dont see this 80-90MBit/s as soon there are more than 3-4 CPEs connected. And we dont see this with tcp. We always have a big difference between UDP and TCP Speeds with nv2. As you do backhauls with nv2 this sums up. We see this getting better with newer ROS releases.

We use different vendors and see how their promises come and go ). We're enthusiastic at the beginning and as time goes by most products dont hold up to their claims.

Esp. with backhauls we see wifi based products suffer somehow. So get rid of them in the center of your network. They are ok at the leaves. But 7 levels deep of wifi-based backhaul you'll never see good results regardless what vendor you use. There are some 5 GHz Products which are not wifi-based which do a very good job. But regardless what vendors claim. Full-Duplex Licensed links are far superior for backhaul. Reducing latency at the center links boosts your whole network.

OK. Thanks for the info.
With 6 (I said "7" but in fact its "6") levels deep I mean to say that some client only get data if this data has travelled over 5 consecutive back hauls and the last wireless shot is the AP-CPE network. These are only a handful of clients though. The bulk of our clients are behind only 3 or less back hauls, so 4 or less wireless shots.
In deed we found the consecutive package losses en ping delays sum up making it hard to have the network perform well under heavy load of traffic. We have some AP's serving 30+ clients and some of these are entitled to get 20Mb to them (it that happens).
Recently we made 2 ospf simulated duplex links on two heavy used pipes (100 to 200mbps client traffic) and it did improve the latency.
Just last night I finished testing this new vendor's 60Ghz link for out main internal backbones that have to carry the bulk (90%) of our clients traffic and although there were several issues with the firmware I could have a sustained throughput of 550Mbps down and at the same 80Mb upload tcp traffic generated by 3 NetMetals connecting to 2 CCR's on the other end. Ping times were around 10-15ms but this was while the link was pushed to the max. Soon we dropped traffic to say 80% of these figures ping fell back to 1-2ms and if traffic falls back even further the ping went to 0-1ms.

The intention is now to replace the heavy used 5Ghz back hauls by these 60Ghz links for our 3 most important back-hauls that all connect directly to the core of our network. The idea is we should improve the rest of the more remote network's traffic a lot too since we sort of 'push' the fiber quality link towards the edge of our working core. Within this core (an urbanized area with 170+ clients, 5 AP's and 7 back hauls leaving) we will now free 180Mhz of spectrum (1 x 80, 3 x 40Mhz) which will then benefit the AP's in this urbanization.
The aim is to offer clients top speeds of 25Mb off these 5 AP's.

I have done one test on a AP with 4 clients simultaneously downloading from an Netmetal AP (omni antenna, all signals -50dBm max.) in a 20Mhz bandwidth. The AP itself still served 25 other clients (some of them using the internet).
I could push the aggregated throughput of the AP to just over 75Mbps. Cpu of the Netmetal stayed around 30% max and during this test I could just pull 150Mbps from the AC router towards this AP with the build in bandwidth test. (tcp traffic)

So I do not know what is actually withholding the AP from pushing more to its clients but so far not even that bad. But it could be much better imho. The question is only how....

Sat May 21, 2016 6:17 pm

Ok, that's nice!
How 'deep' is your network, seen from AC? Xms-tree alike, 2 levels, 3, 4?
How is you QoS made? At the AC only? Or also at AP and/or CPE level?

Reasons for asking is that we have a full MT network, up to 7 levels deep. Most of the AP's won't see no more than 60Mb aggregated client traffic in 20Mhz bands. Which is a bit disappointing if many other brands claim the be able to run many times more. 20 clients with 25Mb? We can only dream of something. 20 x 10 is already a problem for us......
nv2 works reliable but dont scale. We dont see this 80-90MBit/s as soon there are more than 3-4 CPEs connected. And we dont see this with tcp. We always have a big difference between UDP and TCP Speeds with nv2. As you do backhauls with nv2 this sums up. We see this getting better with newer ROS releases.

We use different vendors and see how their promises come and go ). We're enthusiastic at the beginning and as time goes by most products dont hold up to their claims.

Esp. with backhauls we see wifi based products suffer somehow. So get rid of them in the center of your network. They are ok at the leaves. But 7 levels deep of wifi-based backhaul you'll never see good results regardless what vendor you use. There are some 5 GHz Products which are not wifi-based which do a very good job. But regardless what vendors claim. Full-Duplex Licensed links are far superior for backhaul. Reducing latency at the center links boosts your whole network.
OK. Thanks for the info.
With 6 (I said "7" but in fact its "6") levels deep I mean to say that some client only get data if this data has travelled over 5 consecutive back hauls and the last wireless shot is the AP-CPE network. These are only a handful of clients though. The bulk of our clients are behind only 3 or less back hauls, so 4 or less wireless shots.
In deed we found the consecutive package losses en ping delays sum up making it hard to have the network perform well under heavy load of traffic. We have some AP's serving 30+ clients and some of these are entitled to get 20Mb to them (it that happens).
Recently we made 2 ospf simulated duplex links on two heavy used pipes (100 to 200mbps client traffic) and it did improve the latency.
Just last night I finished testing this new vendor's 60Ghz link for out main internal backbones that have to carry the bulk (90%) of our clients traffic and although there were several issues with the firmware I could have a sustained throughput of 550Mbps down and at the same 80Mb upload tcp traffic generated by 3 NetMetals connecting to 2 CCR's on the other end. Ping times were around 10-15ms but this was while the link was pushed to the max. Soon we dropped traffic to say 80% of these figures ping fell back to 1-2ms and if traffic falls back even further the ping went to 0-1ms.

The intention is now to replace the heavy used 5Ghz back hauls by these 60Ghz links for our 3 most important back-hauls that all connect directly to the core of our network. The idea is we should improve the rest of the more remote network's traffic a lot too since we sort of 'push' the fiber quality link towards the edge of our working core. Within this core (an urbanized area with 170+ clients, 5 AP's and 7 back hauls leaving) we will now free 180Mhz of spectrum (1 x 80, 3 x 40Mhz) which will then benefit the AP's in this urbanization.
The aim is to offer clients top speeds of 25Mb off these 5 AP's.

I have done one test on a AP with 4 clients simultaneously downloading from an Netmetal AP (omni antenna, all signals -50dBm max.) in a 20Mhz bandwidth. The AP itself still served 25 other clients (some of them using the internet).
I could push the aggregated throughput of the AP to just over 75Mbps. Cpu of the Netmetal stayed around 30% max and during this test I could just pull 150Mbps from the AC router towards this AP with the build in bandwidth test. (tcp traffic)

So I do not know what is actually withholding the AP from pushing more to its clients but so far not even that bad. But it could be much better imho. The question is only how....

This 60GHz Links are interesting. I guess I know the vendor as the ping times and bandwidth are within what I heard. They are cheap but not the ideal backhaul as they are 802.11ad TDD systems. There are faster 60GHz solutions with lower latency out there. But they are 2x3 times the price.

Your ptmp numbers are ok but not good. With this signals >100MBit/s should be doable. Under ideal conditions >130MBit/s should be seen. I see this with another product with only 4 connected CPEs to one Test-CPE.

WirelessRudy · Sat May 21, 2016 6:40 pm

Your ptmp numbers are ok but not good. With this signals >100MBit/s should be doable. Under ideal conditions >130MBit/s should be seen. I see this with another product with only 4 connected CPEs to one Test-CPE.

Well, to be honest I am convinced there must be people out there that can have 20-40 CPE's to a NetMetal AP associated and at least 4 of these must be able to run at 20Mb download (=80Mbps) where we still can serve small traffic to the others..... if the 'pipe' serving the NetMetal is big enough. (Mine all can have 200Mbp in download session)
Still I have never been able to get more than 80Mbps at the cost of latency (NV2 slot time set to 10ms. On 'auto' or 1 -3ms the latency is better but throughput falls back to 50Mbps max....

The clue must be in the queues or QoS. But with all the theory around its hard to find the right info on what should be done to boost up the AP's.
Inho it can't be that all competition claims 40+ clients and 3 or 4 hundred aggregated on basically the same technology...
Or is MT's NV2 protocol really that bad?

Sat May 21, 2016 7:44 pm

Your ptmp numbers are ok but not good. With this signals >100MBit/s should be doable. Under ideal conditions >130MBit/s should be seen. I see this with another product with only 4 connected CPEs to one Test-CPE.
Well, to be honest I am convinced there must be people out there that can have 20-40 CPE's to a NetMetal AP associated and at least 4 of these must be able to run at 20Mb download (=80Mbps) where we still can serve small traffic to the others..... if the 'pipe' serving the NetMetal is big enough. (Mine all can have 200Mbp in download session)
Still I have never been able to get more than 80Mbps at the cost of latency (NV2 slot time set to 10ms. On 'auto' or 1 -3ms the latency is better but throughput falls back to 50Mbps max....

The clue must be in the queues or QoS. But with all the theory around its hard to find the right info on what should be done to boost up the AP's.
Inho it can't be that all competition claims 40+ clients and 3 or 4 hundred aggregated on basically the same technology...
Or is MT's NV2 protocol really that bad?

There are a lot of claims which dont work in real world. I know this 3-4 hundred claim. It is true but it is a very short range setup on a 80MHz Channel with no interference. And it uses plain 802.11ac with RTS/CTS. So there will be problems for sure. In the same situation you might consider to install 4 SXT SA AC and get a higher aggregated capacity using plain 802.11AC. 4 SXT-SA are cheaper than this one AP.

Nevertheless NV2 needs optimization. The aggregated capacity is too low under ideal conditions.

MT does a lot on wireless at the moment. But this is not WISP stuff, it is related to "normal" AP usage.

Who is online