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
Does this increase if you have more nodes?
Is it a problem if you have lots of nodes connected?
Bob W8ERD
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)?
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.
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.
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.
"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."
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.
Thanks !
Although it may be obvious to some, it's reassuring to hear the info given in a definitive manor.
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.
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
10 Mhz the SNR will be even less.
Bob W8ERD
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.
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
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
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
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:
+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
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.
double post !
not able to delete...sorry.
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:
Hope that helps...
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
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.