You are here

Mesh Overhead

28 posts / 0 new
Last post
w8erd
Mesh Overhead
How much mesh traffic overhead is created by the nodes just talking to one another?   
Does this increase if you have more nodes?
Is it a problem if you have lots of nodes connected?

Bob W8ERD
N8NQH
N8NQH's picture
I would like to know as well.
thanks for bringing this up.

also, if a 1080p IP cam running at a full 30fps (not that I would run a Mesh IP cam at this mega  level, just using this scenario as an example)... does this create data traffic - when  no one is currently viewing?

And if there are two viewers... does this double the grid data traffic (when compared to just one viewer)?
KG6JEI
The mesh routing overhead
The mesh routing overhead really isn't that quantifiable (strictly speaking I guess One could put together a spreadsheet to estimate all this but it would really depend) other then to say, yes the more nodes you add the more data it takes.

There are numerous factors that affect how much data the mesh routing takes, everything from number of nodes to number of advertised services to how long the URL is for the advertised service is to how many are 1 hop, 3 hop, or 255 hop neighbors as to reduce bandwidth some packets are only sent to directly attached neighbors like Hello's, other packets with node details are sent periodically to directly attached neighbors and then later on after a number of direct sends its allowed to go to the whole mesh (255 hop limit)

is is it a problem, well really depends, the data is sent at at the slowest data rate, so the max we could handle on mesh data exchange right now would be 6mbps (5.8GHz and 3.4GHz) or 1mbps (2.4 GHz and 900MHz) these numbers are reduced  for smaller bandwidths.

What I last heard I believe was the "big" mesh that many people join for testing was taking somewhere around 10-20kbps average out the wan port which seems like a good "choke" point to monitor so if that was/is the case and that mesh is much larger then most real production meshes are predicted to get for a while then I don't see it as a major concern just yet.
k1ky
k1ky's picture
MESH Routing Overhead
We are just starting to get a handle on this.  One of our system node locations that hosts 8 tunnel connections used about 285 GB of data last month out to the internet.  We are working on some internal and external monitoring devices.  Most of the traffic was just keeping up with each other!
 
KG6JEI
Being a tunnel pushes you to
Being a tunnel pushes you to me a multiplier location.

Wifi and DTDLink (the main technologies at this time recommended for production meshes) don't suffer from the need to duplicate to multiple hosts, they send it out once and are done while a tunnel has to send it out once to each tunnel client/server connected.

285,000,000,000/(30*24*60*60)/8=~14kbps across the links.
N8NQH
N8NQH's picture
at Hamvention...
Like all the regional Mesh installations...we know our local Mesh grid well; an have become acquainted & accustomed  to it's day-to-day speeds and hesitations.

When the tunnel was active during Hamvention... noticed a serious slow down initially, but then it did rebound somewhat (but never back to our "normal" operation until the tunnel was disconnected).  Granted the slow down may have not been all that dramatic; but it was a stark difference in what we were already familiar with.
AE6XE
AE6XE's picture
What OLSR folks say:   
What OLSR folks say:   

"In Spring 2007 the olsr-ng project kicked off. It quickly turned out that the issue just has been lack of efficient data structures and some implementation tricks to get serious CPU savings. Since then periodical rewrites are underway to save CPU cycles and make olsrd scale to thousands of nodes. The main goal of OLSR-NG is to make olsrd into a rock solid product and a great routing daemon with high scalability. As of this writing the high scalability aspect has been reached."

 
w6bi
w6bi's picture
About those webcams

To address one of the posts in this thread that  I didn't see answered - webcams that are not being viewed don't stream data hence don't occupy any bandwidth.
We've been doing a lot of performance testing with webcams, as we need to be able to put a webcam if necessary way out at the end of 2-3 temporary hops to address possible incidents (in our case, brushfires).
To minimize occupied bandwidth, we keep the frame rate at 5-10 fps, keep the resolution around 640x480, and very importantly, stream via RTSP rather than HTTP.  RTSP is a protocol for streaming data, which itself rides on RTP, which rides on UDP.  Those protocols don't require acknowledgements, reducing needed bandwidth.  That all allows more usable data to be pushed down a given bandwidth channel.   RTSP can be a pain to configure on a camera initially but we believe the results are worth it.

As an aside, during our testing we found VLC tends to lock up when viewing less-than-perfect slow data rate video data streams.  The app itself doesn't stop responding and it continues to process incoming frames, but it stops updating the screen window.   We've found that mplayer on both Linux and Windows is much more robust when displaying crappy intermittent webcam data.    We'd appreciate feedback from other folks to see if our observations are consistent with others.

HTH.

N8NQH
N8NQH's picture
quote: To address one of the

To address one of the posts in this thread that  I didn't see answered - webcams that are not being viewed don't stream data hence don't occupy any bandwidth.
 

Thanks !

Although it may be obvious to some, it's reassuring to hear the info given in a definitive manor.
 

To minimize occupied bandwidth, we keep the frame rate at 5-10 fps, keep the resolution around 640x480,
 

I can remember after we got our first few IP cams on the mesh grid; gleaming on the 1080 and 1200 res quality and fluidity of 30fps frame rate.  Then all of a sudden we all started thinking the same thing... "why?"  We realized we  didn't need "production quality" video on Mesh.  We haven't gone down to 640x480, but am running 720 at 5fps.  Still enjoying every minute of it.

w8erd
How to do RTSP?
What cameras support RTSP?  How does one configure the camera to do RTSP?
We have found we can do 640x480, 10 fps over 2 hops. but not 3, apparently using default HTML.
Hoping that RTSP can improve this.

Bob W8ERD
N8NQH
N8NQH's picture
bandwidth?
Bob, what Mesh  bandwidth setting were you using for your video testing ?
w8erd
mesh bandwidth setting
All our nodes are set to 5 MHz.  The link quality between the nodes is not that great and we are afraid if we go to
10 Mhz the SNR will be even less.

Bob W8ERD
N8NQH
N8NQH's picture
The link quality between the

The link quality between the nodes is not that great and we are afraid if we go to
10 Mhz the SNR will be even less.



 sometimes you gotta do what you gotta do. :)

Keep in mind though that a center node (feeding one on each end; where the end nodes can't see each other directly) has to operate at almost double-duty to keep the ones on the ends current with each others activity.  And if the data rate is already restricted... it could cause issues.  You may not notice it though in most applications... EXCEPT in live video (where is is so easy to see lag, freezing, dropped frames). Each "hop" loses some overhead.

If you can get solid 15db ratios at 10 mhz, I would add that configuration to the testing scenarios you are performing.
S/N numbers sure are helpful to  determine a mesh links health and endurance;  but aren't the end-all decision maker either.
 

going from
20 to 10mhz will show a S/N ratio improvement.
moving again from 10 to 5mhz bandwidth will show another S/N gain.
and then going from 5 to 2.5 mhz bandwidth (lets pretend the software is capable of this) will show another S/N gain
 
and then going from 2.5  to 1.25 mhz bandwidth (lets pretend the software is capable of this selection ) will show yet another S/N gain
and then going from 1.25mhz to 625khz bandwidth  (again pretending the software is capable of this) will show even better  S/N ratios.
 
I guess the question is... where do you stop... due to lower data transfer rates... but in the name of higher S/N numbers ?   I think the way to determine this is  by doing  exactly what you are doing, AB comparisons of all types of scenarios; with your locations specifics & uniquness,  One thing I have learned is that  "one size fits all"  does not always apply in Ham Mesh networking.  Hope you can find the right combination to get the specific outcome desired.


 

KF6VFZ
802.11g bandwidth -v- snr
"going from 20 to 10mhz will show a S/N ratio improvement." ???
How is this possible with 802.11g style modulation?

To change occupied bandwidth from 20MHz to 10Mhz one has to use 26 carriers instead of 52.
The modulation schemes and therefore needed snr for each carrier remains the same.
Therefore changing 'bandwidth' only changes two things: the occupied spectrum width and the available bitrate.

802.11g is not old-style am or fm.

KF6VFZ
K6AH
K6AH's picture
SNR and Bandwidth

TIm, N8NQH, is correct.  The received noise power is reduced by 3dB each time you cut the bandwidth in half... it's listening to half the spectrum, therefore hearing half the noise.  This is independent of modulation scheme.  You can see it on the GUI's charts page.  But, due to the way the Atheros SoC chip works (it has no knowledge of absolute signal strength) it will be reflected in an apparent 3dB increase in the received signal strength... and hence in a 3dB increase in SNR.

This law of physics is the primary reason for running narrower bandwidths. 

Andre, K6AH​

AE6XE
AE6XE's picture
If the xmitter -> Power Amp
If the xmitter -> Power Amp is concentrating the same energy into half the bandwidth, wouldn't this be +3dB SNR?

The noise power in the hardware factoring into receiver sensitivity would be affected to lower the noise floor.  So at 20Mhz the chip has thermo noise at -95dBm, but at 10Mhz the noise is 3dB lower at -98dBm.  (lower the RX sensitivity specs at the various link rates by 3dB.)  Half the ambient noise from other sources is also filtered out.   

Joe AE6XE
KG6JEI
The RX sensitivity is not
The RX sensitivity is not necessarily increased, there could always be an internal noise floor that limits the signal so one can not assume the lower figure.

it does however indeed increase the power density as its (up to) 28dbm spread across 10Mhz  instead of 20Mhz so the power per hz is double (3db)
N8NQH
N8NQH's picture
The RX sensitivity is not increased...

The RX sensitivity is not necessarily increased...it does however indeed increase the power density as its (up to) 28dbm spread across 10Mhz  instead of 20Mhz so the power per hz is double (3db)


correct.

Look, if there's a Mesh grid that is barely communicating - not even gettng other nodes status screens to load without erroring out... then by all means... do what you have to.

I have viewed 720p live video over a 2.4 link... with a S/N of 15, this a over just one "hop"..  Occasional freezing, but watchable.  This same   dual hop - but  at a reduced bandwidth... may indeed improve the S/N numbers by 2-4 db... but actually worsen the video playback due to data rate " pipelining" (if there is such a word) :-)

It's easy to sit here and say these things... at a distance from the localized group that's trying to make Mesh work in their area..  But you do reach a point that Manipulating/increasing the S/N figure (via reducing the bandwidth) becomes counter-productive.  How do you determine the best setting???  By doing exactly what Bob and his Meshies are,  trial & error testing with different settings.

K6AH wrote:

The received noise (level) is reduced by 3dB each time you cut the bandwidth in half... it's listening to half the spectrum, therefore hearing half the noise.  This is independent of modulation scheme.


AE6XE
AE6XE's picture
We have to clarify our terms.
We have to clarify our terms.   RX Sensitivity is a property of the hardware based on thermo noise.  It is 3db less when cutting the bandwidth in half.   This is a non-factor, to everyone's point,  because the 'ambient noise" (as Andre references "received noise") in our world is the overriding factor, unless we're on the back side of the moon :) .

+1 we just have to try it out to know.   For the same xmit energy and uniform ambient noise, the same overall channel rates occur in both 10 and 20Mhz channel widths.   This assumes the environment is not capable of doing the max rate in 20Mhz--that we're optimizing--and there's a low rate that works to begin with on 20Mhz channel.   Because ambient noise is NOT uniform,  we have more opportunity to find a crack with lower noise levels somewhere to achieve an overall higher SNR and rates.  If 20Mhz channel doesn't work at all, then 10Mhz has one even lower rate options that might work (half of MSC0 option, then 5Mhz has MSC0/4 ).

If there's a competing 802.11ac 80Mhz signal out there that sets the bar for the environmental noise, it should be a wash on the channel width we're using, we'd still be getting the same rates through out this 80Mhz space, and the wider channels might not work at all.   Cutting the bandwidth in half means we have to double the rate per OFDM bin to achieve the same overall channel rate. We need every bit of the 3db SNR increase to do this.  Although I'm not factoring in the protocol overhead with the different MCS levels that may be a factor.

Joe AE6XE
N8NQH
N8NQH's picture
the  statement made was that
the  statement made was that SN ratio  numbers improve when reducing bandwidth; and this is fact.
AE6XE
AE6XE's picture
yes, I think we're all in

yes, I think we're all in violent agreement on that point :) .     And the +3 dB SNR gain enables double bit rates in half of the 'bins' in this half-bandwidth to achieve same overall channel rate, before and after.

[...add on comment]
The issue may be where that SNR gain comes from.   It comes from the fact that the transmitter power is not cut in half--the power density per hertz doubles with half the bandwidth.    The SNR increase doesn't come from the ambient noise if it were uniform over the freq space--which remains the same power density per hertz.   Now if we can find a 10Mhz channel where the ambient noise is less per hertz, not uniform,  than exists for a 20Mhz channel, then this should also contribute to an increased SNR.  

The smaller channel widths provide benefit 1) necessary to achieve sufficient SNR to establish a link to begin with; 2) more opportunity to find a sweet spot lowest contention or noise channel that yields better rates than a larger bandwidth channel has available.  

N8NQH
N8NQH's picture
(No subject)

double post !
not able to delete...sorry.

w6bi
w6bi's picture
RTSP & webcams

I'm no webcam expert, but - 
Most current webcams support RTSP; look in the alphabet soup of protocols listed for the camera and make sure it's listed.
The RTSP protocol typical uses port 554 (rather than 80 for HTTP) and there are several video streams available on that port.
Typically the URL would look like RTSP://<hostname>:554/<nameoffirststream>   and RTSP://<hostname>:554/<nameofsecondstream>    Sometimes the :554 isn't even needed.

There are a couple of hurdles to get past:

  • Documentation for RTSP sucks for most cameras; I use the HOSAFE that K5DLQ recommended and had to search the internet for its stream configurations.  I did find this link - it may be helpful.
  • Browsers don't know what to do with RTSP; they'll throw up their hands (figuratively) when you click on an RTSP: link.    There are two ways to get around this:
    • Copy & paste the stream URL into an RTSP-aware viewer program (VLC and mplayer are two we use - our vote at the moment is for mplayer)
    • configure your browser to launch that viewer when you click on the link.  There's documentation out there on how to do it for Firefox; there probably is for Chrome, too.  (Don't ask me about IE; I don't run any MS OSes at home).

Hope that helps...


 

w8erd
RTSP Syntax
Thanks for all the great info.
When connecting to a remote IP camera via the mesh, we know the IP address OK, but what is the  <name of stream> ?
73

Bob W8ERD
K5DLQ
K5DLQ's picture
that depends entirely on your
that depends entirely on your camera manufacturer.  A quick Google search should turn up some for the common cameras out there.
 
w6bi
w6bi's picture
Try this
This link has a lot of cameras listed.
KK6IZS
Mesh Overhead
We have noticed that MeshChat will ping every node on the mesh even if that node has not pushed any messages. Optimally, only nodes with new traffic would push traffic to the mesh. As a result, we have seen 30 - 40 delays is messages posting. So, depending on your services, you can get traffic jams.
KG6JEI
Just a note all this thread
Just a note all this thread looks like it is starting to diverge away from the original topic of how much overhead is in the network from the nodes just speaking to each other to form the mesh network.

Some of these subjects may be better handled in their own threads so that users in the future can find the information they need where they expect to.

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer