I have put this package on ~20 various AP's and it has tremendously improved AP's and customer performace on mipsbe and mipsle chipsets only. On PowerPC units with Nstreme on it has absolutely destroyed the throughput, latency and jitter.

Has anyone else seen this?

Steve
Pocketinet Communications

We have updated the wireless-test package. Please download them again, upgrade your routers and report back how it is working.

they were updateted yesterday.

We tested them on three wireless router and only on one we had a little isse about changing on the fly the Hardware Retries, it crashed the router.
Disabling the interface changing the parameter and then re enabling the wireless worked around the problem.

The performance of last build is fantastic.
GREAT WORK MT.

Regards
Ros

First, GREAT improvements on the NStreme package. Lower ping times (100ms to 20ms or so with 50 clients). Major improvements. Jitter is still not totally consistent, but better.

I am seeing low up times (connectivity from clients). I have been on 3.10 and uptimes of days (30-80 days continuous). Now on 3.15 with the test package, I see maybe an hr then they all re-connect. Only a few stay connected at 1 hr or more.

Anyone else see low client connection times? Should I sent a support file?

Eric

I am seeing low up times (connectivity from clients). I have been on 3.10 and uptimes of days (30-80 days continuous). Now on 3.15 with the test package, I see maybe an hr then they all re-connect. Only a few stay connected at 1 hr or more.

Anyone else see low client connection times?

please send the support output files from your routers where you have installed the wireless-test package to support@mikrotik.com so we could check how well it is working.

please send the support output files from your routers where you have installed the wireless-test package to support@mikrotik.com so we could check how well it is working.

do you mean everyone who has it installed, or are you just referring to peavys?

RB532 with 3.16 wireless-test:
Impressive improvement on connection... It's stable and excellent ping.. 100%CPU though...
RB333 with 3.16 wireless-test:
Good improvement on connections.. but it's too much instable... Clients keep disconnecting "Extensive data loss". When i rollback on wireless normal package, those Clients are stable. CPU 100%


RB532 got 2x AR5006X 802.11abg NIC (rev: 1)
RB333 got 3x AR5212 802.11abg NIC (rev: 1)

RB532 with 3.16 wireless-test:
Impressive improvement on connection... It's stable and excellent ping.. 100%CPU though...
RB333 with 3.16 wireless-test:
Good improvement on connections.. but it's too much instable... Clients keep disconnecting "Extensive data loss". When i rollback on wireless normal package, those Clients are stable. CPU 100%


RB532 got 2x AR5006X 802.11abg NIC (rev: 1)
RB333 got 3x AR5212 802.11abg NIC (rev: 1)

Please provide us with the support output files from your RB333 where you see instability. We need one support output file with wireles-test where you see those disconnects and one with the regular wireless package that is running fine.
Also did you see this issue with v3.15 wireless-test package?

Done, I sent both supout files. I allso noticed that on wireless-test package clock is very fast. He's showing 10-15 secs in 1 "real" second

Uldis,

will there be the possibility to do a mixed Nstream/Non Nstream Segment.
At the moment we use Nstream only for Backhaul links.
So when this new version is leaving test-state we want to switch to Nstream.
But we cannot migrate all clients at once so for a limited time we need to
run both modes at once.
Another (better) solution would be when clients (all MT) have a autodetection
and switch Nstream on/off as needed to connect to the ap. In this scenario
we would update all clients and then turn Nstream on at the AP.

Regards,
Stefan

/system script 
add name="ChangeBand" \
    source=":local delais 5s\r\n:local liste 2.4ghz-b/g,2ghz-5mhz,2ghz-10mhz;\r\n \
    \r\n:foreach band in=\$liste \
    do={\r\n:if (![/interface wireless get wlan1 running]) do={\r\n/interface \
    wireless set wlan1 band=\$band\r\n:delay \$delais\r\n}\r\n}\r\n\r\n:if \
    (![/interface wireless get wlan1 running]) \\\r\ndo={\r\n    :if \
    [/interface wireless nstreme get wlan1 enable-nstreme] \\\r\n    do={\r\n  \
          /interface wireless nstreme set wlan1 enable-nstreme=no\r\n    } \
    else={\r\n        /interface wireless nstreme set wlan1 \
    enable-nstreme=yes\r\n    }\r\n}"
/system scheduler 
add comment="" disabled=no interval=20s name="schedcheckWifi" \
    on-event=ChangeBand start-time=startup

I posted this already in the wireless parent of this thread before I saw this... Just wanted to put it here too seemed like the right place...

Either my understanding needs adjustment or the option doesn't work as expected...

Using wireless test 3.17 on ap and clients i check and uncheck the default forward option on the ap and it makes no difference. Either way broadcast and normal ip traffic pass to all clients of the ap. From my understanding unchecking the DEFAULT FORWARD option would prevent traffic from passing from one client to another.

The AP is normal AP mode with default set to add all clients to wds bridge1 as well as the ethernet and wlan1 interfaces added... Make the ap act like any other trango etc ap just passing traffic from wireless to ethernet interface.

The clients are all station wds setup same as ap - one bridge eith ap added ad wds dynamically and eth1 and wlan1 added as well... again just passing traffic though to router behind the radio.

Thanks,
Scott

Wireless test package 3.18 have same clock problems as previous versions!!!

In 3-18-test mipsbe hit reset configuration on wireless and winbox closes and it does not reset. Confirmed multiple instances of this behavior.

Scott

I have "lost connection not polled for too long" error too when using 3.18 wireless-test if there are interferences, using regular package is working quite well, even multiple links on the same frequency. So it seems wireless-test is not very good if you don't have a clean spectrum, which in our area is impossible (usually we see at least 15-25 radios active on 5.5-5.7 ghz band).

Regards,
Giorgio

I still have a problem with clock issue. ROS 3.20 x86 celeron 1,7 GHz.

how can I roll back to my 3.10 package? 3.20 isnt working welll for me. I downloaded 3.13 and would like to try that one.

do we still need the wireless test package for 3.22 ?? or we use the normal wireless package (in 3.22) ?? what i mean is the new nstream technology.

Actually which version of the test package is reliable now???
And, how i going to have the test package? just a concern is, our link is in live network and easily running about 40Mbps, will it take risk if i load the say firmware??

zaltec wrote:
I have "lost connection not polled for too long" error too when using 3.18 wireless-test if there are interferences, using regular package is working quite well, even multiple links on the same frequency. So it seems wireless-test is not very good if you don't have a clean spectrum, which in our area is impossible (usually we see at least 15-25 radios active on 5.5-5.7 ghz band).

Regards,
Giorgio


I've used it in house. Frequency usage shows no other equipment. If interference it's self-interference.
I used 5,5 and 5,7 for the 2 connections. All cards are R52.

Regards,
Stefan

wireless,info 00:0B:XX:XX:XX:XX@wlan_xr5_ptp_sektor: disconnected, extensive data loss

wireless,info 00:XX:XX:XX:XX:XX@wlan_r52_wka: lost connection, not polled for too long

wireless,info 00:XX:XX:XX:XX:XX@wlan_r52_wka: lost connection, not polled for too long

With or without nstreme, polling, etc.

I'm deploying wireless-test since the first release and i love it,
it tolerates less the bad links (that's why you say the normal package is more reliable), but those links are working bad anyway. If you raise the hw-retries, you get the same result as the normal package.
About 4.x, i had some problems at the beginning. i found out that a reset-configuration of the wireless interface fixes all the troubles. Of course the link must be good! Otherwise raise the hw-retries once again and it becomes magically more stable, but with a awful jitter.
My links are all deployed with hw-retries=4 and if it doesn't work i go to fix it and replace with a better link.