b.a.t.m.a.n.lists.open-mesh.org archive mirror
 help / color / mirror / Atom feed
From: "Linus Lüssing" <linus.luessing@web.de>
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.] [PATCH 4/5] batman-adv: Make number of (re)broadcasts configurable via sysfs
Date: Sun, 10 Oct 2010 16:49:30 +0200	[thread overview]
Message-ID: <20101010144930.GA1843@Sellars> (raw)
In-Reply-To: <201010101453.52594.lindner_marek@yahoo.de>

On Sun, Oct 10, 2010 at 02:53:51PM +0200, Marek Lindner wrote:
> On Sunday 10 October 2010 06:30:00 Linus Lüssing wrote:
> > Depending on the scenario, people might want to adjust the number of
> > (re)broadcast of data packets - usually higher values in sparse or lower
> > values in dense networks.
> 
> Is there a good reason to change this value at runtime or would a define be 
> enough ? I just get scared when we add too many options that almost nobody 
> cares about.
Well, as said before, in some cases the default value of 3 might
be too much, in other cases too less, depending on the topology.
However, you might know the kind of topology you have in advance
and would like to tweak that without having to know how to for
example rebuild a complete image and reflashing it on all
devices. You might want to test different values for your topology
for tweaking, without having to reflash / reload the kernel module
on all devices.

I also don't think too many configuration options in sysfs are
that much of a problem. There are also a dozen options for
tweaking IP in /proc/sys/net which nearly no one uses. But if
someone might need it, (s)he'll be very pleased to not having to
recompile and restart the whole kernel for that (or a kernel module
in our case).

The average user who might be scared of too many configuration
options will be using batctl anyway, won't (s)he? So I'd rather
plead to add tweaking options to the sysfs, but omitting them in
batctl. Or what do you think?
> 
> In other words: What is the use case ? Can we handle it by some kind of auto-
> detection ?
Sure we could, but then we'd need some more information about the
neighbourhood, i.e. with something like a seperate neighbor
discovery protocol giving 2-hop-neighbourhood information.
Otherwise a node would probably usually send the maximum amount of
rebroadcasts as there might be a node in the far distance with a
very low tq-value. But that'd require much more effort to
implement then these couple of lines :).

Thanks for reviewing

Cheers, Linus
> 
> Regards,
> Marek
> 

  reply	other threads:[~2010-10-10 14:49 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-10  4:29 [B.A.T.M.A.N.] [PATCH 1/5] batman-adv: Wrapper functions for sysfs storing Linus Lüssing
2010-10-10  4:29 ` [B.A.T.M.A.N.] [PATCH 2/5] batman-adv: Introduce generic BAT_ATTR_* macros Linus Lüssing
2010-10-10  4:39   ` Linus Lüssing
2010-10-10  8:45     ` Andrew Lunn
2010-10-10 10:34   ` Sven Eckelmann
2010-10-10 12:42   ` Marek Lindner
2010-10-10 19:00     ` Linus Lüssing
2010-10-11  8:04       ` Sven Eckelmann
2010-10-10  4:29 ` [B.A.T.M.A.N.] [PATCH 3/5] batman-adv: Make hop_penalty configurable via sysfs Linus Lüssing
2010-10-10 12:49   ` Marek Lindner
2010-10-10 14:51     ` Linus Lüssing
2010-10-10  4:30 ` [B.A.T.M.A.N.] [PATCH 4/5] batman-adv: Make number of (re)broadcasts " Linus Lüssing
2010-10-10 12:53   ` Marek Lindner
2010-10-10 14:49     ` Linus Lüssing [this message]
2010-10-10  4:30 ` [B.A.T.M.A.N.] [PATCH 5/5] batman-adv: Fix resizing of broadcast seqno buffers on if deletion Linus Lüssing
2010-10-12  9:51   ` Marek Lindner
2010-10-10  8:12 ` [B.A.T.M.A.N.] [PATCH 1/5] batman-adv: Wrapper functions for sysfs storing Andrew Lunn

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=20101010144930.GA1843@Sellars \
    --to=linus.luessing@web.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;
as well as URLs for NNTP newsgroup(s).