On Thursday, 28 September 2023 18:48:20 CEST Remi Pommarel wrote:
If the direct path from Orig0 to Orig2 is better than the path over Orig1 the metric should reflect that.
In the example there is no direct path from Orig0 to Orig2, the only way for Orig2 to reach Orig0 is by going through Orig1.
If there is only one path, the computed metric does not matter at all.
If there are alternative paths (as you saying below "Orig0 and Orig2 are connected via a 100Mbps"), batman-adv has to find the best of the existing paths.
Let's say that :
- Orig0 and Orig1 are connected via a 200Mbps WiFi mesh link (mesh0)
- Orig1 and Orig2 are connected via a 110Mbps WiFi mesh link (mesh0)
- Orig0 and Orig2 are connected via a 100Mbps WiFi mesh link (mesh0)
With the current implementation the originator table of Orig2 will show something like the following:
$ batctl o Originator last-seen ( throughput) Nexthop [outgoingIF]
- Orig0-Main-Mac 0.220s ( 110) Orig1-mesh0-Mac [ mesh0 ] Orig0-Main-Mac 0.220s ( 100) Orig1-mesh0-Mac [ mesh0 ]
So best path for Orig2 to Orig0 would go through Orig1 with an expected throughput of 110Mbps. But such a throughput cannot be reached because Orig1 has to forward packet from and to the same WiFi interface.
Correct. Looking at your example where is the problem with the store & forward penalty?
Or in other words: What scenario are your patches aiming to improve?
Cheers, Marek