linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Karl Beldan <karl.beldan@gmail.com>
To: Simon Wunderlich <simon.wunderlich@s2003.tu-chemnitz.de>
Cc: linux-wireless@vger.kernel.org, nbd@openwrt.org,
	thomas@net.t-labs.tu-berlin.de, johannes@sipsolutions.net,
	Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
Subject: Re: Question regarding minstrel(_ht) and retry limits
Date: Thu, 7 Mar 2013 20:10:18 +0100	[thread overview]
Message-ID: <20130307191018.GA13138@gobelin> (raw)
In-Reply-To: <20130307181405.GB31210@pandem0nium>

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

  reply	other threads:[~2013-03-07 19:09 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-07 15:31 Question regarding minstrel(_ht) and retry limits Simon Wunderlich
2013-03-07 15:40 ` Karl Beldan
2013-03-07 18:14   ` Simon Wunderlich
2013-03-07 19:10     ` Karl Beldan [this message]
2013-03-07 15:47 ` Felix Fietkau
2013-03-07 18:06   ` Simon Wunderlich
2013-03-07 21:32     ` Bob Copeland

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130307191018.GA13138@gobelin \
    --to=karl.beldan@gmail.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=mathias.kretschmer@fokus.fraunhofer.de \
    --cc=nbd@openwrt.org \
    --cc=simon.wunderlich@s2003.tu-chemnitz.de \
    --cc=thomas@net.t-labs.tu-berlin.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).