From: Sven Eckelmann <sven@narfation.org>
To: Ligang LIU <heishuihe2008@163.com>
Cc: b.a.t.m.a.n@lists.open-mesh.org, a@unstable.cc,
mareklindner@neomailbox.ch
Subject: Re: [B.A.T.M.A.N.] Recent test result. Re:Re: Paper "Performance Evaluation of BATMAN-adv Wireless Mesh Network Routing Algorithms "
Date: Sat, 01 Sep 2018 11:08:45 +0200 [thread overview]
Message-ID: <3277849.7XWcqIUx8F@sven-edge> (raw)
In-Reply-To: <3991773.ZLWj8GO7DM@bentobox>
[-- Attachment #1: Type: text/plain, Size: 1041 bytes --]
On Freitag, 31. August 2018 12:30:00 CEST Sven Eckelmann wrote:
> Especially because this frame will now be dropped over some interfaces. We
> already saw this in the past with fragmented frames [1]. You can increase the
> size in batadv_v_elp_iface_enable by adding the number x to the alloc and the
> skb_put. For example 44 to get to the minimum ethernet frame size:
>
> hard_iface->bat_v.elp_skb = dev_alloc_skb(size + 44);
> ...
> elp_buff = skb_put_zero(hard_iface->bat_v.elp_skb, BATADV_ELP_HLEN + 44);
Just as clarification: This should not be relevant for your problem. It was
just observed that the ELP [0] documentation talks about more padding. The
underlying driver is usually only adding extra padding when required (e.g. 60
bytes ethernet).
More relevant here would be whether the duration in the RTS/CTS frames look
odd. Or what else prevents the devices in your six node setup from sending
between each other.
Kind regards,
Sven
[0] https://www.open-mesh.org/projects/batman-adv/wiki/ELP#section-9
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2018-09-01 9:08 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-04 11:38 [B.A.T.M.A.N.] Paper "Performance Evaluation of BATMAN-adv Wireless Mesh Network Routing Algorithms " Sven Eckelmann
2018-08-04 14:39 ` jmh8
2018-08-04 15:34 ` Sven Eckelmann
2018-08-11 6:47 ` jmh8
[not found] ` <2018081310240755548768@mail.sim.ac.cn>
2018-08-13 7:40 ` Sven Eckelmann
2018-08-30 7:50 ` [B.A.T.M.A.N.] Recent test result. " Ligang LIU
2018-08-30 8:17 ` Sven Eckelmann
2018-08-30 8:55 ` Ligang LIU
2018-08-30 9:06 ` Sven Eckelmann
2018-08-31 9:52 ` Ligang LIU
2018-08-31 10:30 ` Sven Eckelmann
2018-08-31 10:41 ` Sven Eckelmann
2018-08-31 12:16 ` Marek Lindner
2018-09-01 9:33 ` Antonio Quartulli
2018-09-01 9:08 ` Sven Eckelmann [this message]
2018-09-03 4:03 ` [B.A.T.M.A.N.] mcast_rate setting of wifi interface has significant effect to performance of V. " Ligang LIU
2018-09-03 6:25 ` Sven Eckelmann
[not found] ` <aa797db.cdf1.165a3d64b19.Coremail.heishuihe2008@163.com>
2018-09-04 10:34 ` Sven Eckelmann
2018-09-05 17:40 ` Sven Eckelmann
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=3277849.7XWcqIUx8F@sven-edge \
--to=sven@narfation.org \
--cc=a@unstable.cc \
--cc=b.a.t.m.a.n@lists.open-mesh.org \
--cc=heishuihe2008@163.com \
--cc=mareklindner@neomailbox.ch \
/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