..thats next on the process-of-elimination-todo list for sure 
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.
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.
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.
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.
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.
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
were you asking me?
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.
uldis
I sent an email to support. let me know whats up. Thanks
no dallas i was responding to uldis. thanks
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:
- Much more testing is needed, I need to understand the new parameters of NV2 and also M.
- M seems to be able accelerating traffic, we usally have 20-30Mbit in our classic links using R52 and Nstream.
- Very low CCQ and bandwith seems to sink down, link is claimed to sit on 6Mbit while we are pumping files with nearly 40Mbit.
- Need to get one more antenna to basestation to see if that helps speed up link.
- 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.
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!
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.
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.
@steen
Ben je Nederlands? (Of Belg.)
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.
Already any news on this?
I have all my CPEâs looking for SSID of their assigned AP. Should that do the job?