Return-path: Received: from mail.toke.dk ([52.28.52.200]:34273 "EHLO mail.toke.dk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731492AbeGRRAy (ORCPT ); Wed, 18 Jul 2018 13:00:54 -0400 From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Ben Greear , Jean-Pierre TOSONI , SEDE , Benjamin Beichler , 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> Date: Wed, 18 Jul 2018 18:21:58 +0200 Message-ID: <877els5xax.fsf@toke.dk> (sfid-20180718_182332_194898_3D950AAC) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-wireless-owner@vger.kernel.org List-ID: Ben Greear writes: > On 07/18/2018 08:50 AM, Jean-Pierre TOSONI wrote: >> Hi, >> >> We made retries configurable in our mac80211+ath9k system, and we ended with 3 counts: >> 1) short retry count, defaults to 4 >> 2) long retrys count, defauts to 7 >> 3) software retry count, defaults to 30 >> This last one is used separately for each frame in an aggregated frame, since they can be separately acknowledged. > > Did you have to change code for #3, and if so, can you share the patch? > > I wonder also if retries should be different for different types of > data. For instance, if someone is using UDP, maybe they don't care so > much about lost packets and would prefer a lower retry count. Or, > maybe IP type-of-service could be taken into account and retry frames > different amounts based on ToS? 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... -Toke