From: "Martin Hundebøll" <martin@hundeboll.net>
To: cmsv@wirelesspt.net,
The list for a Better Approach To Mobile Ad-hoc Networking
<b.a.t.m.a.n@lists.open-mesh.org>
Subject: Re: [B.A.T.M.A.N.] Network coding multi-hop bandwidth loss
Date: Wed, 12 Mar 2014 10:16:15 -0700 [thread overview]
Message-ID: <5320965F.1030900@hundeboll.net> (raw)
In-Reply-To: <5313B316.701@wirelesspt.net>
[-- Attachment #1: Type: text/plain, Size: 1683 bytes --]
Hi cmvs,
Thanks for testing NC.
On 2014-03-02 14:39, cmsv wrote:
> I just found out /(the hard way) that using network coding (batman-adv
> 2013.4) that i have a massive, unbelievable bandwidth loss if i have
> more than one hop to the destination
>
> I tested this in a real scenario with 11 nodes as well as 3 nodes in a
> house with 3 floors and having one per each floor.
>
> Here is the example with 3 nodes
>
> A <------ B -----> C
>
> From node B to iperf reports me 15 mbit
> From node B to node C iperf reports me 9 mbit
>
> Then, from node C to node A i get values bellow 1 mbit such as 647kbits
> or less.
> More than 3 nodes is to forget.
>
> uci set batman-adv.bat0.network_coding=0 disables nc and solved the
> problem which brought the network bandwidth to a more realistic and
> mathematical acceptable bandwidth level.
>
> Is this finding known by others ?
Have you verified that both node A and C have working promiscuous mode?
One way to do this is to transmit udp packets from B to A with iperf and
count the number of received packets on C with tcpdump.
In addition, you should note that NC doesn't bring a gain for
unidirectional flows, so even though TCP sends ACKs in the reverse
direction, the gain is probably eaten up by the delay added by node B,
in order to increase the chance of coding opportunities.
When you have verified the working promisc mode, can you repeat the test
and tell us the results?
And also test with two TCP flows: A -> C and C -> A ?
Thanks!
--
Kind Regards
Martin Hundebøll
Frederiks Allé 99, 1.th
8000 Aarhus C
Denmark
+45 61 65 54 61
martin@hundeboll.net
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
prev parent reply other threads:[~2014-03-12 17:16 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CANHt3YGgN754sR4V2v0jpgMoTSSg0OVmGMOTRQ3zrF8dS5mA_Q@mail.gmail.com>
2014-03-02 22:39 ` [B.A.T.M.A.N.] Network coding multi-hop bandwidth loss cmsv
2014-03-12 17:16 ` Martin Hundebøll [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5320965F.1030900@hundeboll.net \
--to=martin@hundeboll.net \
--cc=b.a.t.m.a.n@lists.open-mesh.org \
--cc=cmsv@wirelesspt.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox