{Draft}
The purpose of this document is to show (with many screen shots) the features of the Broadband HamNet firmware (BBHN). It is also to show network throughput speeds in a direct verses indirect scenario. There are concerns about significant bandwidth preference hits in a mesh network, when you have to hop though a couple nodes to get where you are trying to go.
----
The simulation will use three mesh nodes. Where "A' has a HTTP server attached to it, and "C" is the client trying to reach "A". All are spare WRT54 series Linksys units that were floating around. The output power was adjusted to 1 dBm and TX and RX antenna were set the same on the basic configuration page. The use of dummy loads, and a little physical distance will then help simulate a situation where nodes "A" and "C" cannot reach each other directly. This is where we will introduce node "B".
The HTTP server is a Raspberry Pi B+, running apache. It is connected to Node "A" via the LAN port of the WRT54G.
The client computer is an old Sony PIII, laptop running XP. It has a Windows version of Wget installed to retrieve the file from the Raspberry Pi Webserver since it has a convenient throughput output. The laptop is connected to the LAN port of node "C".
MB/s = MegaBytes per second
KB/s = KiloBytes per second
First some baselines for comparison:
Wired Direct:
C:\Program Files\GnuWin32\bin>tracert 10.25.39.60
Tracing route to 10.25.39.60 over a maximum of 30 hops
1 1 ms <1 ms 1 ms localnode.local.mesh [10.195.3.201]
2 3 ms 2 ms 2 ms 10.25.39.60
Trace complete.
C:\Program Files\GnuWin32\bin>wget 10.25.39.60/file.tar.gz
--2014-10-17 03:38:07-- http://10.25.39.60/file.tar.gz
Connecting to 10.25.39.60:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 34764375 (33M) [application/x-gzip]
Saving to: `file.tar.gz'
100%[======================================>] 34,764,375 7.89M/s in 4.2s
2014-10-17 03:38:11 (7.91 MB/s) - `file.tar.gz' saved [34764375/34764375]
With DD-WRT, standard Wireless AP/Client configuration
DD-WRT AP has the Pi at 192.168.1.122
Client:
C:\Documents and Settings\Owner>tracert 192.168.1.122
Tracing route to raspberrypi [192.168.1.122] over a maximum of 30 hops:
1 20 ms 1 ms 1 ms raspberrypi [192.168.1.122]
Trace complete.
C:\Documents and Settings\Owner>
C:\Program Files\GnuWin32\bin>wget http://192.168.1.122/file.tar.gz
--2014-10-18 22:23:42-- http://192.168.1.122/file.tar.gz
Connecting to 192.168.1.122:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 34764375 (33M) [application/x-gzip]
Saving to: `file.tar.gz'
100%[======================================>] 34,764,375 2.80M/s in 12s
2014-10-18 22:23:54 (2.79 MB/s) - `file.tar.gz' saved [34764375/34764375]
Using BBHN, direct, from node C to A (100 % Link Quality):
C:\Program Files\GnuWin32\bin>tracert 10.25.39.60
Tracing route to 10.25.39.60 over a maximum of 30 hops
1 1 ms <1 ms 1 ms localnode.local.mesh [10.195.3.201]
2 3 ms 1 ms 3 ms kb9mwr-A.local.mesh [10.99.36.231]
3 3 ms 2 ms 2 ms 10.25.39.60
Trace complete.
C:\Program Files\GnuWin32\bin>wget 10.25.39.60/file.tar.gz
Connecting to 10.25.39.60:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 34764375 (33M) [application/x-gzip]
Saving to: `file.tar.gz'
100%[======================================>] 34,764,375 1.90M/s in 17s
2014-10-17 02:58:02 (1.06 MB/s) - `file.tar.gz' saved [34764375/34764375] (1900
KB/s)
Using BBHN, direct, from node C to A (16 % Link Quality) :
C:\Program Files\GnuWin32\bin>wget 10.25.39.60/file.tar.gz
Connecting to 10.25.39.60:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 34764375 (33M) [application/x-gzip]
Saving to: `file.tar.gz'
100%[======================================>] 34,764,375 1.11M/s in 31s
2014-10-17 02:58:02 (1.06 MB/s) - `file.tar.gz' saved [34764375/34764375]
BBHN indirect, through B (100 % Link Quailty):
C:\Program Files\GnuWin32\bin>tracert 10.25.39.60
Tracing route to 10.25.39.60 over a maximum of 30 hops
1 <1 ms 1 ms <1 ms localnode.local.mesh [10.195.3.201]
2 2 ms 2 ms 2 ms kb9mwr-B.local.mesh [10.27.93.182]
3 6 ms 6 ms 6 ms kb9mwr-A.local.mesh [10.99.36.231]
4 6 ms 6 ms 7 ms 10.25.39.60
Trace complete.
C:\Program Files\GnuWin32\bin>wget 10.25.39.60/file.tar.gz
--2014-10-18 17:49:18-- http://10.25.39.60/file.tar.gz
Connecting to 10.25.39.60:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 34764375 (33M) [application/x-gzip]
Saving to: `file.tar.gz'
100%[======================================>] 34,764,375 279K/s in 1m 43s
2014-10-18 17:51:02 (329 KB/s) - `file.tar.gz' saved [34764375/34764375]
82.68 % slower throughput, compared to the direct A to C connection!
Summary:
The automatic routing that a Mesh network provides is very handy for issues; of interference between nodes, fading and other temporary obstructions that crop up in the path. It is beneficial because the connection can continue, instead of dropping out completely. It also simplifies configuration, which is a real benefit for end users or quick deployments, where the users might not be familiar with the network topology.
However, as you can see, there really isn't a replacement for good network
planning. Hops should always try and be minimized in the network
design. Dedicated back bone channels should exist between high profile
user end access points, to essentially provide a full duplex radio link back to
help eliminate the throughput problem.
http://liveqos.com/wp-content/uploads/2012/12/Why-Your-WiFi-Doesnt-Deliver.pdf
http://www.strixsystems.com/products/datasheets/strixwhitepaper_multihop.pdf
http://www.ultra-3eti.com/assets/1/7/MeshNetworkingSystemTopologies.pdf
http://wiki.villagetelco.org/Testing_Data_Transfer_Rates_on_a_Mesh
Now using Ubiquiti gear:
With Nano M2 to M2 using UBNT firmware one as AP the other as station, standard 20 MHz channel:
C:\Program Files\GnuWin32\bin>tracert 192.168.1.200
Tracing route to 192.168.1.200 over a maximum of 30 hops
1 3 ms 1 ms 1 ms 192.168.1.200
Trace complete.
C:\Program Files\GnuWin32\bin>wget http://192.168.1.200/file.tar.gz
--2014-11-04 15:17:24-- http://192.168.1.200/file.tar.gz
Connecting to 192.168.1.200:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 34764375 (33M) [application/x-gzip]
Saving to: `file.tar.gz'
100%[======================================>] 34,764,375 3.50M/s in 9.5s
2014-11-04 15:17:34 (3.48 MB/s) - `file.tar.gz' saved [34764375/34764375] (3500
KB/s)
BBHN indirect using Ubiquiti gear, through B (100 % Link Quailty): C:\Program Files\GnuWin32\bin>tracert 10.80.117.246 Tracing route to 10.80.117.246 over a maximum of 30 hops 1 <1 ms 1 ms <1 ms kb9mwr-c [10.98.20.137] 2 4 ms 4 ms 3 ms kb9mwr-b.local.mesh [10.230.178.251] 3 7 ms 8 ms 7 ms kb9mwr-a.local.mesh [10.10.14.190] 4 6 ms 8 ms 5 ms 10.80.117.246 Trace complete. C:\Program Files\GnuWin32\bin>wget http://10.80.117.246/file.tar.gz --2014-11-04 17:10:18-- http://10.80.117.246/file.tar.gz Connecting to 10.80.117.246:80... connected. HTTP request sent, awaiting response... 200 OK Length: 34764375 (33M) [application/x-gzip] Saving to: `file.tar.gz' 100%[======================================>] 34,764,375 965K/s in 36s 2014-11-04 17:10:53 (955 KB/s) - `file.tar.gz' saved [34764375/34764375] 72.71 % slower throughput, compared to the direct A to C connection!
Note that there is about a 10 % improved throughput using the Ubiquiti gear over the Linksys!
A large part of the throughput hit is related to the fact that collisions are
likely going on, as the relay node is transmitting, the server is likely sending
its next frame, for
example.
I read that 802.11n capable chipsets (like the Ubiquiti M2 line), there are
enhancements related to the RTS/CTS mechanism to help with this. And
apparently this is so after performing these tests.
P.S. I should have verified the RF link speeds by SSHing into the node and issuing the iwinfo command.
Perhaps I'll redo the test later down the road, or maybe this post will inspire someone else do further throughput testing.
A large part of the significant slow down (50-60%) between the direct and the second is because the channel becomes a half duplex link that has to repeat the content (same as 1200 baud through a digipeater) but would expect it to taper off the more hopes you get as you get to a point where one set of nodes is receiving while another is transmitting.