Lets make wifi fast again!
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@toke.dk>
To: Adrian Chadd <adrian@freebsd.org>
Cc: "linux-wireless\@vger.kernel.org"
	<linux-wireless@vger.kernel.org>,
	make-wifi-fast@lists.bufferbloat.net,
	ath9k-devel <ath9k-devel@lists.ath9k.org>
Subject: Re: [Make-wifi-fast] [RFC/RFT 5/5] ath9k: Count RX airtime in airtime deficit
Date: Wed, 08 Jun 2016 15:06:26 +0200	[thread overview]
Message-ID: <87eg87q17x.fsf@toke.dk> (raw)
In-Reply-To: <CAJ-VmonOKjeY5uLeKFOVGmdBmm1V37TH72avf4XNe=-884Szwg@mail.gmail.com> (Adrian Chadd's message of "Tue, 7 Jun 2016 18:41:19 -0700")

Adrian Chadd <adrian@freebsd.org> writes:

> Right. In the case of RX'ing an A-MPDU, we only get told about the
> A-MPDU boundaries (isaggr/lastaggr or something in the RX descriptor)
> but nothing telling us how long the original RX'ed PPDU is.
>
> So if we get say 16 frames and we are missing the middle one, we can
> reconstruct things okay. But if we miss the first 8 frames, we don't
> know when it started - we only get the RX aggr boundary flags set on
> the 9th and the 16th and we don't even know about the missed frames.

Yes, discovering retransmissions is difficult at the RX side by nature.
Another approach to catching (some of) these is trying to parse the MAC
address even for corrupted frames, and if it fits to a station, account
the airtime. Of course this will only catch cases where the frame header
does make it through, and it won't work if the hardware discards the
frame as corrupt before we get to see it.

> I think that's going to be a shortcoming right now. I couldn't think
> of a clever way to figure it out except to detect holes in the BAW and
> determine the client is missing frames and take actions there.

Yes, I'm fine with having the RX side airtime accounting just ignore the
retransmission issue, at least for now.

-Toke

  reply	other threads:[~2016-06-08 13:06 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-03 16:51 [Make-wifi-fast] [RFC/RFT 0/5] Adding an airtime fairness scheduler to ath9k Toke Høiland-Jørgensen
2016-06-03 16:51 ` [Make-wifi-fast] [RFC/RFT 1/5] mac80211: skip netdev queue control with software queuing Toke Høiland-Jørgensen
2016-06-06  2:26   ` Julian Calaby
2016-06-06 17:00     ` Toke Høiland-Jørgensen
2016-06-03 16:51 ` [Make-wifi-fast] [RFC/RFT 2/5] ath9k: use mac80211 intermediate software queues Toke Høiland-Jørgensen
2016-06-03 16:51 ` [Make-wifi-fast] [RFC/RFT 3/5] ath9k: Add airstame stats to per-station debugfs Toke Høiland-Jørgensen
2016-06-03 16:51 ` [Make-wifi-fast] [RFC/RFT 4/5] ath9k: Add a per-station airtime deficit scheduler Toke Høiland-Jørgensen
2016-06-03 16:51 ` [Make-wifi-fast] [RFC/RFT 5/5] ath9k: Count RX airtime in airtime deficit Toke Høiland-Jørgensen
2016-06-04 17:06   ` Adrian Chadd
2016-06-05 10:55     ` Toke Høiland-Jørgensen
2016-06-05 17:23       ` Adrian Chadd
2016-06-07  0:01         ` Adrian Chadd
2016-06-07  1:31           ` Jonathan Morton
2016-06-07  8:58           ` Toke Høiland-Jørgensen
2016-06-07 11:12             ` Toke Høiland-Jørgensen
2016-06-08  1:41               ` Adrian Chadd
2016-06-08 13:06                 ` Toke Høiland-Jørgensen [this message]
2016-06-10  8:40               ` Michal Kazior
2016-06-10  8:53                 ` Toke Høiland-Jørgensen
2016-06-10  9:02                   ` Michal Kazior
2016-06-10  9:08                     ` Toke Høiland-Jørgensen
2016-06-10  9:20                       ` Michal Kazior
2016-06-10  9:49                         ` Toke Høiland-Jørgensen
2016-06-10 15:33                           ` Toke Høiland-Jørgensen
2016-06-10 15:52                             ` Adrian Chadd
2016-06-04 15:24 ` [Make-wifi-fast] [RFC/RFT 0/5] Adding an airtime fairness scheduler to ath9k Luca Muscariello
2016-06-05 10:51   ` Toke Høiland-Jørgensen
2016-06-05 11:40     ` Luca Muscariello

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

  List information: https://lists.bufferbloat.net/postorius/lists/make-wifi-fast.lists.bufferbloat.net/

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

  git send-email \
    --in-reply-to=87eg87q17x.fsf@toke.dk \
    --to=toke@toke.dk \
    --cc=adrian@freebsd.org \
    --cc=ath9k-devel@lists.ath9k.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=make-wifi-fast@lists.bufferbloat.net \
    /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