Hey all,
Please point me in the right direction... first let me say that I'm NOT an IT guy!
I've taken the challenge to move our 220 repeaters over to Mw backhaul. Currently we have 4 sites that talk through a uhf hub. The goal is to have ptp from each site back to our hub site where we will have an internet connection. Internet is needed due to our linking to other 220 Allstar repeaters. Unfortunately, we can't use the "hub and spoke" with 5ghz due to locations. We can however "chain" a few and bring in to hub site that way. The primary goal is building a private rf network for backhaul and later some IP cams. Using ubiquiti nodes ive got my test setup working great with them as a bridge. I did want to use the 5g as Aredn but cant figure out how to set it up so our traffic passes as a large network (all 192.168.1.x/24) AND have Aredn available for others to use and (example) view live cams. Any help? Be gentle!
Thanks....de kg4fjc
Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer
Is this for Virginia? It sounds like we need to sit around a map and look at this. I'm not the best networking guy, but I know a few networking dudes.
-Damon K9CQB
As much as I appreciate AREDN mesh, I would suggest that a mesh is not the best solution for a chain of nodes linking repeater audio. As the number of "hops" increases the amount of variable latency increases quickly and you will start to get stuttering and drop outs in the audio. And, if someone decides to do an "iperf" test on the system things will really bog down. Same is true if someone is trying to stream a high resolution video link.
The AREDN net work is always a 10.x.x.x/8 configuration. If you need other numbering you need to provide routers to accommodate that.
I would suggest using the OEM "transparent bridge" network mode and WDS wireless mode. This has the absolute minimum overhead/latency when doing multi-hop links and you can keep whatever network numbering you want.
An example of a repeater linking network can be found in this presentation (this is a download link) :
http://www.w3nd.org/wp-content/uploads/2014/09/Central-PA-IP-Network-Powerpoint-revised-08052014.pptx
You can contact Gary for more information (as shown in the pptx).
You could provide access points ("off ramps") on such a network for AREDN nodes and, if done properly, you can limit the load imposed on the network by the mesh traffic.
The main disadvantage of using OEM is that the ham-only frequencies are not available. On the other hand, if the nodes are identified with call signs, you will be able to use higher EIRP levels than are permitted in part-15 operation. (You need to turn off encryption, of course).
-Damon K9CQB
Is this a general fact? Can this be quantized? If true, this needs to be made more widely known.
Bob W8ERD
Another observation I have is that many AREDN implementers shoot for LQ/NLQ of something like 80% and call it day. If you are going to support isochronous traffic, you need 100%.
Andre, K6AH
I find lower latency on 100% LQ/NLQ RF links and DtD links than I do on tunnels.
Retries do not seem to matter. Let the wireless driver choose the modulation coding scheme for best though-put.
I find greatest latency on tunnels (residential ISP service<>internet<>residential ISP service).
$0.02
Chuck
I think you mean quantified. I expect a proper analysis of a mesh network is something that graduate students work on to get their degrees.
But I would propose a simple rule of thumb where you take the LQ's in one direction and the NLQ's in the other direction and just multiply them together (where 90%=0.9 for example).
so taking a a 3-hop path - if all the LQ's are 100% you get 1.0*1.0*1.0 = 1.0 or 100% - this is Andre's ideal system and will work well for everything out to many hops.
if the LQ's are 85% you get 0.85*0.85*0.85 = 0.614 or 61% (marginal for VOIP)
If the LQ's are 70% for each link you get 0.7*0.7*0.7 = 0.343 0r 34% (ok for file transfer, but not good enough for VOIP)
(in general the LQ's will not be equal, just chosen here for simplicity)
This rapid fall off with more hops I think is probably realistic and shows how link quality becomes really important as you get more hops.
It also shows why OLSR will try mightily to do it in two hops of three even if it has to slow down to 1 Mb.
Ken
.
Bob W8ERD
Q: can I be sure that is actually the route used by mesh?
A: unless you truly have singular PTP connections (like long-haul PTP and some of the spoke/hub implementations etc), in a true mesh (with multiple possibilities for path) the path is continually and dynamically determined by what the mesh sees as the current conditions for each choice based on then-calculated "cost" (which can change at anytime).
For monitoring changing paths over time for latency and packet loss, I use a windoze-based program called PingPlotter - which still has a free edition available at: http://www.pingplotter.com/products/free.html - I highly recommend it. There is also a free-trial of the more fully-featured paid version available.
Of course, this only works from the end-point where the windoze box is located. However, you might be able to locate a windoze box at another location on the mesh, and use remote desktop/xrdp to run it from there (works well for me).
- Don - AA7AU
VOIP and video will drop out as packets are lost during route table changes--takes time for all nodes on the network to be updated with changing route info. Some applications may drop connection and exit.
Rule of thumb, engineer so route changes are not occurring on fixed location networks. This means if there are 2 paths from A to B, if the OLSR ETX value is close on both paths, need to do something to get the ETX values far enough apart, so the route only changes when one path is actually down or severely degraded from normal.
Joe AE6XE
Orv W6BI
Bob W8ERD
Bob W8ERD
Just a observation - we have a weekly Teamtalk net on the ham network, using both voice and video. Some of our participants are a hundred miles away over a half dozen hops. Admittedly they're pretty high-quality hops, and half of them are Part 15 links but we rarely hear voice dropouts and while video artifacts are more common, they're not frequent, even with a half-dozen (low-res) video streams going.
My two cents.
Orv W6BI
I think that all it takes is a weak link somewhere on the mesh to cause problems. Since every ham is a DX-er at heart you are always subject to some one connecting who can just barely make the link and while we don't want to discourage that guy ... he does cause problems.
On the other hand, if *every* link on your mesh is high quality (very few retries) it makes a big difference in performance. Still, in any side-by-side comparison, the dedicated AP/station mode of operation (especially with some low-overhead protocol) is going to outperform a mesh.
Audio has the advantage that you can make a big jitter buffer to iron out a lot of the latency - as opposed to video. Of course, with a big jitter buffer you may get an objectionable lag in the T/R response time.
So I were designing a system specifically to link repeater audio channels (by audio it could be DSTAR, DMR, or whatever) I would still lean toward the non-mesh configuration.
Ken
Mixing AirOS part 15 links with AREDN links is done and can be done. However, anyone considering this design, means more complexity, consequently a higher level of IT skillset is needed to sustain.
Joe AE6XE
I agree with Ken's comments and analysis on the topic. There are times that a dedicated, non-meshing, link is appropriate when you need more control of the routing and prioritization of traffic.
That said, I'm interested in how we can plan for those "off-ramp" connections to hang mesh infrastructure from a Part 15 microwave link. Do we have to create a tunnel server on one end and client on the other, using the Part 15 "backbone" as the WAN connection? The manufacturer firmware gives us the ability to trunk VLANs over the air, but our AREDN developers have recommended NOT to use microwave to extend a DtD connection utilizing VLAN2 noting latency intolerance in the DtD protocol.
@W6BI, what approach are you all in SoCal taking to work Part 15 links into your mesh? Anyone else have experience with this?
With auto-distance on an AREDN 40 mi 5GHZ link, my testing suggests this is providing equivalent thoughput as AirOS TDMA. Although I need to do the direct auto-distance-aredn with AirOS TDMA and get more numbers to have confidence. Prior testing showed that static-distance-aredn was ~70% throughput of AirOS TDMA. All things were equal, with back-2-back swapping of firmware. Then I compared static-distance-aredn with auto-distance-aredn and found a comparable improvement that suggests auto-distance-aredn is ~= AirOS TDMA or comparable throughput and latency.
How the route tables are configured (aredn is mesh at the IP routing level) isn't going to impact the end to end performance. This is at layer 3. Well, if it is miss configured or flapping it won't work at all. The RF channel throughput and latency is directly dependent on layer 2 and layer 1 protocols. We are comparing 802.11n with CDMA-RTS/CTS in AREDN and 802.11n with TDMA in AirOS. If we are comparing these in P2P back-hall scenarios, the above data says they are directly competitive with each other.
As an example, here is 100+ mile 6 RF hop link through multiple long haul links with AREDN. To get a visual, this is from my QTH in Mission Viejo Orange County, to Redlands San Bernardino County, to Elsinore Peak in Riverside County. Average ping in this sample was 23.197 ms. VOIP crystal clear.
The primary consideration is to have quality links, which means avoiding channel contention or interference. There's increased chance of interference if not using part 97 only channels, particularly in metropolitan areas.
AE6XE
+1
"The RF channel throughput and latency is directly dependent on layer 2 and layer 1 protocols."
IMHO, that should be a 'sticky' note in bold font and large point.
The layer 3 cannot function without a well performing layer 2 and layer 1.
IOW, degradation of the radio signals degrades OLSR.
Channel contention, hidden nodes, and exposed nodes degrade (destroy) OLSR.
OLSR does not 'fix' poor radio circuits, nor poor network planning.
$0.02
Chuck
OLSR is a broadcast -- to all neighbors. As such goes out at lowest common rate (3Mbps @ 10Mhz channel on 3/5 Ghz). Thus, OLSR does not use RTS/CTS, and some transmitted frames are lost or collide with other nodes trying to transmit at the same time on a busy channel.
The same busy channel, when a node is sending VOIP or video will be using RTS/CTS and preserve a time slot (similar to what TDMA protocol is doing), to ensure the channel is clear sending the data. VOIP or video then ends up with 100% success (barring interference beyond neighbor nodes).
Thus, while LQ/NLQ can be <100%, the voip/video can be 100% due to RTS/CTS usage when there are lots of active neighbors (multipoint) on the channel.
One can see and test this by doing a tcpdump capture of the RF channel, and viewing the RTS/CTS packets and video frame sequences.
I'd clarify, that OLSR works well, with the caveat the inherent weakness is the LQ/NLQ and ETX values go down when the link is busy. This is not really representative of the link quality, just because it suddenly got busy.
On my backlog list is to look at an OLSR plugin that reads the ath9k wireless driver data -- to get a much better picture of the RF link quality. No need to send hello broadcast packets, just pull the statistics that already exist from the wireless driver for the best characterization of the link.
Joe AE6XE