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 856073B25D for ; Wed, 8 Jun 2016 09:06:31 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail2.tohojo.dk DKIM-Filter: OpenDKIM Filter v2.10.3 mail2.tohojo.dk E66D240A4C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=201310; t=1465391187; bh=cewB40S1AWT+IoF1eIBo023x9cYzuibrY+S2GqIs/MA=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=Q6lr5AplkYwXQyBdTPl9zA8XV2a06i43gS2+Ns+25/b1ffgIAR7mcsypneWzxQXCI ESPpNCENrR2wPbZA5KrKMRo81ClzgXkb1uV7iPb3vMS1ISUAnmNS0Zi55fpiy/7rVL KmKEQAAOw1qHJrrebjoBtSw94MTCmw4e6/8xsfm8= Sender: toke@toke.dk Received: by alrua-kau.kau.toke.dk (Postfix, from userid 1000) id A5BF3C40163; Wed, 8 Jun 2016 15:06:26 +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> <87wpm1b6bu.fsf@toke.dk> Date: Wed, 08 Jun 2016 15:06:26 +0200 In-Reply-To: (Adrian Chadd's message of "Tue, 7 Jun 2016 18:41:19 -0700") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87eg87q17x.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain 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 13:06:31 -0000 Adrian Chadd 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