public inbox for b.a.t.m.a.n@lists.open-mesh.org
 help / color / mirror / Atom feed
From: Sven Eckelmann <sven@narfation.org>
To: b.a.t.m.a.n@lists.open-mesh.org
Subject: Re: maximum hop count
Date: Thu, 16 Apr 2020 15:22:47 +0200	[thread overview]
Message-ID: <10653471.RuQBq8sfPP@bentobox> (raw)
In-Reply-To: <db951dbb-7ec9-6938-faa7-bf2b46eeda30@web.de>

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

On Thursday, 16 April 2020 14:26:14 CEST Moritz Warning wrote:
> Hi,
> 
> I run a simulation of 50 batman-adv instances connected on a chain topology:
> 
> [node-0] <-> [node1] <-> ... <-> [node49]
> 
> Despite there being no packet loss, the nodes at both ends (nodes 0 and 49) only see 32 other nodes.
> 
> The second outermost nodes see 33 other nodes and so on until the nodes that are at least 18 hops from both ends (nodes 17 and 32), which see all other 49 nodes.
> 
> The OGM TTL is set to 50 [1], but from this experiment, the TTL seems to be 32.
> 
> Can someone shed light on this observation?
> The batman-adv version used is 2019.4.


[2020-04-04 15:13:28] <mwarning> does batman-adv has a maximum hop count? (given that there is no packet loss)
[2020-04-04 15:13:54] <mwarning> I get some funny results while testing with a lot of nodes in a line.
[2020-04-04 16:21:16] <hexa-> hop_penalty gets subtracted from the tq on each hop, so yes
[2020-04-04 17:23:46] <T_X> also, the OGM TTL is 50 (in case mwarning comes back and someone wants to tell him)
[2020-04-04 17:23:49] <T_X> https://git.open-mesh.org/batman-adv.git/blob/refs/heads/master:/net/batman-adv/main.h#l26
[2020-04-04 22:17:02] <marec> mwarning: <T_X> also, the OGM TTL is 50 (in case mwarning comes back and someone wants to tell him)
[2020-04-04 22:17:09] <marec> mwarning: <T_X> https://git.open-mesh.org/batman-adv.git/blob/refs/heads/master:/net/batman-adv/main.h#l26
[2020-04-04 22:20:11] <mwarning> ah
[2020-04-04 22:20:17] <mwarning> marec: thanks
[2020-04-04 22:21:50] <mwarning> https://mwarning.de/misc/convergence-line.png
[2020-04-04 22:22:24] <mwarning> ^ I was worried because batman-adv didn't reach 100% in this artificial test of 100 nodes in line
[2020-04-04 22:24:53] <mwarning> T_X: thanks
[2020-04-04 22:25:36] <mwarning> is there a technical reason for it to be set to 50? Or is it just high enough for technical reasons?
[2020-04-04 22:25:52] <mwarning> * high enough for practical reasons
[2020-04-04 22:35:21] <ordex> mwarning: I think nobody ever came up with a real use case where 50 was not enough
[2020-04-04 22:35:50] <ordex> due to hop penalty and natural metric reduction, a path will most likely never reach 50 hops
[2020-04-04 22:36:33] <mwarning> true (over wifi)
[2020-04-04 22:36:49] <mwarning> a lattice of 100 nodes is much better: https://mwarning.de/misc/convergence-lattice4.png
[2020-04-05 01:08:04] <marec> mwarning: feel free to propose a patch increasing the TTL on the ml
[2020-04-05 01:08:22] <marec> if you feel a bigger TTL is worthwhile
[2020-04-05 01:16:48] <mwarning> I doubt it is worthwhile. That one test was artifical.
[2020-04-05 01:17:45] <mwarning> I will test batman-adv with 1000 nodes tomorrow. But on a lattice.
[2020-04-05 01:18:24] <mwarning> (and if the server can handle the load)
[2020-04-05 11:08:01] <ordex> mwarning: but it seems batman-adv eventually manages to deliver to every node, right ?
[2020-04-05 11:08:07] <ordex> so there is no reachability problem apparently ?


Also regarding the hop penalty - let us the TQ after these amount of hops 
(really, really, really simplified):

  >>> 255 * ((255 - 30) / 255.) ** 32
  4.646168821433396


Now do the same with integer math:

	 def new_tq_penalty(tq):
	 	 hop_penalty = 30
	 	 BATADV_TQ_MAX_VALUE = 255
	     
	 	 new_tq = tq * (BATADV_TQ_MAX_VALUE - hop_penalty);
	 	 new_tq /= BATADV_TQ_MAX_VALUE;
	     
	 	 return int(new_tq)
	 
	 tq = 255
	 for i in range(32):
	     tq = new_tq_penalty(tq)

	 print(tq)

And even in a perfect scenario, you would only have a tq of 0. And here we 
even ignored that wifi interfaces which are used as incoming and outgoing 
interfaces have an extra round of penalty for each link.

Originator nodes with a TQ of zero are filtered out [1] during the print and 
are also not forwarded [2].

Kind regards,
	Sven

[1] https://git.open-mesh.org/batman-adv.git/blob/e13bcb6db03b74e1eb77e7410761db6eca25d48e:/net/batman-adv/bat_iv_ogm.c#l1849
[2] https://git.open-mesh.org/batman-adv.git/blob/e13bcb6db03b74e1eb77e7410761db6eca25d48e:/net/batman-adv/bat_iv_ogm.c#l1357

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

  reply	other threads:[~2020-04-16 13:22 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-16 12:26 maximum hop count Moritz Warning
2020-04-16 13:22 ` Sven Eckelmann [this message]
     [not found]   ` <95ae53f7-66a4-decf-85c6-53955426e638@web.de>
2020-04-17  6:33     ` Sven Eckelmann

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=10653471.RuQBq8sfPP@bentobox \
    --to=sven@narfation.org \
    --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