Re: [B.A.T.M.A.N.] batman-adv bonding feature - unable to get data packets fragmented into multiple wireless interfaces

Re: [B.A.T.M.A.N.] batman-adv bonding feature - unable to get data packets fragmented into multiple wireless interfaces

[Simon Wunderlich]

Hello Syed,

thanks for testing.

Please don't send HTML mails to the mailing list, they will get rejected.

Thank you
    Simon

On Monday 13 October 2014 08:26:59 syedmoulana47 wrote:
> I am using batman-adv: 2012.5.0. I tried with version 2014.3.0 also.
> 
> Even without enabling bonding sometimes I can see simultaneous outbound udp
> traffic in both interfaces wlan0 and wlan1.
> 
> I will try with the patch and update.
> 
> Thanks.
> 
> Sent from my Xiaomi
> 
> On 11 Oct 2014 03:03, Simon Wunderlich <sw@simonwunderlich.de> wrote:
> Hey Syed,
> 
> which version of batman-adv are you using?
> 
> Please note there is a fix for a bonding problem which hasn't been merged
> yet, 
 please merge it manually for your tests (assuming you are using a
> recent version)
> 
> https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2014-August/012382.html
> 
> Also bonding has nothing to do with fragmentation - the idea of bonding is 
> that the packets should not be split, but get sent interleaved over the
> interfaces, e.g.
> 
> * wlan 1 - packet 1
> * wlan 2 - packet 2
> * wlan 1 - packet 3
> * wlan 2 - packet 4
> * etc ...
> 
> To have a real gain from that, the two links must be equally good quality. 
> Also deep queues in the driver may cause reordering of packets which will
> upset TCP. The best results I've seen in the past were 50% performance gain
> over a single link, but I didn't try it out in real world scenarios lately.
> 
> Thanks,
>     Simon
> On Tuesday 07 October 2014 17:27:50 syed moulana wrote:
> 
> > hi
> > 
> > I tested the throughput between point to point mesh nodes using single
> > and 2 radios.
> > 
> > 1.  Using single radio (ch 5180)  the resulting throughput for HT40+
> >
> >            TCP max 250mbit/s
> >            UDP - max 320mbit/s
> >
> > 
> > 2. Using 2 radios with and without batctl bonding enabled (ch 5180 for
> > wlan0, ch 5785 for wlan1), the resulting throughput for HT40+ is same.
> >
> >            with batctl bonding and fragmentation enabled I believed I
> >
> > should be getting 50% gain in througput.
> >
> >     When I monitor the wlan0 and wlan1 interfaces using batctl tcpdump
> >
> > -p 4 wlanx I can see that iperf data are interleaved.
> >
> >     There is no splitting of data frames into 2 wireless interfaces.
> >
> > 
> > Please advice
> > 
> > Tq
> > 
> > Syed

[B.A.T.M.A.N.] batman-adv bonding feature - unable to get data packets fragmented into multiple wireless interfaces

[syed moulana]

hi

I tested the throughput between point to point mesh nodes using single
and 2 radios.

1.  Using single radio (ch 5180)  the resulting throughput for HT40+
           TCP max 250mbit/s
           UDP - max 320mbit/s

2. Using 2 radios with and without batctl bonding enabled (ch 5180 for
wlan0, ch 5785 for wlan1), the resulting throughput for HT40+ is same.
           with batctl bonding and fragmentation enabled I believed I
should be getting 50% gain in througput.
    When I monitor the wlan0 and wlan1 interfaces using batctl tcpdump
-p 4 wlanx I can see that iperf data are interleaved.
    There is no splitting of data frames into 2 wireless interfaces.

Please advice

Tq

Syed

Re: [B.A.T.M.A.N.] batman-adv bonding feature - unable to get data packets fragmented into multiple wireless interfaces

[Simon Wunderlich]

Hey Syed,

which version of batman-adv are you using?

Please note there is a fix for a bonding problem which hasn't been merged yet, 
please merge it manually for your tests (assuming you are using a recent 
version)

https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2014-August/012382.html

Also bonding has nothing to do with fragmentation - the idea of bonding is 
that the packets should not be split, but get sent interleaved over the 
interfaces, e.g. 

 * wlan 1 - packet 1
 * wlan 2 - packet 2
 * wlan 1 - packet 3
 * wlan 2 - packet 4
 * etc ...

To have a real gain from that, the two links must be equally good quality. 
Also deep queues in the driver may cause reordering of packets which will 
upset TCP. The best results I've seen in the past were 50% performance gain 
over a single link, but I didn't try it out in real world scenarios lately.

Thanks,
    Simon
On Tuesday 07 October 2014 17:27:50 syed moulana wrote:
> hi
> 
> I tested the throughput between point to point mesh nodes using single
> and 2 radios.
> 
> 1.  Using single radio (ch 5180)  the resulting throughput for HT40+
>            TCP max 250mbit/s
>            UDP - max 320mbit/s
> 
> 2. Using 2 radios with and without batctl bonding enabled (ch 5180 for
> wlan0, ch 5785 for wlan1), the resulting throughput for HT40+ is same.
>            with batctl bonding and fragmentation enabled I believed I
> should be getting 50% gain in througput.
>     When I monitor the wlan0 and wlan1 interfaces using batctl tcpdump
> -p 4 wlanx I can see that iperf data are interleaved.
>     There is no splitting of data frames into 2 wireless interfaces.
> 
> Please advice
> 
> Tq
> 
> Syed

Re: [B.A.T.M.A.N.] batman-adv bonding feature - unable to get data packets fragmented into multiple wireless interfaces

[Ray Gibson]

On Fri, Oct 10, 2014 at 12:03 PM, Simon Wunderlich
<sw@simonwunderlich.de> wrote:
> https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2014-August/012382.html

Previously rejected, trying again, not from mobile device this time!

Related to this, I had some great success testing the patches in my
experimental VM setup but have not yet had a chance to test in real
world conditions.

Simon, I did want to note that watching ifstat on iperf testing with
batman-adv sitting on top of two equally matched Ethernet adapters
split the outgoing traffic fantastically, though the
response/ack/whatever packets to that session consistently came in on
a single adapter that occasionally bounced around, much like what the
sending traffic was doing previously.  I would imagine the other side,
running on the same software, should have equally split that traffic
as well.

Thanks,

Ray