From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2.tohojo.dk (mail2.tohojo.dk [77.235.48.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id B648D3B2BC for ; Tue, 7 Jun 2016 07:12:56 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail2.tohojo.dk DKIM-Filter: OpenDKIM Filter v2.10.3 mail2.tohojo.dk 9DAAC40A3A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=201310; t=1465297974; bh=PjVwJFeHKu0/tTpaJxT4pNfV0WJndFTWTBBTleivVw4=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=ZhbrlyzcoZd2Hs5IKgWCZE/lBrxvJdjr80o40YPMZ8WSLOqqHJ9RzKMoT7b9V+d70 fQ84F/qPR5Xy02d60YQ+N5hV4sFqSNcyXW8LFCfRXfrxiqx0BZYCi/55dKWlQ3QLGC Vh/MhI2OhVVLORBhKWsazETjJfrwPApjI/yKNP84= Received: by alrua-kau.kau.toke.dk (Postfix, from userid 1000) id CF0D6C40163; Tue, 7 Jun 2016 13:12:53 +0200 (CEST) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: Adrian Chadd Cc: "linux-wireless\@vger.kernel.org" , make-wifi-fast@lists.bufferbloat.net, ath9k-devel References: <20160603165144.17356-1-toke@toke.dk> <20160603165144.17356-6-toke@toke.dk> <8737orucq4.fsf@toke.dk> <87k2i1ml43.fsf@toke.dk> Date: Tue, 07 Jun 2016 13:12:53 +0200 In-Reply-To: <87k2i1ml43.fsf@toke.dk> ("Toke =?utf-8?Q?H=C3=B8iland-J?= =?utf-8?Q?=C3=B8rgensen=22's?= message of "Tue, 07 Jun 2016 10:58:04 +0200") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87wpm1b6bu.fsf@toke.dk> MIME-Version: 1.0 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: Tue, 07 Jun 2016 11:12:56 -0000 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. -Toke