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?
Cheers,
Simon
On Thu, Mar 07, 2013 at 04:31:00PM +0100, 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?
>
BTW, it also ignores max_rate_tries < 3 and rts thresholds.
Karl
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
On Thu, Mar 07, 2013 at 07:06:35PM +0100, Simon Wunderlich wrote:
> 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).
>From what I understand, essentially all legacy Minstrel tries to do is
pick more transmissions for higher rates (since airtime for those will
generally be less) and then a certain base level for the minimal fallback
rate.[1]
My guess would be that it would be "better" to scale the retries by the
desired number of total retries rather than just subtracting the same
amount from each rate. I think you could do the scaling without divides.
At the least, you'd want to keep some minimal number in the base rate
slot so that it gets used if all else fails.
[1] see minstrel_rate_init(); ostensibly, it does this by trying to fit
as many retransmissions per slot that will take 6 ms on a 1200 byte
frame. It doesn't seem to account for the backoff between slots though
(it's all pre-computed per-rate), so the total tx time could be well
over 6x4=24 ms if all the retries were used. Perhaps it's worth fixing
that, too.
--
Bob Copeland %% http://www.bobcopeland.com
On Thu, Mar 07, 2013 at 04:40:45PM +0100, Karl Beldan wrote:
> On Thu, Mar 07, 2013 at 04:31:00PM +0100, 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?
> >
> BTW, it also ignores max_rate_tries < 3 and rts thresholds.
Yup, regarding RTS we had a long discussion some time ago:
* http://thread.gmane.org/gmane.linux.kernel.wireless.general/84459
regarding max_rate_tries, I guess this comes from the hardware? Does it hurt
to ignore it (as drivers will cut it anyway)?
Cheers,
Simon
On Thu, Mar 07, 2013 at 07:14:05PM +0100, Simon Wunderlich wrote:
> On Thu, Mar 07, 2013 at 04:40:45PM +0100, Karl Beldan wrote:
> > On Thu, Mar 07, 2013 at 04:31:00PM +0100, 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?
> > >
> > BTW, it also ignores max_rate_tries < 3 and rts thresholds.
>
> Yup, regarding RTS we had a long discussion some time ago:
>
> * http://thread.gmane.org/gmane.linux.kernel.wireless.general/84459
>
Yes, plus I seem to recall that there's a minstrel paper discussing
protection impact, but I would have found the thread more interesting if
it discussed enforcing protection rather than disabling it at user's
will.
> regarding max_rate_tries, I guess this comes from the hardware? Does it hurt
> to ignore it (as drivers will cut it anyway)?
>
It comes from the hardware.
Can't really say, but the topic being hot with some rate controls facing
removal and the activity around minstrel it might be interesting to be
aware of this when comparing throughputs and also the drivers ampdu
stats reports which hugely affect minstrel.
Karl
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