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:
Link stability. links must never go down, n-stream we use now has been up for years.
Throughput. n-stream performs well between 11-35Mbit/s
Latency. n-stream pings are between 1-5 ms allways.
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.
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.
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.
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:
This implementation of TDMA requires ideally at least 100mhz of separation between adjacent colocated AP’s… or GPS sync
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!
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.
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
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 ?
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 ?
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)
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)
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?
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.
Try beating this for separation: 300mhz and 10km between the 2 x NV2 sectors for an experiment - we can still trigger our fault
Setup a little dummy NV2 AP at trial CPE site 10km from main NV2 AP on hill
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.
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.
Switch off little dummy NV2 AP at trial CPE site
Power cycle CPE 20-30 times and try to repeat the fault. We cant.
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
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
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 >
Setup a little dummy NV2 AP at trial CPE site 10km from main NV2 AP on hill
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.
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.
Switch off little dummy NV2 AP at trial CPE site
Power cycle CPE 20-30 times and try to repeat the fault. We cant.
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.
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.
