You are here

Point to point thruput

11 posts / 0 new
Last post
km4eug
Point to point thruput
Using microtik LHG 
in native Spec it says it can do up to 300MBPS 
when you flash it with AREDN what speed can we expect in thru put?

shooting 10 mile ptp with clear shot 
Terry 
nc8q
nc8q's picture
raw data rate .vs. throughput

Hi, Terrry:
 
Um, you specified a Mikrotik RouterOS firmware raw data rate claim over an unspecified distance and
asked for a AREDN OS firmware throughput estimate.
Instead, let us compare RouterOS and AREDN raw data rate:
300 .vs. 144.4 Mbps
Next, you mentioned distance.
I have a 13.5 mile, half clear shot, PtP link between a pair of RB-LHG-5HP-XLs and
getting 100+ MBPS Winter and 40-80 Mbps Summer.
Throughput a moment ago was ~40 Mpbs.

mode guard #  rate  [name   idx airtime  max_tp]  [avg(tp)
HT20  LGI   2  A      MCS14   16      82    85.4      85.4

I hope this helps,
Chuck
 

Image Attachments: 
km4eug
If i am needing a strong thru
If i am needing a strong thru put the native firmware would be faster? 
K5DLQ
K5DLQ's picture
yes because AP mode is
yes because AP mode is usually going to perform better than adhoc mode.
AE6XE
AE6XE's picture
Note that AREDN could be
Note that AREDN could be configured to do the same bit rates as the full 802.11n spec supports.   This means using higher bandwidth options than 20 MHz, and stretching the same power over more freq space.  The individual carrier waves in OFDM, then have less SNR, and thus the distance a link can go is less.   There hasn't been a compelling reason to add this option in the UI so far, as the thinking is a 40 MHz channel wouldn't be used.   But something to consider.

while AP mode is more efficient to handle many clients,  for a P2P link there isn't the contention on the channel where this becomes an issue of significance.   The key for AREDN is to tune the distance setting which can make a major difference in through put.  I found this to come close to out of box firmware.   You can do a real live test switching out the firmware at the sites to measure.    I did that once with AirOS on a 40 mile link.

Joe AE6XE
k1ky
k1ky's picture
Still interested in 15/7.5 MHz channel possibilities
I am still kicking around the idea of possibilities and advantages of 15 and 7.5 MHz bandwidth for AREDN nodes.  5MHz is basically useless for "most" or our purposes.  If we had something between 10 and 20, we could squeeze some more throughput while saving a little bandwidth and staying out of the 20MHz Wi-Fi visibility widow.
nc8q
nc8q's picture
staying out of the 20MHz Wi-Fi visibility widow.

Hi, Tom:

If other Wi-Fi devices can 'see' you, they might automatically choose a different 20 MHz BW channel.
If they cannot 'see' you, the part 15 devices may think tht the channel is clear when actually you are sharing the channel at 10 MHz BW.
:-|

Chuck

 

kj6dzb
kj6dzb's picture
Loaded question! 
Loaded question! 
 
All wifi radios adjust the modulation rate based on the snr. A link is not granted to have an asymmetrical data rate or enough signal marjon to support the highest modulation rate. Factors like site noise, and not  enough gain play a big factor in a link thats not asymmetrical. The radios automatically adjust for the best data rate without user intervention* based on the snr. The data rate might not be the same in both directions!  With ubiquity's stock fw a user can monitor the modulation rate, lock the radios to a modulation rate to prevent the link on one end from ramping up and down the data modulation rate. AREDN's fw doesn't allow the modulation rate to be fixed. The biggest factor in having enough signal over the noise to support the highest data rate. The radio's transmit power (dbm) varies by manufacturer based on the proprietary rf design. Channel bandwidth (5/10/20mhz) will affect the dbm output. Ubiquity releases a table regarding modulation rates and TX dbm output in the tech sheet but Ive never seen any info of the same type for mikrotik. Selecting the right type of node/ antenna is of most importance!!!!! Antennas don't have a linear response across the whole band 2/3/5ghz, so expect the antennas to have a sweet spot that may differ between the horizontal and vertical polarization. Using nanostations vs  400iso dishes or vs a 30dbi dish for the ptp link will make a major difference for SNR. Using https://link.ui.com/# will help you ESTIMATE!!! The link vectors performance regarding data throughput and path loss for a ptp link or ptmp link. It's worth it too run a few different scenarios with different antennas. I would suggest going big! The environmental noise is not predictable, and you might find out as I did.... that the dish at one site has a lot more background noise than the other, but I was locked into an iso 400 dish. The link's vector could suffer from atmospheric fluctuation or inversion layer scatter. The path loss varys and antenna gain and signal directivity can help but not certainly not overcome those factors. One can always lower the TX power, and Ubiquiti's AC gen2 and AirFiber will allow users to set automatic power reduction preamiters. (not the AREDN FW)
 
With that said... don't expect 300Mbps with the AREDN FW. Dont expect 300Mbps with the stock FW. There is a lot of overhead!  Ive seen the TxMbps as high as 120Mbps (thanks to the Dev Team and or the open source driver) for the improvement from 72Mbps. With the best link I have between myself and another it's a 1.8 miles link on 5ghz 100% 100% 117.0Mbps I get 17-25Mbps of REAL throughput between your sites on a speed test. I think this is the hw topping out! I have a few unrestricted tunnels that run over fiber and I see similar figures. (I would love to hear what others see!!!)  
 
Ive crashed the open source driver used in OpenWRT(AREDN) trying to send video at data rates higher than 25Mbps! (another story) So if you're trying / need the maximum possible throughput between sites, I would suggest using AIRMAX, AIRFIBER, AC gen2 or mikrotik radios with the stock manufacturers FW, and matching antennas. The performance advantage of the proprietary fw and driver will outperform the open source 802.11N driver. Before you add in environmental factors.
 
Using Stock radios does not exclude the use of AREDN FW! Vlans more specifically VLAN2 (DTD) can be passed over a ptp link with the use of a managed switch and a little black magic, you can DTD link AREDN nodes over a high bandwidth link provided by equipment that doesn't run AREDN  FW.   
 
 
73 Mathison KJ6DZB
nc8q
nc8q's picture
best data rate without user intervention* based on the snr.
+1 with Mathison,
except, with AREDN firmware...
I think the Modulation Coding Scheme (MCS) and guard interval (GI) is chosen based on maximum throughput.
73, Chuck

 
AE6XE
AE6XE's picture
Please refer to these prior
Please refer to these prior posts for more details on rate selection. https://www.arednmesh.org/content/how-does-aredn-firmware-select-rf-link... Since link rate is auto determined based on the maximum rate the enviornment supports, locking to a given rate would only yield lower performance. On 5, 10, and 20MHz channel widths AREDN will choose the highest MCS15 rate the 802.11n specification defines, same as all vendors, if supported by the enviornment. Google these rate tables to see, but you must devide the rate in 2 to cut the channel width in half. The rate tables are for 20MHz channel width. This is true for all vendors. Note, for 802.11ac devices, there are higher rate options in the specification, if both devices on each end support this specification. The difference in performance with AREDN and, eg ubiqiti, is the difference in CSMA with RTS/CTS and AirOs using TDMA. TDMA handles better large count of clients. But with P2P links is not really any difference, with limited contention of the channel. The key is tuning the distance setting in AREDN. There is a difference in link rates with 40+ MHz channel widths, that are not options today in AREDN. Yes, higher link rates are 2x rates achieved by doubling the channel width. In the prior posts, there is a way to see the AREDN rate tables in real time. Note that LGI and SGI are options that can be selected. These tables and linux commands will only show information of a 20MHz channel width. Linux has no idea when the channel width is changed. You must divide by 2 when cutting the channel width in half. What happens is a setting is loaded directly to the chip that changes timing to achieve the channel width, and linix doesnt know. Also the mesh status TxMbps is not the link rate. Rather it is the link rate minus the % of packet data lost and had to be retransmitted. Joe AE6XE
AE6XE
AE6XE's picture
Also this link:

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer