Return-path: Received: from mail.toke.dk ([52.28.52.200]:41423 "EHLO mail.toke.dk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727575AbeGSOcB (ORCPT ); Thu, 19 Jul 2018 10:32:01 -0400 From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Benjamin Beichler , Jean-Pierre TOSONI , Ben Greear , SEDE , ath10k , "linux-wireless\@vger.kernel.org" Subject: Re: Setting tx retry count in ath10k In-Reply-To: References: <8b9713fe-7573-f009-d002-13df73315898@televic.com> <9dd76e58-b514-26f2-2fe9-0c9a7f798054@candelatech.com> <877els5xax.fsf@toke.dk> Date: Thu, 19 Jul 2018 15:48:31 +0200 Message-ID: <87zhyn2v68.fsf@toke.dk> (sfid-20180719_154849_048458_B3F28632) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-wireless-owner@vger.kernel.org List-ID: Benjamin Beichler writes: >>> For general internet traffic, a retry count of 30 is way too high; that >>> is up to 120 ms of HOL blocking latency. Better to just drop the packet >>> at that point. >>> >>> Ideally, the retry count should be dynamically calculated in units of >>> time (which would depend on the rate and aggregate size), and also take >>> queueing time into account. I've been meaning to experiment with this >>> for minstrel and ath9k, but haven't gotten around to it... > We have running current research on this topic but focused on the > effects in 802.11s mesh networks. With multiple(forwarding) wireless > links, the retry limit have a bigger impact as only in managed mode > setups, since every forwarding step is doing repeated transmissions. > But I also totally agree, that the retry count needs to be considered > in the bufferbloat/airtime queuing stuff, which Toke proposed. Ah, cool. Looking forward to seeing your results. And yeah, it's probably even worse in meshes... > Nonetheless, since this ambiguities are known, wouldn't it be nice to > clean up all this patches to enable at least ath9k and ath10k to do > the right thing, or do anybody can tell why they weren't included the > first time ? No objection from me, certainly! :) -Toke