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,