You are here

Capability of limiting bandwidth of specific resources?

4 posts / 0 new
Last post
NM7B
Capability of limiting bandwidth of specific resources?

Please feel free to move this to a more appropriate category:

I current have an AREDN mesh with four roof-mounted nodes, one with a Raspberry Pi-based MeshChat server.   I am also building out VoIP telephones at each of our fixed EOC's.

Something I noticed during our last SET is that when a file download is in progress from the MeshChat server, the file download consumes all of the data bandwidth, leaving so little bandwidth that simultaneous attempts to exchange chat messages get blocked out.   This morning I tried a similar test where I placed a voice VoIP telephone call, and monitored that call quality while trying to do a file download from the MeshChat server.  

The audio VoIP call suffered regular drop outs while the file download was in progress.   Once I terminated the download, the voice VoIP call returned to full throughput.

Is there a method (or perhaps this is a suggestion/request for a method) to limit the percentage of bandwidth that a resource may consume, to ensure that other link users aren't squeezed out? I think this is commonly referred to as a QoS (quality of service) setting.  

Thank you, and 73's,
Collier
NM7B
 

AE6XE
AE6XE's picture
QOS
Yes, a Quality of Service capability is needed.   The mesh nodes don't yet have this ability.    Some of the factors that contribute to voip breakups go beyond QOS, so for now, we want to make sure these other factors aren't contributing, things we can do today.   Congestion on the channel is a big one, weak links and over demand,  different cell coverage areas interacting, etc.

Joe AE6XE
NM7B
Thanks for the verification and clarification, Joe!

I have seen what was a measured 15 Mbps throughput when I just had two nodes drop down to 5 Mbps now that I have multiple nodes--all on the same channel.  So your suggestions on what other contributing factors degrade bandwidth are quite plausible.  

I have been brainstorming on how to reconfigure our mesh to eliminate collisions/contention by putting the backbone segments on different 3 GHz frequencies and the "last mile", as needed, are on alternate 3 GHz frequencies at low power, or on 2.4 GHz, all without breaking the bank.    

73's
Collier
NM7B

AE6XE
AE6XE's picture
successive links contending

successive links contending for the channel?

The biggest gain can be made if successive links each have isolated channels.   

Consider the traffic pattern of 4 nodes:   A -> B -> C -> D from ipCam to the laptop viewing the video.  

In the ideal case, every link is on a different channel,  there are no delays or coordination between links, and every link is transmitting 100% of the time (ignoring other clients and data on the links).   

In the worse case, if all links are on the same channel, then generally only 1 link can transmit data at a time and every link is contenting for the same channel. With hidden or exposed nodes, RTS/CTS mitigates the shared use, but still voip quality is poor to unusable in this scenario -- regardless of QOS capability or not.

Joe AE6XE

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer