On 12/02/14 13:54, Felix Fietkau wrote:
> On 2014-02-12 13:12, Antonio Quartulli wrote:
>> On 12/02/14 10:12, Andrew Lunn wrote:
>>> On Tue, Feb 11, 2014 at 01:48:15PM +0100, Antonio Quartulli wrote:
>>>> From: Antonio Quartulli <antonio@open-mesh.com>
>>>>
>>>> In case of a unused link, the throughput estimation will
>>>> get stuck to the last sampled value and therefore the
>>>> reported metric will becomes obsolete.
>>>>
>>>> Send unicast ELP packets to each neighbor to trigger throughput
>>>> sampling on unused links.
>>>
>>> Humm, i can understand the need for this, but i really think the rate
>>> control code should be sending the probes, not batman. What do the
>>> wifi people say about this? Have they tried submitting patches to
>>> them?
>>
>> I am CC'ing Felix so that he can give his opinion.
>> But last time I checked Minstrel I realised that it uses data packets to
>> probe rates (there is not a specific probing packet), meaning that if
>> there is no data packet to send, then no probing is performed.
> Correct. Minstrel never sends dedicated probing packets. Changing
> minstrel to send active probing packets to serve the needs of batman
> would be a very bad idea, because pretty much all regular users do not
> have any need for extra probing.
> 
>> Sending this ELP packets (when there is no unicast traffic) is a way to
>> trigger this mechanism in Minstrel.
> 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).


Thanks Felix!

Cheers,


-- 
Antonio Quartulli