RE: [WISPA] Mikrotik Bridging w-Nstreme

2006-02-09 Thread G.Villarini
Turn off connection tracking under firewall

Gino A. Villarini, 
Aeronet Wireless Broadband Corp.
[EMAIL PROTECTED]
www.aeronetpr.com
787.273.4143


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Tom DeReggi
Sent: Thursday, February 09, 2006 1:30 AM
To: WISPA General List
Subject: Re: [WISPA] Mikrotik Bridging w-Nstreme

Thought I'd share my test results on NStreme.

I am happy with John Tulley's (Mikrotik's) attitude, in the sense that they 
are constantly trying to improve their product, and listening to comments 
from users of their product, and attempting to make sure users are not 
misinformed about the features of their product. They are smart guys, that 
have a lot of skin in the game, and experience beyond many in this industry.

I think Mikrotik is on to something, in their attempt to make a better 
protocol to enhance Wifi, and commend them on their guts to do so. However, 
with that said, I was rather disappointed with the results of NStreme in my 
testing.  I think its still needs a lot of work.

I used the same test bed I've been talking about the past few days 
(originally with Trango), 10 miles, -47db rssi on Mikrotik w/Range5, one 
radio per 532 MB, 2 ft quickfire dish.

My goal was to test how Mikrotik handled packet loss, when it was thrown at 
it at different speeds.  I used three primary tools for testing performance.

Mikrotik's included Btest/bandwdith tester and Iperf TCP and IPerf UDP.

I was surprised to see that Mikrotik's Built-in BTest program actually 
performed (on Average) pretty darn close to the results that I got with 
Iperf. It was hard to tell that at first because BTest is a bit jumpy with 
sparatic speeds, but the average reading was pretty close if an eye was kept

on it.  Iperf was more accurate in getting precise results.  The most useful

test is Iperf UDP. The reason is that Iperf will show you at what point 
(speed) you start to get packet loss and how much. All of Mikrotik's 
performance tests, leave out packet loss in their results, so you can't 
see the effect or choke points.  In a real world enviroment, with lots of 
subscribers and over subscription, its likely that a link will get hammered 
from time to time, and nice to know what will happen from a packet loss 
point of view when limits are reached.  But the biggest help of Iperf UDP, 
is to detect the MAX speed possible from the radio, and at what trade off of

packet loss.  The Iperf UDP speed results is what should be utilized for 
configuring bandwdith management tools. Tke note: That Iperf purpose is to 
see what point packetloss will occur, and it ALWAYS occurs with any 
connection which is pushed beyond its limits. no inteligence at other layers

is applied to slow tranmittingto reduce packet loss.

My goal was to compare Nstreme to not using NStreme. (used new version 9.12)

The majority of the time the Station side, negotiated at 54 mbps, however on

the AP-bride side negotiated speed could jump around from 48mbps to 6 mbps. 
but usually around 36 mbps (QAM16) majority of the time.  I was watching the

negotiated rate at the same time as testing to look for modulation change. 
It didn't change often. To be clear tests were done with WDS mode, and all 
default auto settings. Polling was turned off since a PtP link. And best 
fit, was tried on and off, however, that would not have much effect, as 
Iperf was sending consistent size packets of 1470 bytes.  Often people will 
see better speeds and less packet loss when testing with smaller packets, 
but to get menaing ful results its important to test a full packet size.

Mikrotik reported a Tx CCQ of 93-98% and noise floor of -101, in status of 
WLAN..

In Iperf you set the speed at which you want to send data to the link, and 
then it reports the speed transfer at and at what packet loss.  I ran the 
tests several times for each speed, so I had a good average to consider.

I was stunned by the results.

Using NStreme
Throughput (mbps) /  Packet loss.
6M / .12%
8M / 1% - 2.4%
10M / 1.2% - 8%
12M / 4%
13M / 8.3%
15M / 21%
18M / 35%

In summary, NStreme could perform well without packet loss at about up to 
8mbps.

Using Standard Wifi

10M / .73%
12M / .36%
13M / 1.8%
18M / 2.2%
19M and up- started to see high packet loss

Without NStreme, I could push almost 18mbps at the same packet loss 
Nstreme's 8mbps. And at 12mbps, I got very low packet loss. So in summary, 
Standard Wifi doubled the throughput of NStreme.

Unless there is some hidden tuning commands for NStreme, its not cutting it 
yet, over default Wifi.

Using Mikrotiks BTest, I got about 8M (4mbps in each direction) with 
NStreme, and about 12M (6-7mbps one way, and 5-6mbps in the other.). 
Likewise I tried Iperf TCP, which produced results very similar to 
Mikrotik's average.

Note: understand that this enviroment may have some noise considerations, 
tested to be around -80db with Trango. I tested the Mikrotik using 5.3Ghz

RE: [WISPA] Mikrotik Bridging w-Nstreme

2006-02-09 Thread danlist
I am not seeing results like this at all, I am using nstream on several PTP
links w/ SR5 cards w/ great success, (polling on) - throughput is awesome and I
have replaced all of my karlnet backhaul links (well not replaced but turned the
karlnet links into backup links), I believe mikrotik is definitely the next
wave, so much that I have started offering complete AP/CPE solution kits through
my web store @ http://store.wbisp.com/ (site just went up last night so its
under construction)

Mikrotik is really bringing a great product to the market and w/ the coming sr9
cards there will be a lot of options on the table for the WISP's


 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
 Of Tom DeReggi
 Sent: Thursday, February 09, 2006 1:29 AM
 To: WISPA General List
 Subject: Re: [WISPA] Mikrotik Bridging w-Nstreme
 
 This problem was solved thanks to prompt tech support from Wisp-Router.
 
 With NStreme enabled, it is necessary to assign the IP to the Bridged port,
 not ether1.
 However, without Nstreme enabled, it works fine with IP assigned to Ether1,
 as long as bridged to WLAN.
 (The same way that always worked with Star OS)
 
 There were also a couple odd things related to what order setting were
 checked converting from one config to another, that kept Nstreme from
 working, which we were able to replicate after the fact (after tech
 support), to prove we weren't crazy.  Unfortuneately, I can't remember now,
 what exactly the sequence was, 5 hours later. For example, there were times
 when we enabled Nstreme correctly , and it just wouldn't connect. But we
 then disabled it, got WDS to talk again, and then re-enabled it
 successfully. It may have had something todo with one side of the link being
 completely configured before the other. Because if both aren't on Nstreme
 they dont talk at the radio level. So the rule was when a configuration
 didn't talk, disble NStreme, make it talk, then re-enable, and it would
 work.
 
 What I do like about Mikrotik, is that its all there infront of you, all the
 tools, all the features, as needed. Its pretty well laid out, once you get
 the hang of it.
 
 Probably the biggest feature I saw missing, was it didn't support diversity
 mode on the Wireless driver.  It was A or B or Full Duplex. But not
 diversity.
 
 One of the nice things about Star-OS was that it supported diversity mode,
 but also it was less critical to configuration errors.
 
 Tom DeReggi
 RapidDSL  Wireless, Inc
 IntAirNet- Fixed Wireless Broadband
 
 
 - Original Message -
 From: Tom DeReggi [EMAIL PROTECTED]
 To: WISPA General List wireless@wispa.org
 Sent: Wednesday, February 08, 2006 5:44 PM
 Subject: Re: [WISPA] Mikrotik Bridging w-Nstreme
 
 
  Thats exactly what we are trying to do, but its not working, using version
  9.12.
 
  If I try ping radios
 
  When sniffing, the station sees traffic comming in, but the AP-bridge,
  sees no traffic comming in.
 
  I correctly have put both interfaces Ether1 and WDS1 to the same bridge1.
  Won't pass traffic the second Nstreme gets selected.
 
  The IP is assigned to the ether1 port on each of the sides.
 
  I have the same problem trying to do it without WDS and straight WLAN1. I
  can;t pass traffic the second Nstreme gets selected.
 
  Tom DeReggi
  RapidDSL  Wireless, Inc
  IntAirNet- Fixed Wireless Broadband
 
 
  - Original Message -
  From: JNA [EMAIL PROTECTED]
  To: 'WISPA General List' wireless@wispa.org
  Sent: Wednesday, February 08, 2006 12:32 AM
  Subject: RE: [WISPA] Mikrotik Bridging w-Nstreme
 
 
 
  However, it appears their may be is a flaw in config options, in the
  sense
  that there is no way to get NStreme to work in PTMP modes as a True
  bridge,
  as that would require WDS-AP and WDS-Slave which is not a supported
  config.
  Am I correct on this? Or when NStreme is used, can I safely use WDS-
  station,
  and be a true bridge?
 
  Tom,
 
  We are doing this. We have the base set to ap bridge, with dynamic wds
  enabled using nstream and polling. Backhaul on the towers using wds
  station
  WDS with dynamic wds enabled using nstream and polling. We then have an
  omni
  off the routerboard and the Ethernet connected to a trango 900 base via
  cross over. It is working as a full bridge and our clients get dhcp from
  the
  gateway server at the other end with no problem. I think this is what you
  are looking at doing and If so it is working for us.
 
  John
 
  --
  WISPA Wireless List: wireless@wispa.org
 
  Subscribe/Unsubscribe:
  http://lists.wispa.org/mailman/listinfo/wireless
 
  Archives: http://lists.wispa.org/pipermail/wireless/
 
  --
  WISPA Wireless List: wireless@wispa.org
 
  Subscribe/Unsubscribe:
  http://lists.wispa.org/mailman/listinfo/wireless
 
  Archives: http://lists.wispa.org/pipermail/wireless/
 
 --
 WISPA Wireless List: wireless@wispa.org
 
 Subscribe/Unsubscribe:
 http://lists.wispa.org/mailman/listinfo/wireless
 
 Archives: http

Re: [WISPA] Mikrotik Bridging w-Nstreme

2006-02-08 Thread Tom DeReggi
Thats exactly what we are trying to do, but its not working, using version 
9.12.


If I try ping radios

When sniffing, the station sees traffic comming in, but the AP-bridge, sees 
no traffic comming in.


I correctly have put both interfaces Ether1 and WDS1 to the same bridge1. 
Won't pass traffic the second Nstreme gets selected.


The IP is assigned to the ether1 port on each of the sides.

I have the same problem trying to do it without WDS and straight WLAN1. I 
can;t pass traffic the second Nstreme gets selected.


Tom DeReggi
RapidDSL  Wireless, Inc
IntAirNet- Fixed Wireless Broadband


- Original Message - 
From: JNA [EMAIL PROTECTED]

To: 'WISPA General List' wireless@wispa.org
Sent: Wednesday, February 08, 2006 12:32 AM
Subject: RE: [WISPA] Mikrotik Bridging w-Nstreme




However, it appears their may be is a flaw in config options, in the 
sense

that there is no way to get NStreme to work in PTMP modes as a True
bridge,
as that would require WDS-AP and WDS-Slave which is not a supported
config.
Am I correct on this? Or when NStreme is used, can I safely use WDS-
station,
and be a true bridge?


Tom,

We are doing this. We have the base set to ap bridge, with dynamic wds
enabled using nstream and polling. Backhaul on the towers using wds 
station
WDS with dynamic wds enabled using nstream and polling. We then have an 
omni

off the routerboard and the Ethernet connected to a trango 900 base via
cross over. It is working as a full bridge and our clients get dhcp from 
the

gateway server at the other end with no problem. I think this is what you
are looking at doing and If so it is working for us.

John

--
WISPA Wireless List: wireless@wispa.org

Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless

Archives: http://lists.wispa.org/pipermail/wireless/ 


--
WISPA Wireless List: wireless@wispa.org

Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless

Archives: http://lists.wispa.org/pipermail/wireless/


Re: [WISPA] Mikrotik Bridging w-Nstreme

2006-02-08 Thread Tom DeReggi

Thought I'd share my test results on NStreme.

I am happy with John Tulley's (Mikrotik's) attitude, in the sense that they 
are constantly trying to improve their product, and listening to comments 
from users of their product, and attempting to make sure users are not 
misinformed about the features of their product. They are smart guys, that 
have a lot of skin in the game, and experience beyond many in this industry. 
I think Mikrotik is on to something, in their attempt to make a better 
protocol to enhance Wifi, and commend them on their guts to do so. However, 
with that said, I was rather disappointed with the results of NStreme in my 
testing.  I think its still needs a lot of work.


I used the same test bed I've been talking about the past few days 
(originally with Trango), 10 miles, -47db rssi on Mikrotik w/Range5, one 
radio per 532 MB, 2 ft quickfire dish.


My goal was to test how Mikrotik handled packet loss, when it was thrown at 
it at different speeds.  I used three primary tools for testing performance. 
Mikrotik's included Btest/bandwdith tester and Iperf TCP and IPerf UDP.


I was surprised to see that Mikrotik's Built-in BTest program actually 
performed (on Average) pretty darn close to the results that I got with 
Iperf. It was hard to tell that at first because BTest is a bit jumpy with 
sparatic speeds, but the average reading was pretty close if an eye was kept 
on it.  Iperf was more accurate in getting precise results.  The most useful 
test is Iperf UDP. The reason is that Iperf will show you at what point 
(speed) you start to get packet loss and how much. All of Mikrotik's 
performance tests, leave out packet loss in their results, so you can't 
see the effect or choke points.  In a real world enviroment, with lots of 
subscribers and over subscription, its likely that a link will get hammered 
from time to time, and nice to know what will happen from a packet loss 
point of view when limits are reached.  But the biggest help of Iperf UDP, 
is to detect the MAX speed possible from the radio, and at what trade off of 
packet loss.  The Iperf UDP speed results is what should be utilized for 
configuring bandwdith management tools. Tke note: That Iperf purpose is to 
see what point packetloss will occur, and it ALWAYS occurs with any 
connection which is pushed beyond its limits. no inteligence at other layers 
is applied to slow tranmittingto reduce packet loss.


My goal was to compare Nstreme to not using NStreme. (used new version 9.12)

The majority of the time the Station side, negotiated at 54 mbps, however on 
the AP-bride side negotiated speed could jump around from 48mbps to 6 mbps. 
but usually around 36 mbps (QAM16) majority of the time.  I was watching the 
negotiated rate at the same time as testing to look for modulation change. 
It didn't change often. To be clear tests were done with WDS mode, and all 
default auto settings. Polling was turned off since a PtP link. And best 
fit, was tried on and off, however, that would not have much effect, as 
Iperf was sending consistent size packets of 1470 bytes.  Often people will 
see better speeds and less packet loss when testing with smaller packets, 
but to get menaing ful results its important to test a full packet size.


Mikrotik reported a Tx CCQ of 93-98% and noise floor of -101, in status of 
WLAN..


In Iperf you set the speed at which you want to send data to the link, and 
then it reports the speed transfer at and at what packet loss.  I ran the 
tests several times for each speed, so I had a good average to consider.


I was stunned by the results.

Using NStreme
Throughput (mbps) /  Packet loss.
6M / .12%
8M / 1% - 2.4%
10M / 1.2% - 8%
12M / 4%
13M / 8.3%
15M / 21%
18M / 35%

In summary, NStreme could perform well without packet loss at about up to 
8mbps.


Using Standard Wifi

10M / .73%
12M / .36%
13M / 1.8%
18M / 2.2%
19M and up- started to see high packet loss

Without NStreme, I could push almost 18mbps at the same packet loss 
Nstreme's 8mbps. And at 12mbps, I got very low packet loss. So in summary, 
Standard Wifi doubled the throughput of NStreme.


Unless there is some hidden tuning commands for NStreme, its not cutting it 
yet, over default Wifi.


Using Mikrotiks BTest, I got about 8M (4mbps in each direction) with 
NStreme, and about 12M (6-7mbps one way, and 5-6mbps in the other.). 
Likewise I tried Iperf TCP, which produced results very similar to 
Mikrotik's average.


Note: understand that this enviroment may have some noise considerations, 
tested to be around -80db with Trango. I tested the Mikrotik using 5.3Ghz, 
but performance was not better, but 10.5 miles is a long shot for 5.3Ghz at 
the lower radio output power.


If anyone has any hints on improving NStreme performance let me know, I'll 
have the test link up for about another 24 hours.


Tom DeReggi
RapidDSL  Wireless, Inc
IntAirNet- Fixed Wireless Broadband

--
WISPA Wireless List: wireless@wispa.org


Re: [WISPA] Mikrotik Bridging w-Nstreme

2006-02-08 Thread Tom DeReggi

This problem was solved thanks to prompt tech support from Wisp-Router.

With NStreme enabled, it is necessary to assign the IP to the Bridged port, 
not ether1.
However, without Nstreme enabled, it works fine with IP assigned to Ether1, 
as long as bridged to WLAN.

(The same way that always worked with Star OS)

There were also a couple odd things related to what order setting were 
checked converting from one config to another, that kept Nstreme from 
working, which we were able to replicate after the fact (after tech 
support), to prove we weren't crazy.  Unfortuneately, I can't remember now, 
what exactly the sequence was, 5 hours later. For example, there were times 
when we enabled Nstreme correctly , and it just wouldn't connect. But we 
then disabled it, got WDS to talk again, and then re-enabled it 
successfully. It may have had something todo with one side of the link being 
completely configured before the other. Because if both aren't on Nstreme 
they dont talk at the radio level. So the rule was when a configuration 
didn't talk, disble NStreme, make it talk, then re-enable, and it would 
work.


What I do like about Mikrotik, is that its all there infront of you, all the 
tools, all the features, as needed. Its pretty well laid out, once you get 
the hang of it.


Probably the biggest feature I saw missing, was it didn't support diversity 
mode on the Wireless driver.  It was A or B or Full Duplex. But not 
diversity.


One of the nice things about Star-OS was that it supported diversity mode, 
but also it was less critical to configuration errors.


Tom DeReggi
RapidDSL  Wireless, Inc
IntAirNet- Fixed Wireless Broadband


- Original Message - 
From: Tom DeReggi [EMAIL PROTECTED]

To: WISPA General List wireless@wispa.org
Sent: Wednesday, February 08, 2006 5:44 PM
Subject: Re: [WISPA] Mikrotik Bridging w-Nstreme


Thats exactly what we are trying to do, but its not working, using version 
9.12.


If I try ping radios

When sniffing, the station sees traffic comming in, but the AP-bridge, 
sees no traffic comming in.


I correctly have put both interfaces Ether1 and WDS1 to the same bridge1. 
Won't pass traffic the second Nstreme gets selected.


The IP is assigned to the ether1 port on each of the sides.

I have the same problem trying to do it without WDS and straight WLAN1. I 
can;t pass traffic the second Nstreme gets selected.


Tom DeReggi
RapidDSL  Wireless, Inc
IntAirNet- Fixed Wireless Broadband


- Original Message - 
From: JNA [EMAIL PROTECTED]

To: 'WISPA General List' wireless@wispa.org
Sent: Wednesday, February 08, 2006 12:32 AM
Subject: RE: [WISPA] Mikrotik Bridging w-Nstreme




However, it appears their may be is a flaw in config options, in the 
sense

that there is no way to get NStreme to work in PTMP modes as a True
bridge,
as that would require WDS-AP and WDS-Slave which is not a supported
config.
Am I correct on this? Or when NStreme is used, can I safely use WDS-
station,
and be a true bridge?


Tom,

We are doing this. We have the base set to ap bridge, with dynamic wds
enabled using nstream and polling. Backhaul on the towers using wds 
station
WDS with dynamic wds enabled using nstream and polling. We then have an 
omni

off the routerboard and the Ethernet connected to a trango 900 base via
cross over. It is working as a full bridge and our clients get dhcp from 
the

gateway server at the other end with no problem. I think this is what you
are looking at doing and If so it is working for us.

John

--
WISPA Wireless List: wireless@wispa.org

Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless

Archives: http://lists.wispa.org/pipermail/wireless/


--
WISPA Wireless List: wireless@wispa.org

Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless

Archives: http://lists.wispa.org/pipermail/wireless/ 


--
WISPA Wireless List: wireless@wispa.org

Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless

Archives: http://lists.wispa.org/pipermail/wireless/


[WISPA] Mikrotik Bridging w-Nstreme

2006-02-07 Thread Tom DeReggi
When using Mikrotik, if I want to do a true bridging configuration (like an 
ehternet Switch), if I set AP mode on one side and Client mode on the other, 
it does not work because default 802.11 clients do not support bridging.  To 
solve this, without using Nstreme, we used WDS mode.  One side set to 
AP-bridge/WDS and the other side WDS-slave.  In this configuration we can 
VLAN, bridge complete networks and full range of Mac Addresses, and support 
PtMP configs, etc.


However, I would like to use Nstreme, and that is where I get confused on 
configuration.


For PTP, Mikrotik suggests setting one side as Bridge Mode w/ Nstreme 
enabled, and the other side Client mode w/ Nstreme enabled.
Under this configuration, is it a true bridge, as I desire? (Pass multiple 
Macs and stuff).


If so, is there any reason to use Nstreme w/WDS anymore, if just doing a PtP 
backaul link between cell sites?
MIkrotik states if WDS-station mode is used on one side of link, WDS will 
work with Nstreme.

In WDS-station mode w/Nstreme, does it also infact act as a true bridge?

However, it appears their may be is a flaw in config options, in the sense 
that there is no way to get NStreme to work in PTMP modes as a True bridge, 
as that would require WDS-AP and WDS-Slave which is not a supported config. 
Am I correct on this? Or when NStreme is used, can I safely use WDS-station, 
and be a true bridge?


Tom DeReggi
RapidDSL  Wireless, Inc
IntAirNet- Fixed Wireless Broadband

--
WISPA Wireless List: wireless@wispa.org

Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless

Archives: http://lists.wispa.org/pipermail/wireless/