Re: [B.A.T.M.A.N.] [RFC 15/23] batman-adv: ELP - send unicast ELP packets for throughput sampling

[Antonio Quartulli <antonio@meshcoding.com>]

[-- Attachment #1: Type: text/plain, Size: 1771 bytes --]

On 13/02/14 10:55, Andrew Lunn wrote:
>>> Right. If I remember correctly, if you send less than 1 packet per 100
>>> ms, then all packets should end up being probing packets. If that
>>> doesn't work, we can change minstrel's probing pattern to allow things
>>> like batman to get a desirable amount of rate control probing simply by
>>> sending unicast packets.
>>
>> This is what I am trying to achieve here: if no unicast packets have
>> been sent for the last 100ms (at least) then send N probing packets in a
>> row (with N = 2 at the moment - it is a define in main.h).
> 
> Hi Antonio
> 
> One minor thing to consider is that your statement is actually:
> 
> if no _batman_ unicast packets have been sent for the last 100ms ...
> 
> I've used batman in setups where it has not been the exclusive user of
> the hard interface. So there could be other traffic which is keeping
> the RC algorithm up to date. So maybe it would be better to use the
> hard interface statistic counters rather than last time batman sent a
> packet?

We can't use the hard_iface statistics because we need to know where
that traffic has been sent to.
The same interface might connected to several neighbours and the rates
are selected/probed on a per-peer base.

However, to go in the direction that you are suggesting, I could use the
same API I use to read the throughput (cfg80211_get_station()) to also
read when the last packet was sent to a given peer.
This information should be good for our purposes, but it means that we
probe the neighbours right after having read the throughput.

This should not be a problem because as we said in a previous email we
do not require real time throughput updates.


Cheers,


-- 
Antonio Quartulli


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]