On Tue, Oct 03, 2023 at 11:06:45PM +0200, Marek Lindner wrote:
On Thursday, 28 September 2023 21:16:36 CEST Remi Pommarel wrote:
$ 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?
The problem is that the wrong path is selected.
The best one should be the direct one. Because going through Orig1, 110Mbps would never be bereached due to the store & forward penalty on Orig1 and the real throughput will be below the direct path (around 80Mbps).
To summarize the problem you see: A path traversing a half duplex node might not be penalized enough when the weaker throughput link lies before a stronger throughput link because the half duplex penalty is not be applied before the packet is forwarded.
Yes, in fact currently it is even not penalized at all. This is what the first patch proposes to fix.
This issue could also be looked at from a different angle, which is maybe more convincing.
Let's say there is the following setup:
sta1 <-------> AP <---------> sta2 275Mbps 720Mbps
Then the BATMAN_V current routing algorithm is going to compute the following:
- a 275Mbps path towards sta2 on sta1 - a 137.5Mbps path towards sta1 on sta2
IMO, there is no real reason to have such an asymetry.
While the first patch fixes this asymetry by estimating both paths to be 137.5Mbps, the second patch is a proposition for a better throughput estimation.
The underlying assumption is that this indeed is an issue in terms of (measurable) throughput. Are there any numbers / papers / experiments you are basing this on? Is the store & forward throughput limit determined by the throughput of the weakest link?
I haven't found any paper on that matter, if you have one that shows that dividing by two is a sound estimation I would be genuinely interessted though.
However to support the theory of the second patch I did run some iperf3 tests on the setup above.
Results from iperf3 measurements:
- sta1 --> AP : 275Mbps - AP --> sta1 : 221Mbps
- AP --> sta2 : 720Mbps - sta2 --> AP : 704Mbps
- sta1 --> sta2 : 193Mbps - sta2 --> sta1 : 152Mbps
The sta* --> AP and AP --> sta* asymetry comes from the different WiFi hardwares characteristics (i.e. AP WiFi card is better at TX than RX).
Now let say that B.A.T.M.A.N-Adv has perfect throughput estimation for direct neighbour links (e.g. sta1 <--> AP and sta2 <--> AP).
Here are the path throughput estimations with different methods for sta1 <--> sta2.
Estimation from current B.A.T.M.A.N-adv BATMAN_V: - sta1 --> sta2 : 137.5Mbps - sta2 --> sta1 : 221Mbps
Estimation with Patch 1: - sta1 --> sta2 : 137.5 Mbps - sta2 --> sta1 : 110.5 Mbps
Estimation with both patches: - sta1 --> sta2 : 199Mbps - sta2 --> sta1 : 168Mbps
I have created a NS3 simulation test [0] that also seems to show the proposed throughput estimation is a closer estimation most of the time.
Here is an example output of this simulation:
$ ns3-dev-wifi-duplex-penalty-default --pos=10 NS3 simulated throughput sta2 ---> AP: 156.321 Mbit/s NS3 simulated throughput AP ---> sta1: 323.139 Mbit/s NS3 simulated throughput sta2 --> sta1: 102.888 Mbit/s Current BATMAN_V estimated throughput sta2 --> sta1: 156.321 Mbit/s Patch 1 estimated throughput sta2 --> sta1: 78.1603 Mbit/s Both patches estimated throughput sta2 --> sta1: 105.355 Mbit/s
[0]: http://ix.io/4IG4
Anyway thanks a lot for your time.