Axel Neumann wrote:
> > Does that mean that your svn directories and git repositories at
> > open-mesh.org can be dropped
>
> In the long term yes! But please not right now. I want to update links in
> other repositories like openWrt first and give users some time to update
> their checkout as well so that the build process does not fail. Lets say
> in February.
Ok, sounds good.
> > (at least it seems that no branch has common
> > ancestors with your branches)?
>
> For branches/bmx-0.3.x/ I used git-svn to create the git repository which
> I expected to create common ancestors. Some confusion leaked in when I
> moved the directory from trunk/batman-experimental to branches/bmx-0.3.x
> (some deleted files like LIESMICH,.. were not deleted which I fixed with
> the last git commit).
The problem is that you (sry, no offence meant) did a quite bad job to convert
it. bmxd.git has these weird git-svn-id lines in the commit messages, "random"
commiter names+mails, missing parts of the history, dangling symlinks, ...
Please take a look at git://git.open-mesh.org/ecsv/test/bmx.git
I don't say that it is the holy grail of svn-to-git conversation, but I think
it could be a better conversation than your bmxd.git
Best regards,
Sven
---------- Forwarded message ----------
From: hlabishi kobo <hlabishik(a)gmail.com>
Date: Sun, 28 Nov 2010 22:06:01 +0200
Subject: Fwd: BATMAN routing
To: lindner_marek(a)yahoo.de
Hi
Thank you very much for your reply. The reason why i sent this to you and
your colleague is that i have tried the mail list before and all my post
kept on being returned, i used this address
b.a.t.m.a.n-owner(a)lists.open-mesh.org. I would really appreciate it if this
can reach the mailing list public (i will keep on trying). i will send you a
follow up on the full explanation of the concept like you requested.
Regards
Hlabishi
---------- Forwarded message ----------
From: <b.a.t.m.a.n-owner(a)lists.open-mesh.org>
Date: Sat, Nov 27, 2010 at 12:58 AM
Subject: Fwd: BATMAN routing
To: hlabishik(a)gmail.com
Message rejected by filter rule match
---------- Forwarded message ----------
From: hlabishi kobo <hlabishik(a)gmail.com>
To: b.a.t.m.a.n(a)lists.open-mesh.org
Date: Sat, 27 Nov 2010 00:58:09 +0200
Subject: Fwd: BATMAN routing
---------- Forwarded message ----------
From: Marek Lindner <lindner_marek(a)yahoo.de>
Date: Fri, Nov 26, 2010 at 5:23 PM
Subject: Re: BATMAN routing
To: hlabishi kobo <hlabishik(a)gmail.com>, Linus Lüssing <
linus.luessing(a)web.de>
Cc: siwu(a)hrz.tu-chemnitz.de
Hi,
welcome to the project! :-)
> Firstly my apologies for sending this email to your personal email. My
name
> is Hlabishi Isaac Kobo at the, an Msc computer science student at the
> University of the Western Cape in South Africa, I am doing a research on
> routing in a hybrid (combination of static and mobile dynamic routers)
> mesh.
I don't see a good reason to apologize, just wondering why you are not
sending
this mail to the public list ?
> I want to use the mesh potatoes as well as the batphone (android
> version of batman) to create a mesh model.
What is the "batphone" ? A project name or a nick name you invented ? :-)
Note: Various tests have shown that running a mobile device
(smartphone/tablet/etc) in adhoc mode plus running a mesh protocol on top is
a
battery killer, hence not practical in real world scenarios (in addition of
the hassle to install and configure the mesh software on each and every
device). This was one of the main reasons to start developing batman-adv as
it
allows mobile devices to take advantage of the mesh (e.g. roaming) without
having to run the mesh on the device itself.
You might be aware of this - I am just mentioning it because many people are
not.
> First we say the recently received OGMs will give a clear indication on
the
> reliability on the link, so we give the recently received OGMs from the
> sliding window a priority in deciding the best next hop link towards a
> destination. We want to count and add the indexes were an OGM was recorded
> in an interval (seconds), (hence the recently received OGM will have more
> weight). At the end the link with more recent OGMs will have more weight
> and hence become the current best link.
This is a good idea. We are in the process of redesigning the current
protocol
and welcome any input. Giving older OGMs less "weight" was also one of the
ideas we had. Would you mind explaining your concept in greater detail ?
> I went through the source code so many times and I got few questions about
> this:
Are we talking about the batman daemon source code or the batman-adv kernel
module ? All my answers will refer to the kernel module as this is the place
where most of the development is going on at the moment.
> 1. What structure is used to keep track of the sliding window? If its the
> has how does it get updated based on the sliding packet range?
Each "struct orig_node" has a bitarray to keep track of its own seqnos
repeated by its neighbors (bcast_own) and each "struct neigh_node" having a
bitarray for its own OGMs (real_bits).
> 2. How are the OGM's recorded, is in a form of binary where 1 will
> represent the received OGM and 0 otherwise?
Correct.
> 3. I looked in the source and still not sure of where the ranking
decisions
> are made, can you enlighten me on that?
You mean which function changes the route when a better neighbor was found ?
That would be update_orig() in routing.c.
> On the second approach we want to use mac layer stats to estimate the
> signal strength and probably the congestion rate of the top N ranked
links.
> We acknowledge the fact that usually links with lower signal strength will
> loose more OGM's which results in an automatic low rank, however in a
> frequently changing topology, current signal strength is crucial. We plan
> to use SNR or RSSI in this case.
The concept is known since a while but nobody has implemented it so far
because its implementation is fairly complex. Do you have an idea how it
should work in the end ?
> 1. How can i get the RSSI/LQI of th neighbor links?
I don't get this question. You intend to use RSSI but you don't know how ?
> I would really appreciate your opinions and advices in this regard more
> specially how to go about implementing changes in BATMAN protocol.
This is a little abstract. Usually, we discuss specific concepts / ideas in
our
IRC channel or on the mailing list long before starting to implement them.
The
past has shown it is often better to let other people dive into your ideas
and
comment because routing is a rather complex subject.
As I mentioned above: We are in a redesign phase right now and welcome
anyone
interested to join. As the next step we envisioned a collection of routing
scenarios in which the current implementation behaves poorly. All routing
protocol changes have to go through this collection of scenarios to estimate
its impact. What do you think about this idea ?
Regards,
Marek
Hello to everyone,
This is the second version of the HNAs announcement mechanism/Roaming
management paper. Please, consider it still a draft.
A lot of things have changed since the previous version of this paper.
As usual, feel free to comment it. I'll wait for your feedback :)
Link:
http://www.open-mesh.org/attachment/wiki/hna-improvements/handover.pdf
Ragards,
--
Antonio Quartulli
..each of us alone is worth nothing..
Ernesto "Che" Guevara
Hi there,
I found an interesting paper today that covers mobility of some nodes in
a batman-adv network:
> Stefano Annese, Claudio Casetti, Carla F. Chiasserini, Paolo
> Cipollone, Andrea Ghittino, and Massimo Reineri. 2009. Assessing
> mobility support in mesh networks. In Proceedings of the 4th ACM
> international workshop on Experimental evaluation and
> characterization (WINTECH '09).
http://portal.acm.org/citation.cfm?id=1614297
Unfortunately, the paper is not freely available on the web. If you're
blessed with access to the ACM digital library by your school or
employer, you can download it free of charge; in other cases you'll have
to buy it for USD 15.
In the following, I will summarize relevant parts:
I) Weighting the local packet count
The authors found that when each entry in the sliding window is weighed
with the same weight as it is done in the current version of batman-adv,
routing loops can occur when mobility is present. They greatly improve
their results by weighting with the following function (i = 0..S-1 where
S is the window size; 0 means freshest packet):
weight(i) := max(1, floor(i * S / e^i))
This function seems to be suboptimal as it weights entry 0 with 1 while
the following few entries are boosted with a weight of up to 20 (see
attachment). Adding 1 to i should deal with this flaw.
However, this weighting function lead to big improvements in the
authors' simulations, so I think you are on the right track when
thinking about introducing some kind of weighting or moving average to
boost the weight of current packets.
Here's the Octave/Matlab code I used to create the plot (if you want to
do plots for other weighting functions that are discussed, just replace
the definition of w and don't forget to use .* and ./ instead of * and /
to enforce elementwise operations):
> x = 0:63
> w = max(1, x.*64./exp(x))
> stem(x,w)
> xlabel('age')
> ylabel('weight')
II) Optimizations for multi-interface nodes
The authors used nodes with 2 radios. They did roughly the following on
the mobile nodes (not on the fixed ones):
1) In regular intervals, scan the forwarding tables for each interface
to check if any neighbors are known. If an interface has no contact to
any neighbor, go to 2)
2) Use the interface without known neighbors to scan all channels except
the channel that the other interface is listening to. Don't send OGMs
but simply listen for OGMs from other stations. If a channel is found
that has a neighbor sending, stay on this channel and start to behave
like a normal batman-adv node (send OGMs etc.).
I'm not sure if this will be benefitial in other scenarios than in the
vehicular network scenario of the paper, but I wanted to share my
findings with you.
- Daniel
Hi,
the performance patches progress step by step. A few patches already went into
the repository the rest is waiting for more review. Thanks to Sven's feedback
quite some bugs were squashed.
Changes since v2:
* code rebased on top of the trunk
* some more neigh_node protected by reference counters
* call_rcu and kref_put race condition fixed
Known issues:
* bonding / alternating candidates are not secured by refcounting [see
find_router()] - ideas welcome
Regards,
Marek
Hi everyone,
thanks for all the feedback and reviewing again. The following updated patches
address Marek's comments and suggestions:
* Introducing a commit for renaming only
* batman_packet_ogm -> ogm_packet, batman_packet_ndp -> ndp_packet
* BAT_UNICAST followed by BAT_UNICAST_FRAG
* structs introduced in the patches where they're used, not earlier
(ndp_packet, neigh_entry)
* moved own_ndp_send_time to ndp.c
* checkpatch cleaning
* avoid losing ndp-interval setting on interface down/up
* fixed a potential memory leak in error cases
* skb_copy instead of skb_clone
* rebased to trunk
* removal of unnecessary include
* hlist instead of doubly linked list
* added a break in one list traversal
* secure neigh_list with rcu-locking + ref-counting
* rename rq_real_bits to ndp_rq_window
* use msecs_to_jiffies instead of manual HZ multiplication
* fix get_batman_if_by_netdev usage / refcounting
* adding licenses
Furthermore I've changed the following:
* use dev_kfree_skb instead of kfree_skb in case of successful
ndp packet reception and processing (so no simple NET_RX_DROP return value)
* adding include guards for ndp.h
* use "= seqno - 1" in ndp_create_neighbor(), otherwise ndp_update_neighbor_lq()
does not update tq/rq/last_valid on first ndp packet
Would be great if someone could check the usage of rcu-locking + refcounting.
I was also a little confused because in "Documentation/RCU/listRCU.txt" list_del_rcu()
and list_add_rcu() are not protected with a spinlock for the list here,
but in the batman-adv code we are usually having those extra locks. Do I have
to leave those spinlocks or can I remove them for adding/deleting entries in the
neigh_list?
Cheers, Linus
Hi everyone,
another small, but important update on the NDP patches:
* linearize NDP packet's skb before looking at its neighbor entries
* Avoid disabling bottom halves twice when receiving/processing OGMs
Cheers, Linus
After changeset 1888, the return value of hna_local_fill_buffer() has
not been changed to _count_. In this way an eroneous num_hna was
calculated before sending the new OGM packet.
---
translation-table.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/translation-table.c b/translation-table.c
index a19e16c..a633b5a 100644
--- a/translation-table.c
+++ b/translation-table.c
@@ -162,7 +162,7 @@ int hna_local_fill_buffer(struct bat_priv *bat_priv,
atomic_set(&bat_priv->hna_local_changed, 0);
spin_unlock_bh(&bat_priv->hna_lhash_lock);
- return i;
+ return count;
}
int hna_local_seq_print_text(struct seq_file *seq, void *offset)
--
1.7.2.2
After changeset 1888, the return value of hna_local_fill_buffer() has
not been changed to _count_. In this way an eroneous num_hna was
calculated before sending the new OGM packet.
Axel Neumann wrote:
> On Montag 20 Dezember 2010, you wrote:
> > Please take a look at git://git.open-mesh.org/ecsv/test/bmx.git
> > I don't say that it is the holy grail of svn-to-git conversation, but I
> > think it could be a better conversation than your bmxd.git
>
> I am kind of git newbie. You are right and I see what you mean. Finally I
> decided to simply fetch the bmx-0.3.x branch from the repository you
> mentioned and offer it as a bare master branch at
> git://git.bmx6.net/bmxd.git .
>
> Is there a one line command you used to create this? Essentially I used:
> git svn init http://downloads.open-mesh.org/svn/batman/trunk/batman-
> experimental/
> to create my former repository but obviously this missed some initial
> commits, full names,...:-(
No, not really. I tried different things in the past, but none was really able
to create an useful export. For example the batman-adv repo was created using
following command:
$ git svn clone --minimize-url --follow-parent --use-log-author -A \
/home/batman/batman-adv-sync/batman-svn-git-sync/.git/AUTHORS \
--no-metadata http://downloads.open-mesh.org/svn/batman/trunk/batman-adv/
But your history is a little bit more complex. For example git-svn will not
resolve the symbolic links - but also svn-all-fast-export wasn't able to
export all those things correctly when I tried it. My solution was to write a
simple exporter with a static mapping [1] which was optimized for the needs of
open-mesh.org. It is a little bit hacky, but at least it solved all problems
quite well.
Best regards,
Sven
[1] http://gitorious.org/git-conversation-svn