b.a.t.m.a.n.lists.open-mesh.org archive mirror
 help / color / mirror / Atom feed
From: Matthias Schiffer <mschiffer@universe-factory.net>
To: b.a.t.m.a.n@lists.open-mesh.org
Subject: Re: [B.A.T.M.A.N.] [PATCH 2/2] batman-adv: make number of broadcasts configurable per hardif
Date: Fri, 08 Mar 2013 20:42:34 +0100	[thread overview]
Message-ID: <513A3F2A.8090601@universe-factory.net> (raw)
In-Reply-To: <201303090328.38621.lindner_marek@yahoo.de>

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

On 03/08/2013 08:28 PM, Marek Lindner wrote:
> On Saturday, March 09, 2013 01:38:56 Linus Lüssing wrote:
>> From: Matthias Schiffer <mschiffer@universe-factory.net>
>>
>> In heterogenous networks, setting the number of broadcasts to differing
>> values on different interfaces can be beneficial.
>>
>> E.g., on wireless interfaces with high packet loss a higher number of
>> broadcasts may be necessary, whereas on low-bandwidth interfaces with
>> relatively high reliablily (such as VPN links over slow internet lines)
>> sending only a single packet makes more sense to preserve bandwidth.
> 
> In general, I like the idea but the approach isn't the best. Can't we automate 
> these settings instead of adding hundreds of little knobs nobody will 
> understand ? Why not detecting wifi interfaces as such and configure the 
> broadcast value accordingly ? The same goes for ethernet / vpns ?

While is makes sense to find some sensible defaults for such values, in
my opinion everything should be as configurable as possible. I don't
think it would be a problem to have some dozens knobs more if a normal
user almost never has to touch them. On the other hand, for testing,
debugging and development purposes, it can save a lot of time not having
to recompile the kernel for such changes all the time.

Also, for VPN connections, automatic detection of the link type isn't
generally possible, as we'd have to know which medium the VPN is going
over...

Regards,
Matthias

> 
> Cheers,
> Marek
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

  reply	other threads:[~2013-03-08 19:42 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-08 17:38 [B.A.T.M.A.N.] [PATCH 1/2] batman-adv: Make number of (re)broadcasts configurable via sysfs Linus Lüssing
2013-03-08 17:38 ` [B.A.T.M.A.N.] [PATCH 2/2] batman-adv: make number of broadcasts configurable per hardif Linus Lüssing
2013-03-08 19:28   ` Marek Lindner
2013-03-08 19:42     ` Matthias Schiffer [this message]
2013-03-08 20:06       ` Marek Lindner
2013-03-08 21:50         ` Matthias Schiffer
2013-03-09 10:07           ` Marek Lindner
2013-03-09 21:03     ` "Linus Lüssing"

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=513A3F2A.8090601@universe-factory.net \
    --to=mschiffer@universe-factory.net \
    --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).