All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Antonio Quartulli <antonio@meshcoding.com>
Cc: 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.] Suggestion for routing improvement on poor links
Date: Thu, 20 Feb 2014 11:10:45 +0100	[thread overview]
Message-ID: <20140220101045.GK11878@lunn.ch> (raw)
In-Reply-To: <5305CE85.6020201@meshcoding.com>

> Hi Andrew,
> 
> > 
> > That is not what i have seen in practice. Because the metric is good,
> > and does not degrade, 
> 
> The missing degradation is the part where I don't agree.
> 
> Just to be sure we are understanding each other, I am talking about the
> scenario depicted in this picture:
> 
> http://www.open-mesh.org/attachments/download/52/triangle.png

Thanks for the diagram. Yes, Linus and I had a somewhat similar setup.
We had more nodes involved, and B was walking around the inside of a
building.
 
> 'A' is the source node and 'B' is our destination. B moves and breaks
> the line-of-sight with A, thus making the A<->B link unusable at all (we
> assume that now packet loss on A<->B is 100%).
> 
> At this point A still receives B's OGMs via N1.
> 
> According to batadv_iv_ogm_orig_update() (in bat_iv_ogm.c) each time a
> packet with a _new_seqno_ is received the global window of _each_
> neighbour for the given originator is shifted by one slot and the
> averages are computed again.
 
It is a couple of years since Linus investigated this. So maybe things
have changed. If it does work like this, great, that helps solves a
problem we had. I don't currently have access to a system to test this
though.

	Andrew


  reply	other threads:[~2014-02-20 10:10 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-19 20:56 [B.A.T.M.A.N.] Suggestion for routing improvement on poor links whangarei & opua
2014-02-19 21:27 ` Antonio Quartulli
2014-02-19 22:12   ` whangarei & opua
2014-02-19 22:30     ` Antonio Quartulli
2014-02-20  8:54       ` Andrew Lunn
2014-02-20  9:03         ` Antonio Quartulli
2014-02-20  9:09           ` Andrew Lunn
2014-02-20  9:44             ` Antonio Quartulli
2014-02-20 10:10               ` Andrew Lunn [this message]
2014-02-20 10:33               ` Marek Lindner
     [not found]       ` <F42F9132-14DE-4496-A715-389CF13D6C49@gmx.de>
     [not found]         ` <5305C654.5020605@meshcoding.com>
2014-02-20 10:20           ` whangarei & opua
2014-02-22 13:20             ` Marek Lindner
2014-02-23 10:35               ` whangarei & opua

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=20140220101045.GK11878@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=antonio@meshcoding.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.