NV2 Real life PTMP migration and stability

steen · Fri Jan 14, 2011 1:30 pm

Hello Folks!

I have read a lot in this forum about NV2, some say YES other say HMM.
There is many nice storys around the high network speed you can reach.

I was not able to understand if NV2 is ready for real life production and how it performs in harsh production environment with freznel zones and obstacles, noice etc.

In real life we are interested of:
1. Link stability. links must never go down, n-stream we use now has been up for years.
2. Throughput. n-stream performs well between 11-35Mbit/s
3. Latency. n-stream pings are between 1-5 ms allways.
4. Noice and Signal quality robustness. well, we have had problems with some n-stream links lost connection and reconnect again, and strange lockups where pingtimes rises to >1000 and dropsout. But this during extreme conditions and weather.

I would like to here about P2MP installations in this aspects.

sonny · Fri Jan 14, 2011 1:55 pm

look here: http://forum.mikrotik.com/viewtopic.php?f=7&t=48273

n21roadie · Fri Jan 14, 2011 4:02 pm

@steen
What MK OS are you currently using?

At one site i am using NV2 on some of the AP's but have strange behaviour which i would guess is due to proximity effect, i have spaced each AP over a meter apart and two AP's using NV2 is stable but another has hourly disconnects reconnects, use 802.11 and all is OK,

In a nutshell i think NV2 will be very good in a multi AP site when all the AP's are GPS synced, but in the meantime looks like 3.30 for PtP, and if NV2 will work for you great but if not back to 802.11, the advantage of cpe's using "any" protocol in wireless is very convenient for a quick test with instant roll back 802.11 on the AP and cpe's instantly revert to protocol used by AP.

steen · Fri Jan 14, 2011 11:39 pm

One say performance loss of 30% and instability and yet another say it is a dream if GPS synced.
Maby performance loss is due to not GPS synced.

How does NV2 perform in a noicy environment ?
Does NV2 TDMA also make use of frequency hopping to eleminate/reduce noice on some frequencies ?

We run routeros 4.16.
Our Basestations 2 * RB600 with 4 radio cards at 5GHz pointed in 3 directions and one OMNI antenna 2.4 using classic 802.11b only.
Clients RB411 all over with directional antennas (4 clients per sector).
Our clients has all good signals, -32 down to -70

The basestations are not in same town, so GPS synced is not nessesary I guess.

Notice only! When we upgraded from 3.30 to 4.x first time we had problems with ping, when upgrading from 4.10 to 4.11 our company almost collapsed due to all problems, so we did rollback to 4.10 and then to 4.16 when it came out.

airnet · Thu Jan 20, 2011 3:13 pm

We are running a real world multipoint trial of NV2 v4.16.

There is a single AP - an RB433 with an XR5 with 90deg sector antenna
The AP is using 20mhz channel width, locked to 18meg data rate with NV2 security enabled
There are 50 connected CPE's - a mix of 133's and 411's mainly running XR5's (there are some remaining R52H's lol but that's another story)
The 50 CPE's have been connected now for a week rock solid. Their distance from the AP varies from 2 to 12km
The CPE's all deliver a data service and most deliver at least one G729 voice service.
Call traffic peaks at 10 concurrent calls across this single AP

Summary: NV2 shines in a multipoint environment. Wow.

Highlights:
NV2 is by far the biggest milestone in MT history as far as we are concerned. WMM did the job but was inefficient.
The transition from 802.11+WMM went very smoothly. Gotta love that 802.11-nstreme-nv2 setting.
NV2 gives back all the AP capacity and says goodbye to the hidden node problem completely.
Typical AP capacity/throughput is 14meg actual when locked to a conservatively safe 18meg data rate
The overall capacity stays exactly the same no matter if there is 1 or 50 CPE's connected.
The overall capacity is nicely shared evenly amongst contending data users when busy.

With outdoor multipoint 802.11+WMM and hidden nodes the overall AP capacity drops dramatically as more CPE's are connected.
With outdoor multipoint nstreme you can not properly prioritise voice packets as there is no compatible 'over the air' QoS mechanism.
With outdoor multipoint vanilla 802.11 - you cant do anything, really. It's a horrible protocol to use outdoors.
TDMA is inherently the bullet proof foundation for an almost perfect 'over the air' QoS mechanism

Average CPU utilisation is a lot lower on all devices after migrating to NV2.
Single RB133 CPE up/down throughout is now ~6/10megs! It was ~2/6megs on a good day with WMM.

Round trip latency has increased by about 15ms but jitter has decreased. Jitter is way worse for voice than a little bit of extra latency, so we are happy.

Whilst we are not convinced QoS is implemented 100% properly yet, voice is completely flawless at all times even when the rest of the sector is saturated with data. Voice can still be knocked out intentionally but it's difficult to achieve.

Gripes:
None! ...ok, except maybe TDMA splatter from the AP side. But that's the nature of the beast.

Wish list:
1) This implementation of TDMA requires ideally at least 100mhz of separation between adjacent colocated AP's... or GPS sync

2) Just imagine how handy a 20-10-5mhz 'step down' channel width option in the CPE would be just like that brilliant new 802.11-nstreme-nv2 option?

Keep up the great work, MT. If this is 'beta' we cant wait to see what comes next!

Muhammad · Sun Jan 23, 2011 8:10 am

Hi,

I am using right now 5.07 with nstreme, that’s working very well for me (5 GHz)
Yesterday I try to shift my one tower nstreme to NV2, after shifting of 5 Clients (RB711-5Hn) on NV2 I see my Signal-To-Noise is 30% down and my Tx/Rx-CCQ is also 40%to50% down and Tx/Rx-Rate also become lower, I shifted that clients to back on nstreme, after shifting on nstreme they working fine like before.

So what is this I don’t understand

chadd · Sun Jan 23, 2011 9:25 am

Hi,

I am using right now 5.07 with nstreme, that’s working very well for me (5 GHz)
Yesterday I try to shift my one tower nstreme to NV2, after shifting of 5 Clients (RB711-5Hn) on NV2 I see my Signal-To-Noise is 30% down and my Tx/Rx-CCQ is also 40%to50% down and Tx/Rx-Rate also become lower, I shifted that clients to back on nstreme, after shifting on nstreme they working fine like before.

So what is this I don’t understand

Did you have noise floor threshold set on your AP or Clients?

Muhammad · Sun Jan 23, 2011 9:38 am

Hi,

I am using right now 5.07 with nstreme, that’s working very well for me (5 GHz)
Yesterday I try to shift my one tower nstreme to NV2, after shifting of 5 Clients (RB711-5Hn) on NV2 I see my Signal-To-Noise is 30% down and my Tx/Rx-CCQ is also 40%to50% down and Tx/Rx-Rate also become lower, I shifted that clients to back on nstreme, after shifting on nstreme they working fine like before.

So what is this I don’t understand
Did you have noise floor threshold set on your AP or Clients?

no!

Thanks for reply

chadd · Sun Jan 23, 2011 10:43 am

Hi,

I am using right now 5.07 with nstreme, that’s working very well for me (5 GHz)
Yesterday I try to shift my one tower nstreme to NV2, after shifting of 5 Clients (RB711-5Hn) on NV2 I see my Signal-To-Noise is 30% down and my Tx/Rx-CCQ is also 40%to50% down and Tx/Rx-Rate also become lower, I shifted that clients to back on nstreme, after shifting on nstreme they working fine like before.

So what is this I don’t understand
Did you have noise floor threshold set on your AP or Clients?
no!

Thanks for reply

Can't help you much then, NV2 package does some strange stuff with signal levels and noise levels when you have a value entered into the noise floor threshold.

The other thing I notice about the NV2 package is that at idle the CCQ will show a very low number even in the teens and once you start moving data across the link you will get the actual CCQ.

karlos · Sun Jan 23, 2011 11:24 am

Can't help you much then, NV2 package does some strange stuff with signal levels and noise levels when you have a value entered into the noise floor threshold.

The other thing I notice about the NV2 package is that at idle the CCQ will show a very low number even in the teens and once you start moving data across the link you will get the actual CCQ.

I found this too. Once there is low or nearly no traffic the links are going down with CCQ and modulation speed too. Sometimes to 6/6mbit and ccq like 6-7%. once you just ping it 10/s it starts to climb to 90-100% ccq and 54-65Mbit (single chain or up to 130 dual chain). Also if i look at some link that is loaded 16/1Mbit it has 65/54Mbit, once you put more TX data it goes to 65Mbit.
Can some tell me why, and if it si some way to stabilise it on high datarate?

We also tested troughput and it is mostly just dependant on modulation. If you have 65/65Mbit modulation it can easy handle +50Mbit simplex, even +40Mbit in very noisy area. Talking abour reasonable long distances 1-4km and good anough signals like -62dB and better. This -62dB is something we found as "treshold" for very good link on nv2. If you have -62dB or better signal you got all the advantage of the protocol. We also tested that -40dB makes no sense compared to -60dB.
And i can also tell that we was not able to make stable link on dual chain configuration.
On single chain 53,2-53,8Mbit
On dual chain 80-118Mbit, but also drops down to 25Mbit and very wrong jittering
all test on 20MHz channel

Brianward · Sun Jan 23, 2011 11:45 am

We are running a real world multipoint trial of NV2 v4.16.

There is a single AP - an RB433 with an XR5 with 90deg sector antenna
The AP is using 20mhz channel width, locked to 18meg data rate with NV2 security enabled
There are 50 connected CPE's - a mix of 133's and 411's mainly running XR5's (there are some remaining R52H's lol but that's another story)
The 50 CPE's have been connected now for a week rock solid. Their distance from the AP varies from 2 to 12km
The CPE's all deliver a data service and most deliver at least one G729 voice service.
Call traffic peaks at 10 concurrent calls across this single AP

Summary: NV2 shines in a multipoint environment. Wow.

Highlights:
NV2 is by far the biggest milestone in MT history as far as we are concerned. WMM did the job but was inefficient.
The transition from 802.11+WMM went very smoothly. Gotta love that 802.11-nstreme-nv2 setting.
NV2 gives back all the AP capacity and says goodbye to the hidden node problem completely.
Typical AP capacity/throughput is 14meg actual when locked to a conservatively safe 18meg data rate
The overall capacity stays exactly the same no matter if there is 1 or 50 CPE's connected.
The overall capacity is nicely shared evenly amongst contending data users when busy.

With outdoor multipoint 802.11+WMM and hidden nodes the overall AP capacity drops dramatically as more CPE's are connected.
With outdoor multipoint nstreme you can not properly prioritise voice packets as there is no compatible 'over the air' QoS mechanism.
With outdoor multipoint vanilla 802.11 - you cant do anything, really. It's a horrible protocol to use outdoors.
TDMA is inherently the bullet proof foundation for an almost perfect 'over the air' QoS mechanism

Average CPU utilisation is a lot lower on all devices after migrating to NV2.
Single RB133 CPE up/down throughout is now ~6/10megs! It was ~2/6megs on a good day with WMM.

Round trip latency has increased by about 15ms but jitter has decreased. Jitter is way worse for voice than a little bit of extra latency, so we are happy.

Whilst we are not convinced QoS is implemented 100% properly yet, voice is completely flawless at all times even when the rest of the sector is saturated with data. Voice can still be knocked out intentionally but it's difficult to achieve.

Gripes:
None! ...ok, except maybe TDMA splatter from the AP side. But that's the nature of the beast.

Wish list:
1) This implementation of TDMA requires ideally at least 100mhz of separation between adjacent colocated AP's... or GPS sync
2) Just imagine how handy a 20-10-5mhz 'step down' channel width option in the CPE would be just like that brilliant new 802.11-nstreme-nv2 option?

Keep up the great work, MT. If this is 'beta' we cant wait to see what comes next!

great to see something good about NV2 being posted here

you would not mind posting your config of a client and the AP so that we may use it as a guide for future setups?

steen · Sun Jan 23, 2011 1:11 pm

Hello Folks!

Which Readio board is most suitable for NV2 ?

Our mainstream is RIC522C with RB411 and R52.

My distributor does not keep XR2.

1. What is TDMA splatter ?

2a. How does TDMA handle low signal and noicy environments ?

2b. Does client have problem to "syncronize" themself to the TDMA timeslots (their dwell times) if it is noicy ?

3. I have tons of questions, do you also lock the bitratio to some speed like 18Mbit/s or should it be maximized to 54Mbit or even higher if your boards support it ?

4. GPS syncronisation, is that also for Clients ?

airnet · Sun Jan 23, 2011 3:22 pm

Hello Folks!

Which Readio board is most suitable for NV2 ?
We have used low end 133's and high end units for CPE's and they all work fine. Only use High end RB for AP tho.

Our mainstream is RIC522C with RB411 and R52.
I dont know anything about the RIC522 but the 411's are just fine

My distributor does not keep XR2.
Any 'late model' Atheros chipset cards work with NV2

1. What is TDMA splatter ?
In a nice simple way to explain it:
802.11 mode ony sends a lot of radio waves when data is actually being exchanged.
NV2 (TDMA) mode sends a lot of radio waves all the time from the AP (clients only 'listen' unless they have data to send)
Because the TDMA AP sends radio waves at full power ALL THE TIME (even when not sending data), these radio waves tend to 'spread out' way past its defined 5 or 10 or 20mhz channel bandwidth. This 'spread out' is very low level but is enough to interfere with other colocated nearby AP's even though they are on different (adjacent) channels. I call this TDMA splatter because you can actually see it as splatter coming from the wifi card on a spectrum analyser about 100mhz wide in total with the 20mhz (or 10 or 5 depending what you are using) 'peak' in the middle where the AP is actually transmitting. Using 10mhz channel width as opposed to 20mhz you only see half the 'splatter' but its still about 50mhz wide in total!
NOTE: TDMA Splatter is NOT an MT fault, its NOT a WiFi card fault, it's not a fault at all - it is simply the nature of the TDMA protocol at the AP side.
Splatter is a lot lower with high end TDMA radios tho... we are working with $69 wifi cards here remember.
Most vendors generally mask the negative (self interference) effects of splatter by using the GPS sync method. Splatter can be filtered out completely using high end RF cavity equipment but this is generally never done because the cavity filter would effectively lock the AP to only be able to use ONE single channel.

2a. How does TDMA handle low signal and noicy environments ?
Personal experience has taught us that TDMA is generally the winner in a typical outdoor licence-free noisy environment. Google 'canopy vs 802.11' and read all the complaints about competetors' canopy gear knocking out 802.11 networks. Canopy is TDMA. The good old trusty (now EOL) Proxim MP20 system was also TDMA and that used to rule the airspace as well In fact, rumor has it that Canopy was designed by the origional Western Multiplex MP20 engineers after WM was acquired by Proxim.
Although we havent time tested MT's TDMA yet, it very much smells like the good trusty TDMA we have worked with before. Another first-hand experience with TDMA is that it's usually rather 'binary' - eg it either works at 100% capacity or it doesnt work at all. As opposed to 802.11 if you got a bit of noise it 'still kinda works' but with much less throughput. This is generally not the case with TDMA. 'Still kinda works' could arguably be a better design consideration in some scenarios, but in my opinion, he who runs TDMA generally wins

2b. Does client have problem to "syncronize" themself to the TDMA timeslots (their dwell times) if it is noicy ?
All clients are in the sync with their respective AP at all times, regardless if the AP is GPS sync'd or not [EDITED/ADDED FOR CLARITY]. The air most likely wont be noisy because your AP is already 'noise' to competetors so they likely would have never accidentally used your channel to begin with. Unlike competing 802.11 networks that are often provisioned in the middle of the night when the air was clean because 802.11 only sends (lots of interfering) radio waves when there is data to be sent. The TDMA AP sends radio waves 24/7 therefore even in the middle of the night its almost impossible for a competetor to successfully provision his AP on an already used TDMA channel.
He who's the first to operate TDMA on a particular clean unlicenced channel in a particular area generally ends up owning that channel

3. I have tons of questions, do you also lock the bitratio to some speed like 18Mbit/s or should it be maximized to 54Mbit or even higher if your boards support it ?
There are many variables to consider and there are always tradeoffs. Basically, higher rates = lower reliability. You need to perform your own evaluation of your particular scenario and make the call yourself

4. GPS syncronisation, is that also for Clients ?
Nope, in a GPS sync'd TDD-TDMA network only the AP's require the sync. Clients sync with the already sync'd AP. If all AP's on your network are GPS sync'd then your entire network is in sync meaning you can use adjacent channels on adjacent AP antennas and efficient re-use of frequency may be possible under certain situations [EDITED/ADDED FOR CLARITY]

n21roadie · Sun Jan 23, 2011 4:01 pm

We are running a real world multipoint trial of NV2 v4.16.

There is a single AP - an RB433 with an XR5 with 90deg sector antenna
The AP is using 20mhz channel width, locked to 18meg data rate with NV2 security enabled
You have your AP datarates locked at 18Mbps, I have each of the CPE locked at highest CCQ acheivable using either 12,18,24Mbps rates but AP is set to default?
Of course if you are using XR5 on the AP at 18Mbps you will have a extra 5dBm giving 28dBm TX (as 54Mbps TX rate is 23 dBm)
There are 50 connected CPE's - a mix of 133's and 411's mainly running XR5's (there are some remaining R52H's lol but that's another story)
The 50 CPE's have been connected now for a week rock solid. Their distance from the AP varies from 2 to 12km
The CPE's all deliver a data service and most deliver at least one G729 voice service.
Call traffic peaks at 10 concurrent calls across this single AP

Summary: NV2 shines in a multipoint environment. Wow.

Highlights:
NV2 is by far the biggest milestone in MT history as far as we are concerned. WMM did the job but was inefficient.
The transition from 802.11+WMM went very smoothly. Gotta love that
NV2 gives back all the AP capacity and says goodbye to the hidden node problem completely.
Typical AP capacity/throughput is 14meg actual when locked to a conservatively safe 18meg data rate
The overall capacity stays exactly the same no matter if there is 1 or 50 CPE's connected.
The overall capacity is nicely shared evenly amongst contending data users when busy.

Are we talking about just one sector using NV2 or multiple sectors on a mast using NV2

airnet · Sun Jan 23, 2011 4:39 pm

great to see something good about NV2 being posted here

you would not mind posting your config of a client and the AP so that we may use it as a guide for future setups?

It's just a simple and vanilla layer 2 config at AP and CPE. Basically all the wireless settings are mainly at their defaults with the exception of NV2 and NV2 security being enabled.
It just works. The only experimentation you need to do is with the data rates as they are specific to everyones different outdoor environment. Up to 24meg rate worked great for us (actual 20meg 'real' sector capacity!) but we dropped it back to 18 to play it safe and ensure plenty of fade margin. 36meg mode killed the CPU in most 133 CPE's however but i am sure if all CPE's were 411 or better it would have worked just swell (the drawback being worse RX sensitivity thus a tighter fade margin etc etc)

Are we talking about just one sector using NV2 or multiple sectors on a mast using NV2

Interesting that you ask - this is hot off the press just today since experimenting with NV2 AP #2....

READ BEFORE FLAMING: We've proven that this particular issue has NOTHING to do with interference or any other inherent problems associated with colocation of NV2 (TDMA) AP's.

We *think* we have since discovered a minor protocol 'issue' with NV2 and will work with MT support to help resolve it.
This issue appears to be triggered by CPE's who can 'see' more than one NV2 AP when they scan prior to association with the AP with strongest signal.
What happens is this issue sometime causes all associated CPE's to 'fall off' a particular AP at the same time but ONLY IF the CPE can 'see' more than 1 NV2 AP when it scans prior to association.
Problem goes away at night time when there are generally no CPE's trying to associate. Problem starts again when new CPE's are being installed during business hours.
If you only allow CPE to only ever be able to 'see' a single NV2 AP, I stand to my word and NV2 is STILL solid as a rock.

I guarantee most of the stability gripes about NV2 here on this forum come down to this same 'cpe triggered' bug.

I ask that everyone who has tried NV2 and failed to try again but this time only allow CPE to ever 'see' a single NV2 enabled AP at any given time. Eg enable NV2 on only a single AP at a tower and leave all your other AP's in 802.11 or nstreme mode and I'll bet my right ball your percieved NV2 instability problems will go away.
If you do still happen to find NV2 unstable then you probably have other underlying faults that need to be addressed regardless. Like AP antenna separation and frequency separation. Lots of both are required

In summary, I stand my ground. NV2 is the best thing since sliced bread. (assuming the above is easily resolvable, of course)

n21roadie · Sun Jan 23, 2011 5:20 pm

This issue appears to be triggered by CPE's who can 'see' more than one NV2 AP when they scan prior to association with the AP with strongest signal.
What happens is this issue sometime causes all associated CPE's to 'fall off' a particular AP at the same time but ONLY IF the CPE can 'see' more than 1 NV2 AP when it scans prior to association.

Have the other AP's the same SSID, and is the CPE's using NV2 or "any" wireless protocol

I guarantee most of the stability gripes about NV2 here on this forum come down to this same 'cpe triggered' bug.

I ask that everyone who has tried NV2 and failed to try again but this time only allow CPE to ever 'see' a single NV2 enabled AP at any given time. Eg enable NV2 on only a single AP at a tower and leave all your other AP's in 802.11 or nstreme mode and I'll bet my right ball your percieved NV2 instability problems will go away.
If you do still happen to find NV2 unstable then you probably have other underlying faults that need to be addressed regardless. Like AP antenna separation and frequency separation. Lots of both are required

Not sure about that, I have good physical + frequency seperation of AP's on a mast had two sector AP's with NV2 issues one had daily disconnects and reconnects tweaked advanced setting in wireless and solved that one but another sector AP on same mast had hourly disconnects and reconnects tried same tweaks but no luck, my guess is when wireless sync is available for MK NV2 for co-located radio's then interference issues will disappear and performance will improve?

airnet · Sun Jan 23, 2011 6:21 pm

Have the other AP's the same SSID, and is the CPE's using NV2 or "any" wireless protocol

Hmmm, good point. Yes, AP's have same SSID and CPE's are set to nv2-nstreme-802.11 for fallback purposes.
We might do some experimentation with different AP SSID's and see what happens.

Not sure about that, I have good physical + frequency seperation of AP's on a mast had two sector AP's with NV2 issues one had daily disconnects and reconnects tweaked advanced setting in wireless and solved that one but another sector AP on same mast had hourly disconnects and reconnects tried same tweaks but no luck, my guess is when wireless sync is available for MK NV2 for co-located radio's then interference issues will disappear and performance will improve?

Try beating this for separation: 300mhz and 10km between the 2 x NV2 sectors for an experiment - we can still trigger our fault

1) Setup a little dummy NV2 AP at trial CPE site 10km from main NV2 AP on hill
2) Power cycle CPE and watch it's logs, sure enough it can now see 2 x NV2 AP's and so it associates with the close AP thats only 50metres away. So far so good.
3) Repeat 2) ten times and two of the ten times EVERY SINGLE OTHER 49 CPE's connected to NV2 AP on the hill 10km away all disassociated at the same time.
4) Switch off little dummy NV2 AP at trial CPE site
5) Power cycle CPE 20-30 times and try to repeat the fault. We cant.
6) Repeat 1-5 again. And get same results, again.

Co-incidence? Very possibly... but doubtfully.

COMPLETE stab in the dark: I reakon the CPE is sometimes acquiring it's TDMA timing from one AP and then accidentally applying this AP's timing to the other AP. Effectively freaking the shit out of everything and causing all CPE's to drop off immediately.

What is conclusive however is that physical and channel separation is NOT the culprit in the particular issue we are seeing with 2 or more co-located NV2 AP's

airnet · Sun Jan 23, 2011 7:13 pm

We are running a real world multipoint trial of NV2 v4.16.

There is a single AP - an RB433 with an XR5 with 90deg sector antenna
The AP is using 20mhz channel width, locked to 18meg data rate with NV2 security enabled
You have your AP datarates locked at 18Mbps, I have each of the CPE locked at highest CCQ acheivable using either 12,18,24Mbps rates but AP is set to default?
Of course if you are using XR5 on the AP at 18Mbps you will have a extra 5dBm giving 28dBm TX (as 54Mbps TX rate is 23 dBm)
There are 50 connected CPE's - a mix of 133's and 411's mainly running XR5's (there are some remaining R52H's lol but that's another story)
The 50 CPE's have been connected now for a week rock solid. Their distance from the AP varies from 2 to 12km
The CPE's all deliver a data service and most deliver at least one G729 voice service.
Call traffic peaks at 10 concurrent calls across this single AP

Summary: NV2 shines in a multipoint environment. Wow.

Highlights:
NV2 is by far the biggest milestone in MT history as far as we are concerned. WMM did the job but was inefficient.
The transition from 802.11+WMM went very smoothly. Gotta love that
NV2 gives back all the AP capacity and says goodbye to the hidden node problem completely.
Typical AP capacity/throughput is 14meg actual when locked to a conservatively safe 18meg data rate
The overall capacity stays exactly the same no matter if there is 1 or 50 CPE's connected.
The overall capacity is nicely shared evenly amongst contending data users when busy.
Are we talking about just one sector using NV2 or multiple sectors on a mast using NV2

No! - Do the opposite, leave CPE's at default and make data rate changes at AP. CPE's will follow suit and will all be the same rate both up and down according to AP setting.
Also, only ever tick a single data rate at AP at a time. In theory you cannot have different CPE modulation (data) rates across a TDMA sector. In practice, MT's implimentation could be different. But it would break the rules of most TDMA flavours.

NV2 AP's are each a separate board, card and sector antenna.

DONT ever run XR5's at 28db unless you have PERFECT VSWR, tested end to end with proper equipment, other wise the PA will go *pop*.
We choose to use XR5's at low power (19-20db max) purely for reliability. Think of a de-tuned chevvy V8 with a tiny carburettor. They do that for longevity and reliability

n21roadie · Sun Jan 23, 2011 8:54 pm

Hmmm, good point. Yes, AP's have same SSID and CPE's are set to nv2-nstreme-802.11 for fallback purposes.
We might do some experimentation with different AP SSID's and see what happens.

I use "any" in the CPE which is great for quick switching between protocols on the test AP

No! - Do the opposite, leave CPE's at default and make data rate changes at AP. CPE's will follow suit and will all be the same rate both up and down according to AP setting.

I had read to leave AP to default and tweak CPE data rates as the different distances from AP will result in different data rates, one CPE could have 24Mbit data rate and 90++% CCQ and another would have to be set at 12Mbit to achieve 90+% CCQ

DONT ever run XR5's at 28db unless you have PERFECT VSWR, tested end to end with proper equipment, other wise the PA will go *pop*.
We choose to use XR5's at low power (19-20db max) purely for reliability. Think of a de-tuned chevvy V8 with a tiny carburettor. They do that for longevity and reliability

Good point, so apart from setting the data rates on the AP do you also set power level (TX power which setting, all fixed rates,card rates,default,manual)

how do test an actual configuration for perfect VSWR?

Try beating this for separation: 300mhz and 10km between the 2 x NV2 sectors for an experiment - we can still trigger our fault

1) Setup a little dummy NV2 AP at trial CPE site 10km from main NV2 AP on hill
2) Power cycle CPE and watch it's logs, sure enough it can now see 2 x NV2 AP's and so it associates with the close AP thats only 50metres away. So far so good.
3) Repeat 2) ten times and two of the ten times EVERY SINGLE OTHER 49 CPE's connected to NV2 AP on the hill 10km away all disassociated at the same time.
4) Switch off little dummy NV2 AP at trial CPE site
5) Power cycle CPE 20-30 times and try to repeat the fault. We cant.
6) Repeat 1-5 again. And get same results, again

For this test you outlined had both AP's the same SSID as my AP's have different SSID and NV2 issues continue the only item common to the AP's is PPPoE secret connect list, which has to be there should i need to switch a CPE to a different AP.

chadd · Sun Jan 23, 2011 9:02 pm

COMPLETE stab in the dark: I reakon the CPE is sometimes acquiring it's TDMA timing from one AP and then accidentally applying this AP's timing to the other AP. Effectively freaking the **it out of everything and causing all CPE's to drop off immediately.

What is conclusive however is that physical and channel separation is NOT the culprit in the particular issue we are seeing with 2 or more co-located NV2 AP's

Have you tried to set up access and connect lists on the client/AP to limit who they are allowed to connect to? I would think that would help out with the problem you are talking about. You could also setup a scan list in the CPE so it never tries to scan the AP you don't want it to register to.

airnet · Mon Jan 24, 2011 12:34 am

Have you tried to set up access and connect lists on the client/AP to limit who they are allowed to connect to? I would think that would help out with the problem you are talking about. You could also setup a scan list in the CPE so it never tries to scan the AP you don't want it to register to.

..thats next on the process-of-elimination-todo list for sure

airnet · Mon Jan 24, 2011 12:52 am

I had read to leave AP to default and tweak CPE data rates as the different distances from AP will result in different data rates, one CPE could have 24Mbit data rate and 90++% CCQ and another would have to be set at 12Mbit to achieve 90+% CCQ.

Yes, thats probably the best bet for 802.11 or nstreme etc.
However, clients with a mixture of different data rates logged into an NV2 (TDMA) sector *in theory* would significantly break the fundamental advantages of TDMA.
My other theory is that a mixture of different client data rates just shouldnt work properly (if at all) full stop. But I havent had enough experience with this new 'pseudo wifi TDMA' implimentation to fully understand how it all fits together as yet.

To play it safe at this early stage I would certainly recommend locking all client CPE's to the same rate at the AP for NV2 enabled sectors - It rules out a lot of unknown MT WiFi TDMA factors at this moment in time.

rodneal · Mon Jan 24, 2011 6:41 am

This may work for an ENTIRELY MT RB NETWORK - in real life this doesn't work. You have a mix of new and old - MT and UB and Tranzeo and Engenious and whatever really worked good at that time!
NV2 does NOT work outside the MT spectrum and any Routerboard running 4.16 or rc7 with NV2 activated will NOT handle 802.11 traffic at all!
We need a ubiquitous version to support ALL 802.11 effectively. Right now that is v3.30 - anything after will not!
Rod

chadd · Mon Jan 24, 2011 6:56 am

This may work for an ENTIRELY MT RB NETWORK - in real life this doesn't work. You have a mix of new and old - MT and UB and Tranzeo and Engenious and whatever really worked good at that time!
NV2 does NOT work outside the MT spectrum and any Routerboard running 4.16 or rc7 with NV2 activated will NOT handle 802.11 traffic at all!
We need a ubiquitous version to support ALL 802.11 effectively. Right now that is v3.30 - anything after will not!
Rod

That is the bad thing about any TDMA product once you start moving to TDMA you lose your ability to mix and match equipment. I don't know of any TDMA based AP's that will let you mix match CPE's. 802.11 and TDMA are two totally different animals there is no way to make it backwards compatible. But if you are trying to run just vanilla 802.11 across the board then yeah there are some stability issues with 802.11 past 3.30.

steen · Sat Jan 29, 2011 1:12 am

Today I recieved some lab equipment to star evaluate NV2.
1p MikroTik/RouterBOARD SXT 5HnD5Ghz N
3p RouterBOARD R52Nm 2,4/5GHz

I have some RB433 boxed boards, RB411 and boxed RB333 boards that I will populate them with R52Nm, make two access point's and others will be clients.

I will se some spacing between the access point channels to minimize splatter and interference.

My lab environment is harsh, if it works there, it will work in real life.

illiniwireless · Sun Jan 30, 2011 4:59 pm

I tried NV2 on an rb411a with an xr9 yesterday and I had 4.15 software on it and all clients. There is only 1 900 mhz radio on the tower and it has 31 clients connected. The first thing I tried was enabling nv2 on ap and it did not work as well as the normal wireless package even when set to 802.11. Then I disabled the nv2 package and started enabling nv2 on clients. Once done with clients I once again enabled the nv2 on the ap. It worked horrible. I tried changing all different setting and channels only to be frustrated. Then I reset the wireless to defaults and tried again but to only have bad results again. They would disconnect frequently. I woke up this morning to find no one connected and then just reverted the ap back to the standard wireless package and it is working fine and this is with the clients set to any on the wireless protocol with nv2 packaged enabled. So from what I have established is the clients work fine with nv2 package but the ap doesn't. My 2 scents worth. I'm waiting for the next firmware to try nv2 again.

Mon Jan 31, 2011 4:58 pm

I tried NV2 on an rb411a with an xr9 yesterday and I had 4.15 software on it and all clients. There is only 1 900 mhz radio on the tower and it has 31 clients connected. The first thing I tried was enabling nv2 on ap and it did not work as well as the normal wireless package even when set to 802.11. Then I disabled the nv2 package and started enabling nv2 on clients. Once done with clients I once again enabled the nv2 on the ap. It worked horrible. I tried changing all different setting and channels only to be frustrated. Then I reset the wireless to defaults and tried again but to only have bad results again. They would disconnect frequently. I woke up this morning to find no one connected and then just reverted the ap back to the standard wireless package and it is working fine and this is with the clients set to any on the wireless protocol with nv2 packaged enabled. So from what I have established is the clients work fine with nv2 package but the ap doesn't. My 2 scents worth. I'm waiting for the next firmware to try nv2 again.

Please use RouterOS v4.16 or RouterOS v5.0rc7 which has improvements for the Nv2 protocol.
also please contact support@mikrotik.com with the support output file form that AP where you see problems. Also Maybe you can provide us remote access to your AP -that would help us to solve the problem.

dallas · Tue Feb 01, 2011 12:19 am

wow I waited for nv2 to go rc. I justed started using it production and wow its amazing. 30mbps up and download at 4 miles is great. 6-8mbps minimum at 10 miles.

illiniwireless · Tue Feb 01, 2011 3:24 am

Uldis

I looked at change log and it doesn't show any wireless changes from 4.15 to 4.16. Am I missing something?

Thanks

dallas · Tue Feb 01, 2011 6:33 am

were you asking me?

Tue Feb 01, 2011 10:46 am

Uldis

I looked at change log and it doesn't show any wireless changes from 4.15 to 4.16. Am I missing something?

Thanks

to debug the problem we need to have the latest release installed on the router, that is why I asking to upgrade to v4.16. Let us know by writing to support@mikrotik.com if you could give us remote access to that router.

illiniwireless · Tue Feb 01, 2011 5:31 pm

uldis

I sent an email to support. let me know whats up. Thanks

illiniwireless · Tue Feb 01, 2011 5:43 pm

no dallas i was responding to uldis. thanks

steen · Sat Feb 05, 2011 4:11 pm

Hello Folks!

Now I have made the first tests of NV2 using R52N-M boards and also the new MT device SXT-5D with integrated 16db antenna (sorry to say but 16 db is way to little, we need 21db for stable links here).

RouterOS 4.16 in all boxes.

Basestation RB433 (one antenna)
Client 1 RB411 (one antenna)
Client 2 SXT-5D (claims it has two antennas, will fix basestation with two antennas later).

First, I do not know much about the M mode at all, support is needed here.

I followed the migration to NV2 guide and some other instructions on howto setup R52N-M.
I did enable the "extra channel" to get 40 MHz bandwith.
All else is out of the box settings.

Using Nstream I recieved connections up to HT40-7 (what is HT40-7 ?)
CCQ was low 60-80%, we are used to 95%-100%.
Signal to Noice was 50db.
Speed of link was while transferring files 30-65Mbit.
Link seems very stable when working with ssh/telnet at all times.

Using NV2 I recieved connections up to HT20-6 (what is HT20-6 ?)
CCQ was very low 11% steady sometime flicker up to 60%. Strangely enough the link works.
Signal to Noice was 50db.
Speed of link was while transferring files 4-5Mbit/s first, then it raised to 30-40Mbit not more.
Link seems very stable when working with ssh/telnet at all times.

I did try the dual settings in client to have the ability swithching between NV2 and Nstream, it was also tested and worked very quickly when switching.

First time test Conclusions:
1. Much more testing is needed, I need to understand the new parameters of NV2 and also M.
2. M seems to be able accelerating traffic, we usally have 20-30Mbit in our classic links using R52 and Nstream.
3. Very low CCQ and bandwith seems to sink down, link is claimed to sit on 6Mbit while we are pumping files with nearly 40Mbit.
4. Need to get one more antenna to basestation to see if that helps speed up link.
5. The HT values does not exeed HT20-6 for NV2, maby HT40 is not supported ?
I understand that the 20 and 40 in HT values must be the bandwidth.

I will put configuration up here as well as next post later today.

steen · Sun Feb 06, 2011 11:16 am

Hello Folks!

I did get opposite performance than many on the network.
NV2 performs considerable better than Nstreme in my tests.

So for me this starts to look like a success story.

I did not have time to put up configuration, but as I wrote above it is out from the box settings regarding the R54n-M boards.

I now managed to get link speed all way up to HT-40-7, I did not do anything special more than hooking up the client to a laptop and start transferring files.

5GHz band. Client setup to pick either Nstream or NV2. All per MT instructions no own inventions. Basestation is access point mode and client is station mode. All setup as a routing network, no bridging. Classic setup per our site's, IP packing all on, HW compression is on in basestations. One swivel antenna at client and one at basestation.

Observations:

Half meter lab test bench:
From beginning tests Nstream was performing much better than NV2.
Link connect 150/150mbit and udp traffic up to 100Mbit/s vs TCP traffic 40-60Mbit (cpu went to 100% in rb433 and rb411 during TCP tests).
NV2 did not work well at short distances (half meter in lab), 12-15Mbit, 3-4Mbit.

Adding distance and freznel zones:
Adding some distance (40 meters + svivel antenna) and freznel zones to link made Nstream drop down quickly in speed to 20-35Mbit, 20-25Mbit or lower. While NV2 connects to 135/135Mbit and udp traffic is 100Mbit/s vs TCP traffic is 35-60Mbit (cpu 100%).

Yet it is at least double real life link speeds than R52 classic setup.

Feelings:
Trying real life scenario with NV2 it is lighting fast, it "feels" like copper wire connection, BIG difference to the classic setup using R52 5GHz links.

Nv2 vs Nstreme:
For NV2 when client have just connected to basestation speed indicators show 6Mbit and terrible CCQ, however the link is rock solid anyway, no lagging not delay, IP telefony works well and fels qiuck. After some minutes the speed indicators and CCQ start to climb up.
Speed levels out to 135Mbit and all steps up to Ht40-7 becomes available. After the process link is ROCK SOLID and ligthing fast.

For Nstreme in same situation, speed indicators say 150/150 in some 3-5 seconds and all steps up to HT40-7 becomes available. The link is little shaky, but not much some lags are noticed (stucks shortly). After stabilizing link is rock solid, but feels little more lagging than NV2.

Note:
Yet I do not make any conclusions, I have to test on some customers in an area first.
Lab tests are one thing, real life with paying customers is fully another!

I will put my standard configuration here as soon I have time now.
Hope more than I have success with NV2, i looked on this with rather critical eyes from beginning.

GREAT WORK MIKROTIK!

steen · Sun Feb 06, 2011 2:18 pm

Working config's, hope it helps someone.

Client side, changes to standard only:
# jan/02/1970 00:36:39 by RouterOS 4.16

/interface wireless security-profiles
add name=test123 authentication-types=wpa2-psk group-ciphers=tkip \
name=test123 \
wpa2-pre-shared-key=test123

# Comment ht-txchains=0 ht-rxchains=0 since we have only one antenna in test.
/interface wireless
set 0 band=5ghz-onlyn \
country=no_country_set \
ht-ampdu-priorities=0,1 \
ht-extension-channel=above-control \
default nv2-preshared-key=test \
nv2-security=enabled security-profile=test123 ssid=Node46Nv2 \
wireless-protocol=nv2-nstreme wmm-support=enabled

/interface wireless nstreme
set wlan1 enable-nstreme=yes enable-polling=yes

/ip address
add address=10.21.0.2/24 broadcast=10.21.0.255 \
interface=wlan1 network=10.21.0.0
add address=10.21.1.1/24 broadcast=10.21.1.255 \
interface=ether1 network=10.21.1.0

/ip route
add dst-address=0.0.0.0/0 gateway=10.21.0.1

/ip dns
set allow-remote-requests=yes servers=172.16.1.1

/ip dns static
add address=10.21.1.1 name=ns

Basestation side:
/interface wireless security-profiles
add authentication-types=wpa2-psk group-ciphers=tkip \
name=test123
unicast-ciphers=tkip wpa-pre-shared-key="" wpa2-pre-shared-key=test123

# Comment ht-txchains=0 ht-rxchains=0 since we have only one antenna in test.
/interface wireless
set 1 country=no_country_set \
frequency=5805 \
mode=ap-bridge \
ht-ampdu-priorities=0,1 \
ht-extension-channel=above-control \
nv2-preshared-key=test security-profile=test123 \
nv2-security=enabled \
ssid=Node46Nv2 wireless-protocol=nv2 wmm-support=enabled

/interface wireless nstreme
set wlan2 enable-nstreme=yes enable-polling=yes

/ip address
add address=172.16.1.12/24 interface=ether1
add address=10.21.0.1/24 interface=wlan2

/ip route
add dst-address=0.0.0.0/0 gateway=172.16.1.1
add dst-address=10.21.1.0/24 gateway=10.21.0.2

/ip dns
set allow-remote-requests=yes servers=172.16.1.1

/ip dns static
add address=10.21.1.1 name=basestation
# END #

I will now do two more tests, using two antennas on base and client and then also test it with classic R52 boards to see what I can gain.

By the way, is there boards with three antennas ? I can see three cannel fields in MT signal pane.

steen · Sun Feb 06, 2011 4:35 pm

TSM works well through the link.
While working with the one antenna tests with NV2, my laptop suddenly started to do daily TSM backup, a nice way to check bandwith. Speed is steadly 35-40Mbit/s whole way through, not realy wirespeed, we usally got 80-90Mbit/s when TSM backup is running.
Link is not even lagging all is smoth and quick when doing other things! CPU is not 100%, it is between 12-37% all way through.

So for a new player, as me it worked well, I do not know all nitty gritty settings but all seems to work out of the box.

So now to the dual antenna tests which was completed some moment ago.
Settings per above tests with one difference in configuration and hardware.
Adding one swivel antenna to basestation R52n-M board and now using the SXT-5D as client.

Adding to configuraion in both basestation and client:
/interface wireless
set 0 ht-txchains=1 ht-rxchains=1
# This would by my understanding activate one more channel on the radio board.

Link observations
NV2 behaves as before, slowly climbing up to 270/270Mbit link speed.
Nstreme start to climb up but stop somewhere around 110Mbit-135Mbit.
Question, should not link speed be 300/300 ?

When there is little or no traffic over the link, speed start to slowly go down again.
And reverse when traffic is back, it raises again, quickly.
The behavor has not ben observed to disturb anything at all, no lagging nothing.

Bandwith tests
Adding traffic to it using MT bandwith test, NV2 170Mbit/s-190Mbit UDP traffic, 35-50Mbit/s TCP traffic (cpu goes 100% again).

Nstreme got problem during bandwith tests
Using Nstreme link is dropped when traffic starts to flow, it reaches abot 15Mbit/s then dies.
Link comes up again, and cykling all the time.

Traffic does not go up to 80-90Mbit/s
Why traffic does not go up to 80-90Mbit/s I do not know.
In any cases it is much better than classic R52.
But if it is worth the trouble rebuilding all basestations and change radio boards in all CPE's could be discussed. For that I would like ot see 80-90Mbit first or close to it.

WirelessRudy · Mon Feb 07, 2011 1:53 am

@steen
Ben je Nederlands? (Of Belg.)

WirelessRudy · Mon Feb 07, 2011 3:38 am

1. What is TDMA splatter ?
In a nice simple way to explain it:
802.11 mode ony sends a lot of radio waves when data is actually being exchanged.
NV2 (TDMA) mode sends a lot of radio waves all the time from the AP (clients only 'listen' unless they have data to send)
Because the TDMA AP sends radio waves at full power ALL THE TIME (even when not sending data), these radio waves tend to 'spread out' way past its defined 5 or 10 or 20mhz channel bandwidth. This 'spread out' is very low level but is enough to interfere with other colocated nearby AP's even though they are on different (adjacent) channels. I call this TDMA splatter because you can actually see it as splatter coming from the wifi card on a spectrum analyser about 100mhz wide in total with the 20mhz (or 10 or 5 depending what you are using) 'peak' in the middle where the AP is actually transmitting. Using 10mhz channel width as opposed to 20mhz you only see half the 'splatter' but its still about 50mhz wide in total!
NOTE: TDMA Splatter is NOT an MT fault, its NOT a WiFi card fault, it's not a fault at all - it is simply the nature of the TDMA protocol at the AP side.
Splatter is a lot lower with high end TDMA radios tho... we are working with $69 wifi cards here remember.
Most vendors generally mask the negative (self interference) effects of splatter by using the GPS sync method. Splatter can be filtered out completely using high end RF cavity equipment but this is generally never done because the cavity filter would effectively lock the AP to only be able to use ONE single channel.

Can you explain why radio waves from TDMA radio would ´spread out` more then legacy 802.11 radio waves? (Given we use same antenna, power and radio in both instances.)
Maybe in time (24/7-TDMA versus ´when needed-legacy´) but when a radio wave in a certain freq. is transmitted it will ´spread out´ over the spectrum anyway, no matter TDMA or whatever protocol/modulation etc.?
Everybody knows about ´that boy around the corner´ with his hobby fm radio station is blasting almost the whole FM band to destruction... Or put your cellphone near a very cheap radio. When the cell starts transmitting your radio signal is blast away. Freq's are not even close!

The quality of a radio is a result of how sharp the ´cut-off´ is of the transmitters radio wave outside its working frequency band. The narrower the better (and the more expensive the radio). On the receiver end it is the filter that decides how narrow the freq band is that is passed and how much of the ´off center´ frequencies are still passed though to the receiver. Good radio's usually come with good filters.

WirelessRudy · Mon Feb 07, 2011 3:42 am

Have you tried to set up access and connect lists on the client/AP to limit who they are allowed to connect to? I would think that would help out with the problem you are talking about. You could also setup a scan list in the CPE so it never tries to scan the AP you don't want it to register to.
..thats next on the process-of-elimination-todo list for sure

Already any news on this?

I have all my CPE's looking for SSID of their assigned AP. Should that do the job?

WirelessRudy · Mon Feb 07, 2011 3:58 am

Can't help you much then, NV2 package does some strange stuff with signal levels and noise levels when you have a value entered into the noise floor threshold.

So you have set them? Any guideline? I never set these. Should I?

Beccara · Mon Feb 07, 2011 5:24 am

Hello Folks!
Half meter lab test bench:
From beginning tests Nstream was performing much better than NV2.
Link connect 150/150mbit and udp traffic up to 100Mbit/s vs TCP traffic 40-60Mbit (cpu went to 100% in rb433 and rb411 during TCP tests).
NV2 did not work well at short distances (half meter in lab), 12-15Mbit, 3-4Mbit.

Your doing apples to oranges here, UDP test's always show great speeds but hardly ever relate to real life traffic. Try rerunning this test with both tests being either UDP or TCP, never mix the two because they always vary wildly

chadd · Mon Feb 07, 2011 9:58 am

Can't help you much then, NV2 package does some strange stuff with signal levels and noise levels when you have a value entered into the noise floor threshold.
So you have set them? Any guideline? I never set these. Should I?

If you are running the 4.16 NV2 package my advice is to not set them at all.

Trisc · Mon Feb 07, 2011 4:47 pm

Airnet - how did you manage to get wireless-nv2 package to work on RB133s? We can just about load 4.16 with the minimum packages: ppp, dhcp, system, routerboard, security and standard wireless package, but replace this with wireless-nv2 and the board becomes completely unresponsive - cannot even telnet in let alone use Winbox!

This board does not seem to have sufficient resources.

We have a large number of RB133/R52 s and we desperately want to use TDMA so please share your method!

Trisc · Mon Feb 07, 2011 5:48 pm

OK, I eventually managed to login to RB133. As suspected CPU is stuck at 100%.

All I did was change standard wireless package to wireless-nv2.

steen · Mon Feb 07, 2011 10:40 pm

@steen
Ben je Nederlands? (Of Belg.)

Steen from Sweden

WirelessRudy · Tue Feb 08, 2011 11:45 pm

OK, I eventually managed to login to RB133. As suspected CPU is stuck at 100%.

All I did was change standard wireless package to wireless-nv2.

I can second all that.
Some rb133C's are doing better after some power cycles.
All my rb133C's are with similar config and same radio's. Still some work good while other always are slow with nv2 package.
I only run dhcp, routerboard, system and wireless-nv2 package. Simple config. No queues, simple firewall filter, no mangle.

What I also notice is that when under ´idle´ circumstances (winbox open with one or two windows) the cpu is around 10% (no further traffic over router) but the moment you want a terminal screen, ask some system info (like ask the packages) the cpu jumps to 100%
Some boards never get it to open a compleet terminal screen. Even after the cpu falls back the terminal screen stays frozen apart form the welcome message.
On such board trying to open telnet session makes them crash.
So basically, these boards are almost impossible to upgrade the firmware. You have to install the normal wireless package first, than upgrade firmware, then put the nv-2 package back on again....

I also have some 80 of these ´old´ boards and I also really would like to use nv-2 more.....

dallas · Wed Feb 09, 2011 12:46 am

Yes all of my rb133 175mhz cpu is real sluggest with the nv2 protocol. Sometimes its hard to even log in. So I agree.

Trisc · Wed Feb 09, 2011 12:32 pm

We managed to upgrade approx 10 RB133s to 4.16 with nv-2, but it took all day. First we had to lock default rates on AP and client to 18Mbps like the earlier post says, then upload only the packages we need. We foundthe CPU could just handle it. We even managed to upgrade a 112!

So far all 133s are working OK but if I were to open a terminal window in Winbox it would still crash the router.

dallas · Wed Feb 09, 2011 5:02 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.

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.