Update for those Interested.... I loaded the newest stable rel MT OS v 3.30 on all the radio. It did not help. The problem still existed.
To review we had two clients "a" and "b", and "b" was the one that would drop link if pass traffic in upload direction. Initially it was impossible to upload the firmware to the clientB. So I temporarily disabled clientA, and then it was possible to successfully upload new OSfirmware to clientB. So, I replicated the setup in the lab today, with 5 MT SBCs, of the same type as in the field. The only difference is I was out of XR900s so I used 5.Xghz cards. Initially I could not relicate the problem. So I decided to enduce some noise (a Trango AP randomly pointing to and away and to the test bed in a controlled fassion). I was able to replicate the problem. And yes the 411 system (equivellent to clientB) that had 5db better signal was the one that dropped link when the Trango noise was induced, just like in the field. What was most interesting is the results of the Bandwdith test, when noise was induced. Note we were simultaneously running 1500byte ping across both radios simultanous to MT bandwidth test to clientB, and accross clientA we ran a timed Iperf to generate triffic. . When noise was slowly induced, the pings stopped passing traffic first, then about a second or two later, the MT Bandwidth test (same results set at UDP or TCP) started the incremental slow down, 800mbps to 700mbps, to 500mbps, to 300 mbps until reached Zero, and then when at Zero the wifi session to ClientB dropped. So first thing we realized is that the MT Bandwdith test incremental slow down was a misleading symptom. Its the results the tool will always show when any Noise gets injected onto the link to the level that full packet traffic won't pass. Second thing noticed... In our original test bed, clientB was on Station WDS, and CLientA on WDS Slave. This is because clientB is the 411 board and has License level 3, and we figured it would only support station modes. We also switched ClientA to station WDS, and when we did that, and injected noise, it took a bit longer and more noise before the noise caused links to drop, and it also eventually caused ClientA to also drop along with ClientB. That last test was done at end of day, as we were finishing up. Tommorrow, we are going to substitute a 433board for teh 411 board, and see if we get different results or not. Tommorrow we are also going to try different configuration methods other than WDS modes, to see if the links drop as easilly in the same way or not. So in summary I can conclusively say.... The original way I had radio configured wa sperfectly acceptable for low noise conditions. But with 900Mhz, I surely will run into sporatic noise, atleast at that site.. It is clear that noise was integating the odd behavior from the MT radios. It is also clear noise was at the AP side. What we still will be investigating is how come one radio was effected more than the other, and if we can find alternate MT configs to allow clients to be more noise resilient. In a nutshell, disconnections occured to soon on the one unit. Tom DeReggi RapidDSL & Wireless, Inc IntAirNet- Fixed Wireless Broadband ----- Original Message ----- From: "Josh Luthman" <j...@imaginenetworksllc.com> To: "WISPA General List" <wireless@wispa.org> Sent: Thursday, September 17, 2009 4:04 PM Subject: Re: [WISPA] Mikrotik Problem - 900Mhz-WDS-incremental speeddegradetp Zero then drop- repeat. > WDS and nstreme can be used with wireless-test I hear. Before that it was > not workable at all. > > Any load seems to kill your links - that has to be kept on mind. > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > > "When you have eliminated the impossible, that which remains, however > improbable, must be the truth." > --- Sir Arthur Conan Doyle > > > On Thu, Sep 17, 2009 at 3:41 PM, Tom DeReggi > <wirelessn...@rapiddsl.net>wrote: > >> > Well your problem reminded me of wds + nstreme problem is why I >> > brought it up. I believe wireless-test will fix this. >> >> How can WDS and NStreme be used togeather? >> I thought it had to be one or the other? >> >> > Any way you could test the links disconnected from the rest of the >> > network and see if stressing the links drops it? >> >> Will do that if necessary, after firmware update. >> >> > Are the links losing wireless association? >> >> Yes, they do when it reaches Zero mbps, then immediately restablishes >> association. >> >> Tom DeReggi >> RapidDSL & Wireless, Inc >> IntAirNet- Fixed Wireless Broadband >> >> >> ----- Original Message ----- >> From: "Josh Luthman" <j...@imaginenetworksllc.com> >> To: "WISPA General List" <wireless@wispa.org> >> Sent: Wednesday, September 16, 2009 9:43 PM >> Subject: Re: [WISPA] Mikrotik Problem - 900Mhz-WDS-incremental speed >> degradetp Zero then drop- repeat. >> >> >> > Well your problem reminded me of wds + nstreme problem is why I >> > brought it up. I believe wireless-test will fix this. >> > >> > Any way you could test the links disconnected from the rest of the >> > network and see if stressing the links drops it? >> > >> > Are the links losing wireless association? >> > >> > On 9/16/09, Tom DeReggi <wirelessn...@rapiddsl.net> wrote: >> >> No I am not using nstreme now. >> >> >> >> However, to expand on the conversations....and history of the job.... >> >> I >> >> am >> >> using WDS because that is the standard configuration that has always >> >> worked >> >> for us. We have a central routing platform at the nearest regional >> >> tower >> >> and >> >> bandwdith manage via VLAN, so we wanted all our leg radios to be true >> >> bridges, for easy consistent management of IP space. Many of our MT >> >> isntalls >> >> are configured for VLAN. When we originally selected WDS for our >> standard >> >> config, taht was like 3 years ago, with the earlier MT 2.X versions, >> >> and >> >> some of teh alternate methods did not properly work as stated in >> >> manual. >> >> For >> >> example, back then Station WDS didn't work right. Now a couple years >> >> later, >> >> and up to many version of 3.X, we want to re-investigate what is best >> >> practices. >> >> >> >> In this particular case, Subscriber A had to be a true bridge for >> various >> >> reasons so used WDS. But SubscriberB was an end user residential >> >> client, >> >> connected with a Linksys router, and could have worked fine as a >> standard >> >> wifi client. What we tried to do first was setup a Virtual AP. Leave >> >> Custoemr A on WDS, and then setup CustomerB as a standard wifi station >> on >> >> the Virtual AP standard AP. But we couldn't get the Virtual AP to pass >> >> traffic. We weren't sure if it was a config mistake or a incompatible >> >> configuration, doing both WDS and Virtual AP on the same WLAN. So that >> is >> >> why we reconfigured everything back to all WDS. >> >> >> >> We are looking for alternate configuration options, if better. In this >> >> particular case, we were very concerned about hidden node type issues, >> >> and >> >> concerned using regular WDS for both clients could cause significant >> >> Hideen >> >> Node type colissions or self interference. SubA was like 5 miles >> >> away, >> >> and >> >> pushes much larger amount of traffic, SubB was like 1 mile away, and >> >> low >> >> use >> >> residential. We were concerned Residential SubB could get performance >> >> issues >> >> because of SubA's traffic use. We were debating whether NStreme w/ >> >> polling >> >> would have been the best configuration for the solution. Does NStreme >> >> polling allow full bridging like WDS? >> >> >> >> Do you have any recommendations on best practice config now for MT >> >> PTMP, >> >> (without routing)? >> >> >> >> Tom DeReggi >> >> RapidDSL & Wireless, Inc >> >> IntAirNet- Fixed Wireless Broadband >> >> >> >> >> >> ----- Original Message ----- >> >> From: "Josh Luthman" <j...@imaginenetworksllc.com> >> >> To: "WISPA General List" <wireless@wispa.org> >> >> Sent: Wednesday, September 16, 2009 12:42 PM >> >> Subject: Re: [WISPA] Mikrotik Problem - 900Mhz-WDS-incremental speed >> >> degradetp Zero then drop- repeat. >> >> >> >> >> >>> You're not using nstreme are you? >> >>> >> >>> Josh Luthman >> >>> Office: 937-552-2340 >> >>> Direct: 937-552-2343 >> >>> 1100 Wayne St >> >>> Suite 1337 >> >>> Troy, OH 45373 >> >>> >> >>> "When you have eliminated the impossible, that which remains, however >> >>> improbable, must be the truth." >> >>> --- Sir Arthur Conan Doyle >> >>> >> >>> >> >>> On Tue, Sep 15, 2009 at 8:25 PM, Tom DeReggi >> >>> <wirelessn...@rapiddsl.net>wrote: >> >>> >> >>>> I have a problem with Mikrotik I have not been able to solve. >> Wondering >> >>>> if >> >>>> anyone has any insight. >> >>>> >> >>>> A summary config is.... >> >>>> >> >>>> I have a 433AH setup as AP with 1 XR900 and 1 R5H (5.8Ghz). The Cat5 >> >>>> Ethernet port goes to a SMC VLAN switch, where the SMC tags and >> >>>> untags >> >>>> VLAN >> >>>> ID, and continues to the Backhaul Radio. My point here is the MT >> itself >> >>>> does >> >>>> not have any VLAN configured. >> >>>> >> >>>> I need everything to act as a True Bridge, so I'm using WDS on >> >>>> everything. >> >>>> Both mPCI cards are set up as "AP" and then WDS interfaces >> >>>> configured. >> >>>> The R5H sector has one subscriber, so there is one WDS interface >> >>>> created >> >>>> for >> >>>> that. The XR900 has two subscriber points. So there are two WDS >> >>>> interfaces >> >>>> set up for the XR900 sector, one for each subscriber. So all three >> WDS >> >>>> interaces and the Ethernet (to backhaul) are all bridged togeather >> >>>> under >> >>>> one >> >>>> Bridge. >> >>>> >> >>>> SubscriberA has a 433AH also, and actually is a repeater site. So it >> >>>> has >> >>>> two >> >>>> mPCI each configured for WDS, and then the WDS ports bridged >> togeather. >> >>>> The >> >>>> primary mPCI that connects to the above first AP, is set for WDS >> Slave. >> >>>> This subscriberA (repeater radio) works normally. I can run MT >> >>>> bandwdith >> >>>> test continually at consistent speed. >> >>>> >> >>>> As well, the subscriber for the R5H sector above also is set up for >> WDS >> >>>> Salve, and works properly, and tests consistently with Bandwdith >> >>>> test. >> >>>> >> >>>> SubscriberB for 900Mhz sector is the problem. It is a RB411 w/ a >> 24V-1A >> >>>> PS, >> >>>> w/ XR900. Originally it was set for WDS Slave also. It is now set >> >>>> for >> >>>> WDS >> >>>> Station, and performs the same as if WDS Slave. When running MT >> >>>> Bandwdith >> >>>> test both UDP or TCP, Sitting at the 433AH AP's winbox, I get the >> >>>> following >> >>>> results.... TXing it works perfectly and consistently. >> >>>> But if doing a receive test.... It starts out at about 800 kbps, >> >>>> then >> >>>> slowly >> >>>> reduces speed incrementally, down to 500 kbps, to 300kbps, to >> >>>> 100kbps, >> >>>> etc, >> >>>> down to Zero. When it reaches Zero mbps, the radio link disconnects, >> >>>> and >> >>>> immediately restarts itself. Speed starts back up at 800 kbps or so, >> >>>> and >> >>>> the >> >>>> same thing repeats. If doing Bi-directional tests of course the same >> >>>> thing >> >>>> applies, because it receives also. >> >>>> >> >>>> Noise is low at teh SU, about -67, and -74 at AP. At first I >> >>>> thought >> >>>> it >> >>>> was >> >>>> noise at the IP, because occastionally SNR gets very low. .But.... >> >>>> SubscriberA has a lower signal at -84 and does not experience the >> >>>> same >> >>>> problem. Just for grins, I tried playing around with TRansmit power >> at >> >>>> the >> >>>> SubscriberB, but that had no positive effect. As well, as a test, I >> >>>> disabled the second WDS interface to SubscriberA, and no change. >> >>>> >> >>>> To be clear... SubscriberA and SubscriberB each have their own WDS >> >>>> interface >> >>>> configured on WLAN1 of the 433AH AP. >> >>>> I am using embedded MTOS V 3.10 on each. >> >>>> >> >>>> What is causing this problem? Why is speed received from my >> >>>> SubscriberB >> >>>> incrementally degrading and breaking link? >> >>>> >> >>>> Bridge loops? Is my config valid? RB411 Bug? >> >>>> >> >>>> Tom DeReggi >> >>>> RapidDSL & Wireless, Inc >> >>>> IntAirNet- Fixed Wireless Broadband >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> -------------------------------------------------------------------------------- >> >>>> WISPA Wants You! Join today! >> >>>> http://signup.wispa.org/ >> >>>> >> >>>> >> -------------------------------------------------------------------------------- >> >>>> >> >>>> WISPA Wireless List: wireless@wispa.org >> >>>> >> >>>> Subscribe/Unsubscribe: >> >>>> http://lists.wispa.org/mailman/listinfo/wireless >> >>>> >> >>>> Archives: http://lists.wispa.org/pipermail/wireless/ >> >>>> >> >>> >> >>> >> >>> >> -------------------------------------------------------------------------------- >> >>> WISPA Wants You! Join today! >> >>> http://signup.wispa.org/ >> >>> >> -------------------------------------------------------------------------------- >> >>> >> >>> WISPA Wireless List: wireless@wispa.org >> >>> >> >>> Subscribe/Unsubscribe: >> >>> http://lists.wispa.org/mailman/listinfo/wireless >> >>> >> >>> Archives: http://lists.wispa.org/pipermail/wireless/ >> >> >> >> >> >> >> >> >> -------------------------------------------------------------------------------- >> >> WISPA Wants You! Join today! >> >> http://signup.wispa.org/ >> >> >> -------------------------------------------------------------------------------- >> >> >> >> WISPA Wireless List: wireless@wispa.org >> >> >> >> Subscribe/Unsubscribe: >> >> http://lists.wispa.org/mailman/listinfo/wireless >> >> >> >> Archives: http://lists.wispa.org/pipermail/wireless/ >> >> >> > >> > >> > -- >> > Josh Luthman >> > Office: 937-552-2340 >> > Direct: 937-552-2343 >> > 1100 Wayne St >> > Suite 1337 >> > Troy, OH 45373 >> > >> > "When you have eliminated the impossible, that which remains, however >> > improbable, must be the truth." >> > --- Sir Arthur Conan Doyle >> > >> > >> > >> -------------------------------------------------------------------------------- >> > WISPA Wants You! Join today! >> > http://signup.wispa.org/ >> > >> -------------------------------------------------------------------------------- >> > >> > WISPA Wireless List: wireless@wispa.org >> > >> > Subscribe/Unsubscribe: >> > http://lists.wispa.org/mailman/listinfo/wireless >> > >> > Archives: http://lists.wispa.org/pipermail/wireless/ >> >> >> >> >> -------------------------------------------------------------------------------- >> WISPA Wants You! Join today! >> http://signup.wispa.org/ >> >> -------------------------------------------------------------------------------- >> >> WISPA Wireless List: wireless@wispa.org >> >> Subscribe/Unsubscribe: >> http://lists.wispa.org/mailman/listinfo/wireless >> >> Archives: http://lists.wispa.org/pipermail/wireless/ >> > > > -------------------------------------------------------------------------------- > WISPA Wants You! Join today! > http://signup.wispa.org/ > -------------------------------------------------------------------------------- > > WISPA Wireless List: wireless@wispa.org > > Subscribe/Unsubscribe: > http://lists.wispa.org/mailman/listinfo/wireless > > Archives: http://lists.wispa.org/pipermail/wireless/ -------------------------------------------------------------------------------- WISPA Wants You! Join today! http://signup.wispa.org/ -------------------------------------------------------------------------------- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
