From: Michal Kazior <michal.kazior@tieto.com>
To: "Toke Høiland-Jørgensen" <toke@toke.dk>
Cc: Adrian Chadd <adrian@freebsd.org>,
make-wifi-fast@lists.bufferbloat.net,
ath9k-devel <ath9k-devel@lists.ath9k.org>,
"linux-wireless@vger.kernel.org"
<linux-wireless@vger.kernel.org>
Subject: Re: [Make-wifi-fast] [RFC/RFT 5/5] ath9k: Count RX airtime in airtime deficit
Date: Fri, 10 Jun 2016 11:02:35 +0200 [thread overview]
Message-ID: <CA+BoTQ=9X8621AbG+S3MqYFpeySsYSr3iiwCTHf3VpQAkXAHiQ@mail.gmail.com> (raw)
In-Reply-To: <87inxhl90y.fsf@toke.dk>
On 10 June 2016 at 10:53, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>
>>> I initially thought that using the timestamp put into the frame by the
>>> hardware could be a way to get timing. But there's only a timestamp of
>>> the first symbol in rs_tstamp, and getting a time to compare it with is
>>> difficult; by the time the frame is handled in the rx tasklet, way too
>>> much time has been spent on interrupt handling etc for the current time
>>> to be worth comparing with.
>
> As an aside, I'm no longer sure this explanation for why I got wrong
> timings for this way of measuring RX time is correct. It may simply be
> that I was counting the same time interval more than once because I
> didn't realise that the handler would be called for each frame. See
> below.
>
>> I think rs_tstamp in rx-status is different for first MPDU and last
>> MPDU in an A-MPDU meaning you should be able to compute the entire
>> duration (if you track it, and this should be fairly straightforward
>> as you can't really rx interleaved MPDUs from different
>> A-MPDUs/stations). I'm not sure if the last MPDU defines the tstamp of
>> first symbol or last one.
>
> I actually went down this path again last night, but haven't had a
> chance to test it yet.
>
> So what I have now is this:
>
> /* Only count airtime for last frame in an aggregate. FIXME: Should
> * this be only the first frame? */
> if (!rs->rs_isaggr || !rs->rs_moreaggr)
> airtime = (tsf & 0xffffffff) - rs->rs_tstamp;
>
> Which was under the assumption that rs_tstamp will be the time of the
> first symbol *of the whole ampdu* for all the frames in that aggregate.
> However, if rs_tstamp differs between frames, tracking it at the first
> frame might be the right things to do?
For A-MPDU all MPDU rx status (except last one) should share the same
timestamp. Last one has a different one so all you need is to
distinguish first and last MPDU. Non A-MPDU obviously are special case
(status bits are pricky).
> Is the entire A-MPDU received before the RX handler is called for the
> first frame?
No idea. Maybe it is as there's distinction between "more" and "moreaggr".
Michał
next prev parent reply other threads:[~2016-06-10 9:02 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
2016-06-10 8:40 ` Michal Kazior
2016-06-10 8:53 ` Toke Høiland-Jørgensen
2016-06-10 9:02 ` Michal Kazior [this message]
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='CA+BoTQ=9X8621AbG+S3MqYFpeySsYSr3iiwCTHf3VpQAkXAHiQ@mail.gmail.com' \
--to=michal.kazior@tieto.com \
--cc=adrian@freebsd.org \
--cc=ath9k-devel@lists.ath9k.org \
--cc=linux-wireless@vger.kernel.org \
--cc=make-wifi-fast@lists.bufferbloat.net \
--cc=toke@toke.dk \
/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