Community discussions

MikroTik App
 
soulmata
just joined
Topic Author
Posts: 5
Joined: Wed Aug 29, 2012 12:12 am

Achieving good throughput on very short range PTP bridge

Wed Aug 29, 2012 12:47 am

Hello,

Short summary: I am having difficulty in getting good wireless performance out of a bridge. I would like suggestions on ideal configuration.

The hardware and software I am using is as follows:
2x RBSXTG-5HnD
license level: 3
current software version: 2.38

I have configured a PTP bridge, following the MT wiki, attempting to use the most ideal options presented. The particular issues I am having are extremely low throughput, especially for 802.11N compatible hardware with absolutely no noise (I spent many hours with a spectrum analyzer ensuring the channels selected were free, and experimented with other channels as well). The particular symptoms I am seeing are:

* Terrible throughput (<30Mbp/s sustained throughput with single/multiple TCP stream with small/large packets)
* Very bad latency (>7ms)
* Very inconsistent throughput and latency

Some interesting notes:

* When I begin to sustain traffic to a downstream host, latency drops by nearly 10 fold, to ~0.8-1.2ms, where it really should be.
* This bad performance is not affected by changing frequencies or synchronization rates

Here's the configuration parameters of the wireless link:

Bridge 1:
0 R name="wlan1-gateway" mtu=1500 mac-address=00:0C:42:F2:4B:C2 arp=enabled interface-type=Atheros 11N mode=bridge ssid="tera-bridge" frequency=5180 band=5ghz-onlyn channel-width=20/40mhz-ht-above scan-list=default wireless-protocol=nv2 wds-mode=disabled
wds-default-bridge=none wds-ignore-ssid=no bridge-mode=enabled default-authentication=yes default-forwarding=yes default-ap-tx-limit=0 default-client-tx-limit=0 hide-ssid=no security-profile=default compression=no

Bridge 2:
0 R name="wlan1-gateway" mtu=1500 mac-address=00:0C:42:F6:0A:28 arp=enabled interface-type=Atheros 11N mode=station-bridge ssid="tera-bridge" frequency=5180 band=5ghz-onlyn channel-width=20/40mhz-ht-above scan-list=default wireless-protocol=nv2 wds-mode=disabled
wds-default-bridge=none wds-ignore-ssid=no bridge-mode=enabled default-authentication=yes default-forwarding=yes default-ap-tx-limit=0 default-client-tx-limit=0 hide-ssid=no security-profile=default compression=no

Association information:
0 wlan1-gateway 000C42F24BC2 00:0C:42:F2:4B:C2 yes -45dBm 270.... 4d21h52m1s

Nstreme configuration:
0 name="wlan1-gateway" enable-nstreme=yes enable-polling=yes disable-csma=no framer-policy=none framer-limit=3200

It's worth noting I upgraded to this hardware from some really ancient star hardware which was 802.11a only, not even 802.11N, and the throughput and latency was way better and more consistent. The distance between these routers is only about 20 feet. The goal for this link should be:

* Optimized for a pure PTP link. 1 client, 1 AP, bridged.
* Always maintains low latency (I use it for a remote file system, so low-traffic but latency is super critical)
* Has high maximum througput for 1-way transfers (when copying data to/from this remote file system)

For this hardware, with gigabit ethernet and a very clean 5GHz, I would expect >100Mbp/s. So, suggestions?
 
User avatar
nickshore
Member
Member
Posts: 477
Joined: Thu Mar 03, 2005 4:14 pm
Location: Suffolk, UK.
Contact:

Re: Achieving good throughput on very short range PTP bridge

Wed Aug 29, 2012 5:39 pm

First of all I would look at transmit power, and reduce it, your link is very short

Secondly look at the NV2 tab and set TDMA Period Size to 1, and reduce the cell radius to whatever it allows as lowest (I think this is 10km)

See if that helps

Nick.
Nick Shore MTCNA MTCWE MTCRE MTCINE MTCTCE
LinITX.com - MultiThread Consultants
Get your MikroTik RBs and Training: http://linitx.com/brand/mikrotik
Official UK MikroTik Distributor
IRC chan: #routerboard on irc.z.je (IPv4 and IPv6)
 
whitenoise
just joined
Posts: 10
Joined: Mon May 29, 2006 6:15 am
Location: Bulgaria

Re: Achieving good throughput on very short range PTP bridge

Thu Aug 30, 2012 12:14 am

use nstreme
 
soulmata
just joined
Topic Author
Posts: 5
Joined: Wed Aug 29, 2012 12:12 am

Re: Achieving good throughput on very short range PTP bridge

Thu Aug 30, 2012 12:21 am

nickshore:
I appreciate the suggestions. I will experiment tonight with both nv2 configuration options and with transmit power. I suppose it would also be good to ensure I'm using the latest firmware available. The TDMA configuration could be an explanation for the latency fluctuation. Thanks.

whitenoise:
If you read my post, you would see quite clearly that I [/i]am[/i] using nstreme, so that is not a very helpful answer.

It's worth noting I experimented with A/A testing using 802.11A, 802.11N, nstreme and nstreme v2.
 
taduikis
Member
Member
Posts: 427
Joined: Sat Jul 07, 2007 12:09 pm

Re: Achieving good throughput on very short range PTP bridge

Thu Aug 30, 2012 9:04 am

I too think you should try achieving your goal with nstreme. After many days spent trying to get nv2 working, I gave up and found nstreme superior in everything..
 
janisbvp
Frequent Visitor
Frequent Visitor
Posts: 75
Joined: Thu Jul 15, 2010 10:33 am

Re: Achieving good throughput on very short range PTP bridge

Thu Aug 30, 2012 2:30 pm

Just my 2 cents in here:
1. lower the transmit power until you are in mid-50 rx/tx (-55-60db)
2. in HT MCS tab on AP, leave only one mcs in both Supported and Basic MCS (try to avoid MCS 13-15 if you are in noisy environment)
http://www.dbii.com/wiki/index.php?titl ... outerboard
3. Use WDS bridging.
This should get you fast and stable link.
 
janisbvp
Frequent Visitor
Frequent Visitor
Posts: 75
Joined: Thu Jul 15, 2010 10:33 am

Re: Achieving good throughput on very short range PTP bridge

Thu Aug 30, 2012 2:38 pm

* Very bad latency (>7ms)
You should consider fiber if 7ms is high.
current software version: 2.38

This is routerboot version - software is 5.xx
I would expect >100Mbp/s
Definately depends on many factors, but don't hope for huge numbers.
* When I begin to sustain traffic to a downstream host, latency drops by nearly 10 fold, to ~0.8-1.2ms, where it really should be.
This is normal, for a link under load to switch modulations and nv2 especially reserves time slots bor busy clients.
 
soulmata
just joined
Topic Author
Posts: 5
Joined: Wed Aug 29, 2012 12:12 am

Re: Achieving good throughput on very short range PTP bridge

Thu Aug 30, 2012 8:52 pm

7ms is extremely high for an idle PTP link in a low noise environment with great SNR. I've assembled hundreds of bridge links over the years and have never seen equipment where 7ms on an idle link is "acceptable", except in cases where something like TDMA is being utilized -which is the case with nv2, I suppose. At the WISP I worked at for 6 years, 7ms was easily achievable from CPE to our edge, across perhaps four or five backhauls, using 802.11a.

Now, the explanation of nv2 of increasing priority for a client that begins transmitting makes sense - and perhaps nv2 is not ideal for a PTP link - if that was what whitenoise's earlier assertion was, I misread your intention and will definitely give that a try.

I was not aware that was the boot code version. I am not sure where to see the software version from the CLI.

For those who have suggested power leveling, your suggestions are definitely getting me somewhere - excessive power is definitely a contributing factor, and lowering it has provided me with greater link stability. I am not yet getting the throughput I want, but stability is a great starting point. I'll also try WDS bridging tonight and see how that changes things.

Thanks for the wiki reference, I have not yet seen that link and it looks much more informational than the wiki I looked at.
 
frankie
Member Candidate
Member Candidate
Posts: 116
Joined: Thu May 08, 2008 9:45 pm

Re: Achieving good throughput on very short range PTP bridge

Thu Aug 30, 2012 11:19 pm

I built a PtP link with par of RB600a, r52Hn, Cyberbajt GigaEter Duo 19 dBi WideBand 5GHz. Clear LOS. Distance aprox. 350meters. Wireless Protocol 5GHz-Only-N. MCS: 0,1,7,8,14,15. Signal levels: 54/55dB. Tx/Rx CCQ: 95-100%. P-Throughput 159-160mbit/sec. UDP-test shows 200mbit/sec bandwidth. Real world TCP-traffic 140mbit/sec. Copying from SAMBA server - 14MBytes/sec. Latency max. 9ms when traffic goes over 100mbit/sec. Idle latency is 1ms.
 
soulmata
just joined
Topic Author
Posts: 5
Joined: Wed Aug 29, 2012 12:12 am

Re: Achieving good throughput on very short range PTP bridge

Fri Aug 31, 2012 2:11 am

I built a PtP link with par of RB600a, r52Hn, Cyberbajt GigaEter Duo 19 dBi WideBand 5GHz. Clear LOS. Distance aprox. 350meters. Wireless Protocol 5GHz-Only-N. MCS: 0,1,7,8,14,15. Signal levels: 54/55dB. Tx/Rx CCQ: 95-100%. P-Throughput 159-160mbit/sec. UDP-test shows 200mbit/sec bandwidth. Real world TCP-traffic 140mbit/sec. Copying from SAMBA server - 14MBytes/sec. Latency max. 9ms when traffic goes over 100mbit/sec. Idle latency is 1ms.

That is very similar to my setup (ideal CCQ, samba and NFS traffic, ideal idle latency, etc). So it's good to know the performance I want is certainly possible, I just need to get my configuration right.

Could you post your detailed wireless configuration?
 
0ldman
Forum Guru
Forum Guru
Posts: 1446
Joined: Thu Jul 27, 2006 5:01 am

Re: Achieving good throughput on very short range PTP bridge

Fri Aug 31, 2012 9:34 pm

nv2 and nstreme both affect latency when the link is idle, but not so much when data is going across the link.

My backhaul with no data running nstreme, ping is erratic, 5ms, 23ms, 7ms, 37ms, etc.

My backhaul moving 10Mb, ping is consistently between 2ms and 5ms.

You are using ping as a diagnostic tool, which is fine. In this case the latency isn't an issue when moving data, only when idle.

What is the distance, what antennas, what is your signal strength? Single chain, right?
 
soulmata
just joined
Topic Author
Posts: 5
Joined: Wed Aug 29, 2012 12:12 am

Re: Achieving good throughput on very short range PTP bridge

Sat Sep 01, 2012 2:10 am

The latency is definitely an issue - there's a noticeable delay when accessing real-time resources, only when you first access them. Example: Fetching a file contents list on a directory. That operation takes less than 16.88ms (timed using perl) when using a generic 802.11g bridge (actually, UBNT hardware). When using this much newer 802.11n RB gear, it can take upwards of 4264ms.

If, however, I flood the connection and keep it flooded, response time drops substantially - back down to the sub-20ms range for the same operation. The instant I stop the flood, however, all FS operations again start take very, very long to respond. So, the response time of an individual ICMP packet is irrelevant to me - but something about the modulation or schema being used is definitely not functioning right, or I'm not deploying nv2 appropriately.

I posted my exact SNR, equipment and configuration in the very first post.

Who is online

Users browsing this forum: No registered users and 58 guests