B.A.T.M.A.N April 2012

b.a.t.m.a.n@lists.open-mesh.org

25 participants
63 discussions

[B.A.T.M.A.N.] [PATCH] batctl: Changed the wrong option in log level that was, showing arp as and option where it should be dat
by Xabier R B 04 Apr '12

04 Apr '12

Signed-off-by: Xabier Rodriguez <xrb(a)kalrong.net> --- sys.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sys.c b/sys.c index e0dcb07..d3bf7fa 100644 --- a/sys.c +++ b/sys.c @@ -257,7 +257,7 @@ int handle_loglevel(char *mesh_iface, int argc, char **argv) printf("[%c] %s (%s)\n", (log_level & 8) ? 'x' : ' ', "messages related to bridge loop avoidance", "bla"); printf("[%c] %s (%s)\n", (log_level & 16) ? 'x' : ' ', - "messages related to the distributed arp table", "arp"); + "messages related to the distributed arp table", "dat"); out: free(path_buff); -- 1.7.9.1

2 1

[B.A.T.M.A.N.] new batman-adv maintainer
by Marek Lindner 02 Apr '12

02 Apr '12

David, I'd like to let you know that Antonio is going to replace me as linux kernel integrator. He has been active in our project for more than 2 years and closely follows the kernel development. Sven and I are still going to be around to help whenver there are questions or problems to discuss. Thanks, Marek

2 1

[B.A.T.M.A.N.] any throughput mechanism or plans?
by dan 02 Apr '12

02 Apr '12

I can't see anything in my reading on this. Is there a mechanism to identify throughput between two nodes? or between a client and a destination for the purpose of routing through the highest throughput path? For instance, track the maximum throughput on each interface over time. Compare it to the current throughput on the interface and send what is leftover as 'available throughput' with the TQ each node. Now instead of adding up the numbers as with TQ, just take the min. Take the lowest throughput along the path and have a node be able to utilize the highest throughput path that has acceptable TQ. As a node's interface gets loaded up (vs observed maximum) it will inform it's neighbors in the same way it informs them of the TQ of each interface and then the neighbors can choose to route around if there is a good alternate path. Basically, I'm thinking that TQ isn't the only or most optimal way to route simply because available throughput should be considered somehow. As far as I can tell, a 56k link with .001% packet loss is better than a 54Mb link with .1% packet loss, though both are solid interfaces and the 54Mb link should be prefered heavily over the 56k link. The 56k link probably will start dropping packets once it is saturated, but one client might run up against slow ACKs keeping the remote server from sending enough data to saturate the connection so the client could be getting a very slow connection while a 54Mb link sits virtually unused.

5 12

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

B.A.T.M.A.N April 2012