From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path:
References: <2791173.mX5NbDZpiX@sven-edge>
<733b64f0.dcd9.1658f661fb2.Coremail.heishuihe2008@163.com>
<3991773.ZLWj8GO7DM@bentobox> <2087861.tpEfN19RDO@rousseau>
From: Antonio Quartulli
Message-ID: <68a21394-e8ac-2fb1-2132-901ea4c0e610@unstable.cc>
Date: Sat, 1 Sep 2018 17:33:35 +0800
MIME-Version: 1.0
In-Reply-To: <2087861.tpEfN19RDO@rousseau>
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature";
boundary="gNoBe1zGKGDUQ9vVNoAXw53OVHwJgnIMe"
Subject: Re: [B.A.T.M.A.N.] Recent test result. Re:Re: Paper "Performance
Evaluation of BATMAN-adv Wireless Mesh Network Routing Algorithms "
List-Id: The list for a Better Approach To Mobile Ad-hoc Networking
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
To: Ligang LIU
Cc: The list for a Better Approach To Mobile Ad-hoc Networking , Marek Lindner
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--gNoBe1zGKGDUQ9vVNoAXw53OVHwJgnIMe
Content-Type: multipart/mixed; boundary="QWgHZWxp3w881JsFg5ENUt6blIVgorAfN";
protected-headers="v1"
From: Antonio Quartulli
To: Ligang LIU
Cc: The list for a Better Approach To Mobile Ad-hoc Networking
, Marek Lindner
Message-ID: <68a21394-e8ac-2fb1-2132-901ea4c0e610@unstable.cc>
Subject: Re: [B.A.T.M.A.N.] Recent test result. Re:Re: Paper "Performance
Evaluation of BATMAN-adv Wireless Mesh Network Routing Algorithms "
References: <2791173.mX5NbDZpiX@sven-edge>
<733b64f0.dcd9.1658f661fb2.Coremail.heishuihe2008@163.com>
<3991773.ZLWj8GO7DM@bentobox> <2087861.tpEfN19RDO@rousseau>
In-Reply-To: <2087861.tpEfN19RDO@rousseau>
--QWgHZWxp3w881JsFg5ENUt6blIVgorAfN
Content-Type: text/plain; charset=windows-1252
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Hi,
On 31/08/18 20:16, Marek Lindner wrote:
> On Friday, 31 August 2018 18:30:00 HKT Sven Eckelmann wrote:
>>> I noticed 2 macro definitons.
>>> #define BATADV_ELP_PROBES_PER_NODE 2
>>> #define BATADV_ELP_MIN_PROBE_SIZE 200 /* bytes */
>>> I wonder why it sends 2 prob ELP packets to each neighbour.
>>> Can I change the value of BATADV_ELP_PROBES_PER_NODE from 2 to 1?
>>> And can I decrease ELP prob packet size from 200 to 100, in order to
>>> decrase the ELP airtime?
>> @Antonio, @Marek: Maybe you can explain it better than me.
>>
>> I would guess that Antonio wanted to make sure that the rate control
>> algorithm of the driver probes enough and thus provides a more realist=
ic
>> expected throughput.
>=20
> Feel free to change these values to test if this has any impact. As far=
as I=20
> am aware, these number are the result of an educated guess based on how=
=20
> minstrel works. Antonio can shed more light on this.
As Marek stated above, these constants are defined so that Minstrel has
always enough samples to trigger a throughput re-computation for every
ELP interval.
If less data is available, Minstrel won't compute a fresh expected
throughput.
Therefore after every ELP interval batman-adv checks if during the last
100ms (BATADV_ELP_PROBE_MAX_TX_DIFF) the node had sent any payload data
to a given neighbour. If not, then it will send the unicast probes.
This means that if you already have enough data over the link, no
unicast ELP messages should be sent (thus these constants won't be used).=
To conclude: if you have no data over the link, sending 2 probes of
200bytes each every 500ms (default ELP interval) won't really eat much
airtime, unless you have a lot of idling 1-hop neighbours.
I hope this helps.
Cheers,
--=20
Antonio Quartulli
--QWgHZWxp3w881JsFg5ENUt6blIVgorAfN--
--gNoBe1zGKGDUQ9vVNoAXw53OVHwJgnIMe
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEERdCuyFSHc3WdqS4EB6U8WA7yzXQFAluKXPMACgkQB6U8WA7y
zXT5gA/+PvP7Ut4R36X7CZ3zUuMqpTtUKxmqL1sF6E9+ZXPg/jrReeyQlaRZ4o+h
iqcg/OQ8T61j77bEzUPTsrvweE3Dbw23Yw1nnV0pxw9RdBKekCPnUSdCxpRUPIxq
hsjxOoHuDtBclpzI5ko58xX5qeszMfvBKv04gYTCMUsh00dqJ5rqaTjkjjdD8bII
FCxi/IHLz7qH1ytBamsdQ6fKP/7dIMVNkErCP8xgu8aUXCv+POFd8TJ3wpWxLtQN
1KFALcJpoKB2+AQcjekHMEoo6GBHWSwsVE0KD34OSkcpEWDwofpWjJn5dM6gUTqc
hSHypTJ8W8dEi9I/Tp6yuWBVvc9VgPzsL5gIbHRImd7cldCLDExxSmiaWU/06LnA
C0QXe193MBGo4mjG4wgaxiFDwflOXIzn0hGqYmK3f1Q3Skh5WmIn2PkEBdr/NyO+
O7YC9gytXQ3VuXhGb9F3APIbMyU2bgMwJyo07K63t2Dd+oE3GAaEj/QBno6dyIZh
XWL6qnSA3LCI+Hc3PZpuSthp5/vDXpp56WKYVmL17JATPKCnIMjalkQUOwVgvALl
LG+0GlcKc4VxeLaBycn6GOnlzQvhGSJ5LJow/4Xbt1pFJa9O1LHn1w/A/PWdZTaD
HOfrtOHZJFAdyGKLR+dFS2jtXe5xZcAsuiCc8rY4q4IwoxivkCA=
=D5jm
-----END PGP SIGNATURE-----
--gNoBe1zGKGDUQ9vVNoAXw53OVHwJgnIMe--