On Sat, Mar 31, 2012 at 04:22:06 -0600, dan wrote:
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.
Hello Dan,
there is not such mechanism in batman-adv right now. It is a really good idea and we already started to think about that during WBMv5. Personally, I'm applying to the GSOC2012 and I'm proposing something similar.
I also think that packet loss is not the correct way to go.
Regarding your idea, how would you measure the maximum throughput?
Cheers,