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.
You are here
nanostation vs rocket and v3.16.1.0b02
Mon, 04/25/2016 - 22:51
#1
KE2N
nanostation vs rocket and v3.16.1.0b02
Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer
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.
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) ?
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
here is what the client looks like (not the same run)
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 ...
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
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.
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
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.
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.
Joe AE6XE
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
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.