You are here

nanostation vs rocket and v3.16.1.0b02

15 posts / 0 new
Last post
KE2N
KE2N's picture
nanostation vs rocket and v3.16.1.0b02

I was doing some throughput benchmarking here and have found that, while beta02 now shows the full speed of the unit (almost 65 TxMbps for 10 MHz and 130 TxMbps for 20 MHz), the throughput I am seeing for the NS-M3 is pretty low (two nodes in mesh configuration).

For example, with the M2's running at 10 MHz I get 18 Mpbs on speedtest.net (with 5 km distance setting).

But with the NS-M3 set at 20 MHz (and reporting 129.7 Mbps) the most I get is about 9 Mbps throughput (upload from the PC to the WAN through the two nodes, download is slightly slower).  I verified that the actual bandwidth is in fact 20 MHz. Distance setting is 3 or 5 km.  I am puzzled as to why it is so slow. I backdated the firmware to beta01 and got the same throughput results.

Does anyone else have experience with NS-M3 and AREDN firmware?


PS - as an aside: I tried switching to access point / client mode and beta02 would not save the settings for the client.  It said that there was an invalid wifi channel (or frequency) which is nonsensical since you do not set the frequency for the client, only the access point.

 

K5DLQ
K5DLQ's picture
i would think a more accurate

i would think a more accurate test would be to load http://www.speedtest.net/mini.php on a PI/linux box on the mesh and eliminate the WAN egress.

EDITED: edited link.

KE2N
KE2N's picture
VIRUS

Daryl - Norton got pretty excited when I clicked on that link. I don't think I will do that again.

We can eliminate both the WAN and LAN interface by running "iperf" which comes-with the AREDN packages.  I have been wanting to run that anyway.  The problem is it always results in "connect failed: Connection refused" 

One reason for this message is that a firewall is blocking the program in one direction, or the other.  (I can run both client and server OK within the same node).

>> Do I have to do something (on the server side I suppose) to allow the client program to come in and access the server (default TCP port is 5001) ?

 

K5DLQ
K5DLQ's picture
my bad.  i just updated the
my bad.  i just updated the post with the proper link.
KE2N
KE2N's picture
answering my own question

This was simple:  in  /etc/config.mesh/firewall  
add this

# iperf
config rule
       option src                 wifi
       option dest_port        5001
       option proto              tcp
       option target             ACCEPT

Then restart the node. Run the server on one node and the client on the other node
here is the server output

root@KE2N-AR-1:~# iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local 10.51.250.25 port 5001 connected with 10.78.178.163 port 35489
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.4 sec  3.25 MBytes  2.61 Mbits/sec

here is what the client looks like (not the same run)

root@KE2N-AG1:~# iperf -c 10.51.250.25 -p 5001
------------------------------------------------------------
Client connecting to 10.51.250.25, TCP port 5001
TCP window size: 21.0 KByte (default)
------------------------------------------------------------
[  3] local 10.78.178.163 port 35661 connected with 10.51.250.25 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.9 sec  2.00 MBytes  1.54 Mbits/sec


EDIT: changed the src option to "wifi" - although it did work with wan.
In using iperf I think you are supposed to use WiFi address although it works with the LAN address. 
We have one node on our mesh that simply refuses to accept iperf connections even with this mod though ...

k1ky
k1ky's picture
Another point of interest
Another point of interest (to me anyway) would be what throughput you get with some file transfers over the MESH.  One test would be to set up a WINLINK POST OFFICE on one end and send a large 2-5MB Compressed Picture File using RMS Express on the other end.  Another test would be some other "direct" file transfer using FTP or Teamviewer in Peer to Peer mode.  WINLINK Peer to Peer would be another test.  We have file transfer rate calculations built into RMS Express.
 
AE6XE
AE6XE's picture
KE2N, 
KE2N, 

I have a NSM3 as the primary link from my QTH and ~5 miles to a Rocket M3 with 120deg sector.     It has been a while since I tested 20Mhz channel, but when I did, the 10Mhz channel showed higher throughput (with iperf direct between nodes).   I saw similar results on 5Ghz.

How comparable is the throughput for same channel widths between 2Ghz and 3Ghz in your test setup?  This is a mystery to explain...

Joe AE6XE
KE2N
KE2N's picture
2 and 3 GHz

I did a couple of runs at 10 MHz BW using the NS-M3 and the results were quite similar to the 20 MHz BW. This throughput is half what the M2 units are producing at 10 MHz BW. Given that there are no interfering signals, this I think clearly indicates something is wrong with the NS-M3. Hence my original posting.

kg9dw
kg9dw's picture
Three thoughts...
Three thoughts...

1. Distance parameter is set right?
2. Do you have them TOO close? I get whacky results when I have three nodes in the lab located within 100 ft of each other. Do you get the same results if you put the nodes 1 mile apart?
3. Does the throughput decrease over time? If you transmit a 10 MB file do you get the same throughput as you do when you transmit a 30 MB file?

MB
K5DLQ
K5DLQ's picture
also, did you use AirView
also, did you use AirView (AirOS) to look at the RF spectrum in the area?
KE2N
KE2N's picture
airview

Yes - the area around 3420 MHz where I am testing is clear of interference. Once thing I do need to check is that this frequency does not correspond to some  5 GHz node that I have locally - I have forgotten the conversion constant for 3 GHz ..

second question:
I was deliberately varying the distance parameter to see the effect on throughput.. but at 3 or 5 km I expect it to be about as high as it can go.

kg9dw
kg9dw's picture
I'd try item 3 I suggested
I'd try item 3 I suggested above. See if your performance changes over time by varying the file sizes. 
AE6XE
AE6XE's picture
KE2N,  I'm trying to

KE2N,  I'm trying to determine if there are 2 mysteries or 1:

1)  The M3 is all-around slower (about half throughput) than the M2 (for both 10 & 20Mhz channel widths?)
2)  The 20Mhz channel throughput is not 2x the 10Mhz channel throughput for the M3 (and M2?)  when SNR is sufficient

What throughput do you see for M2 @ 20Mhz?    ~18Mbps or much higher?      Don't want to jump to any conclusions or go on a tangent, but for example, one explanation might be that the M3 is stuck on a 5Mhz channel regardless of our settings, and we don't realize it.   Let's validate the full picture of the data to make sure we stay on the right track to get to the bottom of the issue.
 

  10Mhz 20Mhz
M2 18 ?
M3 9 9


Joe AE6XE

KE2N
KE2N's picture
NSM3

The NSM3 is not noticeably faster with 20 than with 10.  With a 10 km distance I get about 7 Mbps in both cases.
With the M2 (rocket not NS) I get 15-19 Mbps at 5km and 13-15 Mbps at 10 km with 10 MHz,  I have not tried 20 MHz on the M2 as we are on channel -2.

Attched PNG files show the spectrum.  I have two more I will upload a little later.

Speedtest.net results with the OEM firmware at 3420 MHz:  
20: 71/84 Mbps throughput
10: 35/36
 5:  20/18


 

Image Attachments: 
KE2N
KE2N's picture
two more snapshots

these are airView of the NSM3 running at 3430 MHz and 5,10, or 20 MHz bandwidth.  The file names with "oem" in them are the Ubiquiti firmware load. The ones without "oem" are the AREDN beta firmware. Each snip shows two of the standard graphs - the upper one being kind of an integration of the energy. The OEM ones are much brighter in this energy graph I assume because it is putting through a LOT more data in the same running time. Signals are quite strong here so you can see quite far down in the skirts - its probably not linear at these levels so suppression is probably better than what you see.  The discontinuties (at, for example, 3435 MHz) are artifacts of the way the Ubiquiti scan works and not something coming from the transmitter.

From this we can see that the bandwidth is changing as requested. And while we know the MESH protocol has lower throughput, you can see that the ARDEN firmware load is not just not working the transmitter very hard.

Image Attachments: 

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer