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.
--
Remi
