From:
http://Broadband-hamnet.org
Name will change to Broadband-Hamnet™
Written by Rick Kirchhof, NG5V
Wednesday, 27 March 2013 22:46
A firmware release is scheduled in the 2nd quarter. Some major changes will be included. The list below gives a bit of detail but some changes are already in place. For example Broadband-hamnet.org or Broadbandhamnet.org already bring up this site. HSMM-MESH.org will
still work but the site will now answer to both. Other things to expect are:
SSID changes to Broadband-HamnetV1
Upgrade ALL is necessary as SSID and the actual format of data flowing will be changing.
SSID minor level (V1) will roll when succeeding firmware requires another upgrade all.
Interoperability with Ubiquiti hand loaded systems (simple web page config for Ubiquiti comes later)
DNS changes from the Austin.TX.mesh style to local.mesh
More FAQs to be written, better documentation on the way
YouTube videos becoming more popular, see "videos" in left menu or search YouTube.
More mesh elmers have joined, more are needed.
Over 1200 registered users on the forums, rising by nearly 100/month.
Web site hits growing at an increasing pace, Google hits for hsmm mesh search terms growing.
QST article in July with more to follow.
Watch here or in the developers newsgroup for updates.
73,
Rick, NG5V
Here are some excellent starter videos from Kevin, N7RXE:
--
Dave AD5OO has officially released the 1.0.0 Broadband-Hamnet firmware. (8/2013)
This new firmware is NOT backward compatible and has some significant changes upon install by default. Any nodes flashed with this new 1.0.0 will NOT talk in any way shape or form with 0.4.3 (or older) firmware. Its All or Nuthin.
The major change you will notice is that instead of the LAN being in NAT mode, it is now in 5-host DIRECT mode (formerly called DMZ). NAT mode is still available for those who wish to switch back, but give Direct Mode a try, as it makes devices/servers easier to put out onto the mesh.
Also, this firmware now allows those who hand-craft firmware onto other manufacturers' hardware to be able to mesh back with the WRTs we have all come to know and love.
You can read the change log on the site (below the WISH LIST, dont get those confused like I just did myself...), and get the new firmware from the software download page.
OR, if your node(s) have internet access, you can go to the Setup-Administration page, click REFRESH next to the Firmware Download section, then use the pull-down to pick the 1.0.0 TRX file.
IF you have mesh nodes already at 0.4.3, you can just choose the generic TRX file without needing to use the hardware-specific BIN files.
But remember, this is a FULL flash: You WILL need to setup as if from scratch (set the nodename and new passwords) once you flash. If you have any services running on a node, backup in some way any customized settings before flashing (dummy me lost a custom script I wrote on one node because I forgot to copy it off the node to somewhere else before I flashed it---LEARN FROM MY MISTAKE!BACKUP BACKUP BACKUP)
I HIGHLY suggest you read the documentation again to refresh your memory, and if you have any questions, the Documentation on the site, Help files, and forums are a great place to start.
Happy Meshing!
Jim
K5KTF
Webmaster & Mesh Geek
Broadband-Hamnet.com
Here are some screen shots from the web GUI to show the features of the Broadband HamNet firmware (BBHN).
-
The purpose of what follows is 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):
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.
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
(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
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):
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
(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]
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
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. This will help eliminate the throughput problem that occurs with half duplex radio links.
Suggested reading:
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.
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 Quality):
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.
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 was told 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.
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.
