public inbox for b.a.t.m.a.n@lists.open-mesh.org
 help / color / mirror / Atom feed
From: Simon Wunderlich <sw@simonwunderlich.de>
To: b.a.t.m.a.n@lists.open-mesh.org
Subject: Re: [B.A.T.M.A.N.] video streaming over batman-adv
Date: Fri, 16 Oct 2015 13:28:55 +0200	[thread overview]
Message-ID: <2791733.raofpuymoN@prime> (raw)
In-Reply-To: <001f01d107fd$2a0f9680$7e2ec380$@itelsis.com>

[-- Attachment #1: Type: text/plain, Size: 3004 bytes --]

Hi Santiago,

On Friday 16 October 2015 12:26:48 Santiago Álvarez Álvarez wrote:
> Hi everybody,
> I’m an engineer working in a R&D Project using batman-adv protocol. We’re
> trying to develop a mesh network using linux devices with the objective of
> transmitting video in streaming. Video is being generated with gstreamer
> using UDP.
> The application works relatively fine with 2 devices, but efficiency heavily
> decreases when introducing a new node in the mesh network (information need
> two jumps to arrive to destination). Introducing more jumps in the network
> is exponentially worst. We have been expecting a better behavior of this
> protocol, since level 2 routing should be transparent  (just increasing
> delay when increasing the number of nodes).

Did you consider the effects of the half-duplex nature? Your intemediate hop 
will have to listen to the sender and and send each packet also to the 
receiver. This means it has to send and receive each packet twice, so needs 
double amount of airtime and therefore the throughput will be halved. Adding 
more repeaters is even worse. This is a well known effect in mesh networks and 
is not limited to Layer2/3. Usually your first hop drops to 50%, second to 33% 
and so on.

The only way to resolve that would be to use multiradio access points on 
different frequencies.

> We are using batman version 2015.0,  over wifi interfaces, and our streaming
> applications is working only point-to-point (not multicast or broadcast).
> The nodes in between server and client are working just as wireless
> repeaters using batman-adv.
> We also discovered that worst case happens when changes in batman routing
> tables are happening (sometimes, client is able to reach server in just one
> jump, but with low quality, and chooses that option instead of jumping
> through the repeater node, with better quality). When that happens, we're
> droping lots of packets.

Another thing you should consider is rates: your wifi card has a rate control 
algorithm implemented which will choose the best rate, which can be anything 
between 1 Mbit/s and 450 MBit/s (depending on  your hardware of course). 
Choosing a low throughput rate also results into losses if your video stream 
needs more throughput than the channel can give you.

> Any of you haver tried batman-adv for video streaming? Which was the maximum
> number of jumps between batman nodes that you can manage maintaining a good
> video quality?

I've seen for some cases. It can work over multiple hops, but it heavily 
depends on your video stream. There are also WiFi parameters you might tune.

> Can you recommend any specific configuration for improving batman behavior?

First, I would suggest to use a higher multicast rate (WiFi configuration). 
Another thing to consider, if this is a setup which should only send video 
streams, is to limit the WiFi rates to some high rates like 18 Mbit/s and up.

Cheers,
     Simon

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

  reply	other threads:[~2015-10-16 11:28 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-16 10:26 [B.A.T.M.A.N.] video streaming over batman-adv Santiago Álvarez Álvarez
2015-10-16 11:28 ` Simon Wunderlich [this message]
2015-10-16 13:21 ` Linus Lüssing
2015-10-19  9:36   ` Santiago Álvarez Álvarez

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2791733.raofpuymoN@prime \
    --to=sw@simonwunderlich.de \
    --cc=b.a.t.m.a.n@lists.open-mesh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox