From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-x243.google.com (mail-io0-x243.google.com [IPv6:2607:f8b0:4001:c06::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id EC1C43B2A0 for ; Tue, 7 Jun 2016 21:41:20 -0400 (EDT) Received: by mail-io0-x243.google.com with SMTP id 5so4112482ioy.0 for ; Tue, 07 Jun 2016 18:41:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=e3KnvD/2VHomLuFjiKF3EInJsSplyGxdqnHk9y+RD5U=; b=EzkwTseQdAVWgt4LzP5qTwCbVOIw7VxdRYssN7ef8Tik2x4UyWAljRRhfIuItdQLUy TL5GRvAgsOdVCFzAEUIA0K4Jum3/DLUfndo8a1Aht8tHbBzzQWtjYPvsyKtyQuiRQ1A5 ADvzGhX2i6V3tVrVFJi7jB80h6XxeHtNp0N2TfSsf5eMeePtZcGggWqActcZP8GETHtu ka/nIa9/030huuRcf5NXyieQi5pbxpmbX9OsvNcFXxzto62tBb7Q1cxl/rjTjUOt8G/Y nPn16yZdbY6F6PFBo2K2fPnfUrLEQQym3CC2zM5uz03F0l4P4UQVx99yLiHIX1ArUHlL 6JuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=e3KnvD/2VHomLuFjiKF3EInJsSplyGxdqnHk9y+RD5U=; b=fqYZ15MWUjnVOtXBQCirAqNFeZaVBEA9O6kzvg8k1+lglt8/ItLR/Z0/yJm1yVEMU+ feEPMQPF1wxj0IkiF9ejNoTssnD/k8QPSB8l8oWkK+HUzSeBEEeWvEGciJiEQvB0DQzT ahy2bOn5Z1RvWLXjvWC3gVxO54+gg88vCO0V8ek21fNeQt/9oCcn82qHDOIVAVkv0TaB uz62bCGXrozgZtg80QjQmr4gcMRUU+7rRB2GQW6yT3n480THPfRjx5RDpNOUmNGnlbn9 9W4T6AiBTPT72MjytNtY+z1TEcoK/DjAVtgubHIZeH0kZJ7QP0ZRRFBbIBIC08yyYQKf S2lg== X-Gm-Message-State: ALyK8tJazXBKwpZMmLQ1MBfOWPFnqfIXyvq5XNXNzunaIG0OsosGzw5WyuSv4b/HkBS+0Z8NUFbs6T6nmdh4Xg== X-Received: by 10.107.48.211 with SMTP id w202mr3339213iow.123.1465350080237; Tue, 07 Jun 2016 18:41:20 -0700 (PDT) MIME-Version: 1.0 Sender: adrian.chadd@gmail.com Received: by 10.36.113.3 with HTTP; Tue, 7 Jun 2016 18:41:19 -0700 (PDT) In-Reply-To: <87wpm1b6bu.fsf@toke.dk> References: <20160603165144.17356-1-toke@toke.dk> <20160603165144.17356-6-toke@toke.dk> <8737orucq4.fsf@toke.dk> <87k2i1ml43.fsf@toke.dk> <87wpm1b6bu.fsf@toke.dk> From: Adrian Chadd Date: Tue, 7 Jun 2016 18:41:19 -0700 X-Google-Sender-Auth: 4ryBf2wzBiV-VJsTfhn37XyDjxs Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: "linux-wireless@vger.kernel.org" , make-wifi-fast@lists.bufferbloat.net, ath9k-devel Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Make-wifi-fast] [RFC/RFT 5/5] ath9k: Count RX airtime in airtime deficit X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 01:41:21 -0000 On 7 June 2016 at 04:12, Toke H=C3=B8iland-J=C3=B8rgensen wr= ote: > Toke H=C3=B8iland-J=C3=B8rgensen writes: > >>> [snip] >>> >>> I also found one of my notes in my version of this - how can we >>> estimate the duration of an A-MPDU, when we only get hardware >>> de-encapsulated frames? >> >> Well in my case I'm sidestepping this by getting the TX duration from >> a register in the hardware. There seems to be registers containing the >> duration spent on each step in the retry chain; I simply sum these. > > Ah, but you're still talking RX? Hmm, I'm using ath_pkt_duration() to > compute the RX time, which does take into account MIMO (I think) but > expects the size to include padding. Which is probably not included in > the rs_datalen field of struct ath_rx_status that I'm using. > > So yeah, how to account for that? > > 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. 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. 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. -adrian