Now that is very useful info Tom. I look forward to your next report. Thanks! -RickG
On Wed, Sep 23, 2009 at 3:29 AM, Tom DeReggi <[email protected]> wrote: > 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" <[email protected]> > To: "WISPA General List" <[email protected]> > 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 >> <[email protected]>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" <[email protected]> >>> To: "WISPA General List" <[email protected]> >>> 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 <[email protected]> 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" <[email protected]> >>> >> To: "WISPA General List" <[email protected]> >>> >> 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 >>> >>> <[email protected]>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: [email protected] >>> >>>> >>> >>>> 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: [email protected] >>> >>> >>> >>> 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: [email protected] >>> >> >>> >> 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: [email protected] >>> > >>> > 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: [email protected] >>> >>> 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: [email protected] >> >> 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: [email protected] > > 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: [email protected] Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
