linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Felix Fietkau <nbd@openwrt.org>
To: "Björn Smedman" <bjorn.smedman@venatech.se>
Cc: linux-wireless <linux-wireless@vger.kernel.org>,
	Derek Smithies <derek@indranet.co.nz>,
	Benoit PAPILLAULT <benoit.papillault@free.fr>,
	"Luis R. Rodriguez" <lrodriguez@atheros.com>,
	Christian Lamparter <chunkeey@googlemail.com>,
	Johannes Berg <johannes@sipsolutions.net>,
	ath9k-devel@lists.ath9k.org
Subject: Re: [RFC/RFT] minstrel_ht: new rate control module for 802.11n
Date: Wed, 23 Jun 2010 21:27:26 +0200	[thread overview]
Message-ID: <4C22601E.5050101@openwrt.org> (raw)
In-Reply-To: <AANLkTilDTZRUk_3iI5NPX0JhqG7N8LtKcE3VSSnqFGk9@mail.gmail.com>

On 2010-06-23 8:47 PM, Björn Smedman wrote:
> 2010/6/23 Felix Fietkau <nbd@openwrt.org>:
>> On 2010-06-23 6:36 PM, Björn Smedman wrote:
> [snip]
>>> If I'm not wrong above then the rate control feedback must also be
>>> incorrect: a disaster of that magnitude simply cannot be conveyed to
>>> the rate control algorithm through the thin tx status interface. As
>>> far as I can tell, whenever the first subframe of an aggregate fails
>>> and is software retried, the rate control feedback for that aggregate
>>> is lost (ath_tx_rc_status() is never called with update_rc = true in
>>> xmit.c).
>> I think you misread that part. The loop iterates over all subframes in
>> the aggregate, and the first successful or swretry-expired frame will
>> trigger an AMPDU status report, which will update the RC. The first
>> subframe of the A-MPDU is not getting any special treatment here.
> 
> You're right, I missed that part. And I guess that's also why the
> worst case is so rare.
> 
> But on the other hand doesn't that also mean that MRR rates and counts
> in the tx status will be incorrect? I.e. one set of rates/counts used
> to transmit the aggregate (first subframe) and (possibly) another set
> reported back in tx status (first acked/expired subframe)?
No, MRR info is just fine. The retry stats are reported for the whole
A-MPDU, not for indvididual subframes. It's always present in the last
descriptor of the whole batch. Also, since my code cleanup a while ago,
the converted rx/tx status info is not longer part of the allocated
descriptor space, but instead kept on stack in the function that
processes the tx status. This on stack tx status is then passed to the
rc update function, which sends the data to mac80211 along with the
AMPDU tx status report.

> Also, bf->bf_retries is used in ath_tx_rc_status() but the logic makes
> no sense if bf_retries holds the number of software retries...
Hmm, that part might indeed be buggy. I'll review it in detail when I'm
at home again.

- Felix

  reply	other threads:[~2010-06-23 19:27 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-01 22:05 [RFC/RFT] minstrel_ht: new rate control module for 802.11n Felix Fietkau
2010-03-01 22:38 ` Derek Smithies
2010-03-01 22:58   ` Felix Fietkau
2010-03-01 23:04     ` Derek Smithies
2010-03-02 12:19 ` Björn Smedman
2010-03-02 14:51   ` Felix Fietkau
2010-03-02 15:47     ` Björn Smedman
2010-03-02 16:14       ` Felix Fietkau
2010-06-23 16:36         ` Björn Smedman
2010-06-23 17:07           ` Felix Fietkau
2010-06-23 18:47             ` Björn Smedman
2010-06-23 19:27               ` Felix Fietkau [this message]
2010-06-23 23:56                 ` Björn Smedman
2010-06-28  0:01             ` Björn Smedman
2010-06-28  0:12               ` Felix Fietkau
2010-06-28 10:20                 ` Björn Smedman
2010-06-28 10:27                   ` Felix Fietkau
2010-03-02 21:55       ` Derek Smithies
2010-03-04 14:12         ` Bob Copeland
2010-03-04 16:40           ` Björn Smedman
2010-03-04 20:11             ` Derek Smithies

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=4C22601E.5050101@openwrt.org \
    --to=nbd@openwrt.org \
    --cc=ath9k-devel@lists.ath9k.org \
    --cc=benoit.papillault@free.fr \
    --cc=bjorn.smedman@venatech.se \
    --cc=chunkeey@googlemail.com \
    --cc=derek@indranet.co.nz \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=lrodriguez@atheros.com \
    /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).