All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Wunderlich <sw@simonwunderlich.de>
To: Jake.Harris@zf.com
Cc: b.a.t.m.a.n@lists.open-mesh.org
Subject: Re: [B.A.T.M.A.N.] broadcast storms
Date: Tue, 13 Nov 2018 16:26:14 +0100	[thread overview]
Message-ID: <2217702.0z5C6BKyfH@prime> (raw)
In-Reply-To: <B99A1AB9A294834C8DF94185A5E9D18101784D2AFE@NRTV96002.america.zf-world.com>

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

On Tuesday, November 13, 2018 2:55:31 PM CET Jake.Harris@zf.com wrote:
> > Mhm, this is really not much data ... did you try the multicast as
> > suggested in an earlier reply?
> What earlier reply are you referring to? The only one I'm noticing is the
> tip to boost the multicast bandwidth, but I cannot see this being fruitful
> to update the configuration of all 50 nodes when worst-case I'm using less
> than 1% of the max throughput.

One aspect is that the multicast rate is also changing the modulation rate of 
beacons. If you have >50 nodes beaconing with 1 Mbit/s you are already filling 
up your airtime with beacons. Do the math - one beacon takes about 1ms on 1 
Mbit/s, each node sends about 10 beacons per second ...

This is actually very important and will most likely help already. It would be 
a better fix than changing the protection window.

> > BATADV_RESET_PROTECTION_MS is a define in the batman-adv C-code, so it
> > can't be set at runtime but only at compile time.
> While this sounds like an utter pain in the butt to recompile and update the
> code on all the nodes to make this change, I believe this has a far better
> chance of alleviating the issue, I'm looking into how to do this since I've
> never compiled anything myself but I can't see it being too difficult.
> 
> One observation I made when rebooting the swarm all at once, about a minute
> after all the pi's go down the laptop I work off (running batctl td bat0)
> reports a whole bunch of backbone unannounced messages I believe. I'm
> assuming there is one message per node but have not verified, my guess is
> this is normal and is not the cause of these issues?
> 
> Again, thank you


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

      reply	other threads:[~2018-11-13 15:26 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-22 13:07 [B.A.T.M.A.N.] broadcast storms Jake.Harris
2018-10-22 14:26 ` Simon Wunderlich
2018-10-22 17:27   ` Jake.Harris
2018-10-22 18:17     ` Simon Wunderlich
2018-11-12 14:29       ` Jake.Harris
2018-11-12 17:13         ` Simon Wunderlich
2018-11-13 14:55           ` Jake.Harris
2018-11-13 15:26             ` Simon Wunderlich [this message]

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=2217702.0z5C6BKyfH@prime \
    --to=sw@simonwunderlich.de \
    --cc=Jake.Harris@zf.com \
    --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.