Re: Question regarding minstrel(_ht) and retry limits

[Simon Wunderlich <simon.wunderlich@s2003.tu-chemnitz.de>]

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

Hey Felix,

On Thu, Mar 07, 2013 at 04:47:40PM +0100, Felix Fietkau wrote:
> On 2013-03-07 4:31 PM, Simon Wunderlich wrote:
> > Hello list,
> > 
> > as you might be aware, it is possible to set short and long retry limits
> > to specify how often a frame should be retransmitted before getting dropped.
> > 
> > However, it appears that minstrel completely ignores any retry limit, and it is
> > also not applied later in the code path. I've hacked minstrel_ht a little bit
> > to apply the retry limits in minstrel_get_rate() before returning the rates
> > (i.e. just cutting retries at the end from the struct ieee80211_tx_rate array).
> > 
> > This worked for me, but is probably not clean either and might disturb minstrel
> > operation. Also minstrel uses much more retries than default retry limits
> > (short: 7, long: 4), so this patch might introduce behaviour changes.
> > 
> > What is your opinion on this? Can we get it properly supported? Does it hurt
> > to just use the first $retry_limit retries, and cut the rest at other rates
> > at the end?
> I think simply cutting off from the end of the retry chain is a bad idea
> - if there are too many scheduled retries in the max throughput rate, it
> will not make it to the fallback to a reliable rate if that fails. A
> better approach is to make minstrel use fewer retries per rate.
> 
> - Felix
> 

Are there any theoritical constraints to consider? I don't know too much
about minstrel theory, but from what I understand:

The ieee80211_tx_rate array has 4 entries with rate + count number, where
the last entries may be empty (count = 0).

Would you suggest to decrease the count numbers of each array entry uniformly
to meet the limit requirement? From what I've seen, minstrel assigns more than
7 tries in total quite often - will it be problematic if we decrease the count
number uniformally? And finally, is there any more elegant way than adjusting
to the limits just before returning and after minstrel made all its choices?
This is how I've implemented the cutting as described above, but it appears
that there are some limits in minstrel too ... not sure if they can be used
to enforce the total count limit though. :)

Thanks,
	Simon

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]