On Monday 07 March 2011 22:00:25 hlabishi kobo wrote:
> Linus suggested to me that i should print the window and see how it
> looks, I did that and it returns this ef0fffffe, ffbffff, f70fffff,
> eb1b53c0, eb3950b8, eb1749c0. I am not sure if this are hexadecimal
> number or what.
I would think that you wrote the part which prints out this values. This means
that you know which parameters you gave printk and that you should know the
conversation specifiers and length modifiers that you used in the format
But I would guess without having any of these information that you used %x to
print these values. Whatever you used as argument - 32 bit (size of single
int) of it were printed in unsigned in hexidecimal notation. Maybe you should
think about using %lx to print unsigned long ints in hexidecimal notation in
case you really used %x.
Which brings me to another question: Why to I see 6 numbers in your post and
why has the first one 9 nibbles?
As said before (and also recommended by Linus): try to write a small c program
which uses these values, print the single bits, try to write some test
algorithm using these decoded bits and play a little bit around with other
test inputs before trying random things inside the kernel.
> Again this is the results of printing seq_bits, so far
> i have not been able to print real_bits as this cannot even make a
> network ping. Could you enlighten me in this case.
I cannot understand how pings and printks are related...
May I ask how these things are related to your work/studies? It is ok to play
around a little bit as small side project/hobby without having the time and
knowledge to understand what you are really doing. That is usually a good way
to find new interesting topics and maybe to learn something (or blow up a
building...). But I would highly recommend to switch the topic in case this is
part of your thesis or work.
It is not meant as harsh criticism of what you try to do, but it seems that
right now you aren't able to efficiently work with it and to gain enough
knowledge by yourself to be able to understand simple parts the thing you are
>From e03cb760a296b55138dd6507b5e676c22cecf37e Mon Sep 17 00:00:00 2001
From: Andrew Lunn <andrew(a)lunn.ch>
Date: Mon, 21 Mar 2011 21:31:44 +0100
Subject: [PATCH] [batman-adv] Set the txqueuelen to zero when creating soft interface.
Like other virtual interfaces, e.g. br0, we don't need a transmit
queue. Packets should only be queued on real interfaces which are
underneath. In practice this patch makes little difference since the
virtual interfaces can accept packets as fast as they come, but the
patch will avoid bufferbloat questions to the mailling lists in the
Signed-off-by: Andrew Lunn <andrew(a)lunn.ch>
Tested-by: Linus Luesing <linus.luessing(a)web.de>
soft-interface.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/soft-interface.c b/soft-interface.c
index 9ed2614..7230e33 100644
@@ -524,6 +524,7 @@ static void interface_setup(struct net_device *dev)
dev->hard_start_xmit = interface_tx;
dev->destructor = free_netdev;
+ dev->tx_queue_len = 0;
* can't call min_mtu, because the needed variables
We have just completed a brief research project looking at the performance
of BATMAN IV in a MANET with directional antennas. We've augmenting BATMAN's
route selection algorithm with a simple hysteresis mechanism called
"Batrytis" to reduce route-flapping in some circumstances. Please find
attached an initial technical report describing our work. You are welcome to
publish this on your site if you wish, and any feedback would also be
welcome. We have as yet not published this work, although it may be modified
into a conference paper later in the year. We probably will not have time to
extend this work although there are clearly many issues that could be
Dr. Matthew Britton
Teletraffic Research Centre
Office 5.18, Level 5, Innova21 Building, North Terrace, Adelaide
Mobile: +61 (0) 404 384 221
Landline: +61 (8) 8313 0565
yes, batman advanced (note, not the layer 3 BATMAN) supports multicast. It
behaves like a (rather lossy) Ethernet interface and transports multicast
traffic just like broadcast. For broadcast, we use a "classic flooding"
approach, which means that every message is rebroadcasted by every node
once when heard first. This "works" also for UDP multicast traffic,
but is not designed for high bandwidth multicast/broadcast data.
Linus and me are working on an optimization for multicast which is currently
in an experimental stage, which may also be better suited for your application.
However, I don't know whether LCM works on lossy networks and which bandwidth
requirements it has. Also note that the optimization is not "deployment ready"
A few pointers to get started:
Quick Start Guide: http://www.open-mesh.org/wiki/batman-adv/Quick-start-guide
First Announcement of Multicast Optimization (Specification attached):
On Thu, Mar 24, 2011 at 07:42:21PM +0000, Toupet, Olivier wrote:
> I am considering using the Lightweight Communications and Marshalling (LCM) library recently developed at MIT: http://code.google.com/p/lcm/ . However, that library relies on UDP multicast and I need it to work for mesh networks. I have only used simple UDP in the past with B.A.T.M.A.N. and I was wondering if my applications would still work with B.A.T.M.A.N. if I went with UDP multicast. Doing a little bit of research on the web seems to indicate that the UDP packets would be treated like broadcast packets and would then be flooded in the network, which doesn't seem efficient bandwidth-wise. Is that really the case? Would B.A.T.M.A.N. work with LCM (i.e. UDP multicast)? Is there documentation that explains how to set up B.A.T.M.A.N. for UDP multicast?
> Thanks in advance for your reply.
> Best regards,
*** Google Summer of Code 2011 ***
Since last Monday the student application period for the Google
Summer of Code 2011 has opened. A chance for any student to get
their hands dirty on their favorite OpenSource project and getting
its development process and code base to know better during these
2 months - while getting payed for it! And guess what? This year,
you can play with Batman - ehh, B.A.T.M.A.N. Anyways, they both
want to save the world of course ;).
As the application of OpenMesh as a mentoring organization was
sadly rejected last year, we decided and agreed on applying via
Freifunk this year, which serves as an umbrella organization for
various projects dealing with wireless mesh networks.
If you are interested in mesh networking and B.A.T.M.A.N. and if
you also love OpenSource software and would like to become a more
firm part of it, then get in touch with us via mailinglist and/or
IRC. So far the following ideas have been collected which you may
But feel free to tell us your own suggestions and ideas, too.
*** Student application deadline is the 8th of April!! ***
- GSoC timeline:
- Student Check List:
- Freifunk GSoC Page:
The B.A.T.M.A.N. team
On Sat, Mar 26, 2011 at 06:45:48PM +0100, Andrew Lunn wrote:
> > I think it is wrong: TQ is not decremented by hop_penalty each time, but it is
> > multiplied by (TQ_MAX-hop_penalty/TQ_MAX), then the number of hops is
> > bigger than what you said. With hop_penalty = 10 we can probably reach
> > ~135 hops (raw calculus 255*(TQ_MAX-hop_penalty/TQ_MAX)^135) =~ 0)
> I agree with the principle. However, you need to take rounding into
> effect. The kernel does integer arithmetic and TQ is always an integer
> value. I also got it wrong in my last post. I used the wrong round
> function when calculating the values. Using rounddown() i get:
> After 73 hops, TQ will be zero.
You are right, my raw calculus was too raw :p
> > Looking at the calculus above, I'm proposing to use TTL = ~135
> TTL of 73 would be more accurate i think.
> Which leads me to a new question. At WBM we talked about moving the
> HNAs out of the OGMs. If we had a really big mesh, with more than 73
> hops from side to side, do we get into a situation where we have HNAs
> from more than 73 hops away, but no idea how to route to them since
> OGMs got dropped when TQ reached 0?
Mh..The HNA request is triggered by the TTVN carried into the OGM. Then a node
far more than 73 hops should never ask for HNAs it cannot reach..
Moreover, a route toward a client is never allocated if we don't have
its orig_node in our DB.
..each of us alone is worth nothing..
Ernesto "Che" Guevara
On sab, mar 26, 2011 at 04:31:42 +0100, Marek Lindner wrote:
> > In these days I was wondering whether the TTL field in the OGM packet is
> > really useful or not...Due to hop_penalty an OGM will be discarded as
> > soon as the TQ will reach 0 (which is a sort of TTL mechanism itself).
> > At this point why is the TTL field needed?
> uhm.., you probably are right. As long as there is a hop penalty it also
> functions as a TTL. Keep in mind that it is possible to set the hop penalty to
> zero. With the current default hop penalty of 10 the maximum number of hops is
> limited to 25.
I think it is wrong: TQ is not decremented by hop_penalty each time, but it is
multiplied by (TQ_MAX-hop_penalty/TQ_MAX), then the number of hops is
bigger than what you said. With hop_penalty = 10 we can probably reach
~135 hops (raw calculus 255*(TQ_MAX-hop_penalty/TQ_MAX)^135) =~ 0)
> > Someone could probably say that a node far at least TTL hops will never
> > be reached by a unicast packet, then it is meaningless to let it know
> > about me. But then it could be possible to recalibrate the TTL such that
> > it has to be equal to the maximum length in number of hops of the longest
> > path the OGM can traverse.
> Not quite sure what you are proposing. A TTL of TQ_MAX / hop penalty ?
Looking at the calculus above, I'm proposing to use TTL = ~135
..each of us alone is worth nothing..
Ernesto "Che" Guevara