From: "Linus Lüssing" <linus.luessing@c0d3.blue>
To: The list for a Better Approach To Mobile Ad-hoc Networking
<b.a.t.m.a.n@lists.open-mesh.org>
Subject: Re: [B.A.T.M.A.N.] is the multicast performance throttled?
Date: Sun, 14 Aug 2016 19:21:28 +0200 [thread overview]
Message-ID: <20160814172128.GD8599@otheros> (raw)
In-Reply-To: <1470988256.16102.4.camel@gmail.com>
On Fri, Aug 12, 2016 at 09:50:56AM +0200, Ignacio Quezada wrote:
> > UDP has no flow control. That's why I was asking about the bitrate
> > you have configured in the application. Sending with "as fast as
> > possible" will basically jam your (and your neighbors) wifi. And
> > will create trouble for batman-adv to find usable routes too
> > without any airtime available.
> >
> > Regards, Linus
>
> What I don't understand is that you are explaining standard behavior of
> WiFi networks, but using plain WiFi without batman works ok and the
> multicast goes up to 100kb/s (I think I wrote that in my first email).
> The tests have been like this so far:
> - wlan0 (no batman), multicast: 100kb/s
> - wlan0 (no batman), unicast: 100kb/s
> - bat0, unicast: 100kb/s
> - bat0, multicast: 20kb/s
Yes, read your first email and that's the oddity I'm trying to
figure out :-).
Let me try to rephrase. One guess I'm having (which might be
wrong), that the multicast traffic on bat0 is interfering with the
control packets ("Originator Messages" in batman speak). And that
this breaks even one-hop routes. Hm, ok, on the other hand, even
with no routes, flooded multicast would "work" because it doesn't
use the routes discovered by OGMs. Next guess. (although the
output of the originator table, "batctl o", before and during your
application transmitting would be interesting to check whether
there is an effect/interference)
Second guess (which is probably it :-) ): In general, batman-adv
(re)broadcasts a multicast packet three times on an interface. To
ensure proper reception even over multiple hops.
That might even add up with your numbers: Initial sender
broadcasts three times, neighbor rebroadcasts three times, so
6*16kb/s ~ 100kb/s. 100kb/s => 0.800Mbit/s, which is already
oversaturating the gross 1MBit/s wifi multicast rate (@1MBit/s gross
it's usually more like 0.5MBit/s net at least for unicast,
multicast might be something between 1MBit/s and 0.5MBit/s net).
>
>
> PS: Emails from the Gmail Android App get rejected by the mailinglist,
> I guess it is because of the HTML format? I wasn't able to disable it,
> back at the desktop.
Yes, this mailinglist rejects HTML mail. To cope with spam,
I think.
Regards, Linus
next prev parent reply other threads:[~2016-08-14 17:21 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-11 15:13 [B.A.T.M.A.N.] is the multicast performance throttled? Ignacio Quezada
2016-08-11 15:47 ` Linus Lüssing
2016-08-11 16:09 ` Ignacio Quezada
2016-08-11 16:31 ` Linus Lüssing
2016-08-12 7:50 ` Ignacio Quezada
2016-08-14 17:21 ` Linus Lüssing [this message]
2016-08-14 17:28 ` Linus Lüssing
2016-08-15 18:03 ` Ignacio Quezada
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=20160814172128.GD8599@otheros \
--to=linus.luessing@c0d3.blue \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.