Search Linux Wireless

RE: Setting tx retry count in ath10k

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Ben,

I attached the patch. Please remind that it applies to ath9k.

At the end there are 3 comments in French, translation follows:
1) " longretry gives directly the transmit count, the +1 is useless.
     Should rather have -1 to account for the first try"
2) " The retries just made for this frame must be added in to know
     If the max was overstepped"
3) " Add the 1st try (probably useless).
     Upstream version adds 1 to A-MPDU retries but I don't understand why.
     Since above I removed the +1 to fix the count, I add +1 here once per
     frame in case the "+1" is actually hiding a bug in the upstream version"

@Toke: As you can see in the patch, the value 30 was the fixed value defined
 in ath9k, I kept it for compatibility only (and that's why I wanted to make
 it configurable :-)
On another hand, Minstrel in mac80211 seems to vary retries according to what
you say, i.e. Minstrel tries to stay below a certain amount of time, but this
only applies to short/long retries.

Jean-Pierre

> -----Message d'origine-----
> De : Toke Høiland-Jørgensen [mailto:toke@xxxxxxx]
> Envoyé : mercredi 18 juillet 2018 18:22
> À : Ben Greear; Jean-Pierre TOSONI; SEDE; Benjamin Beichler; ath10k; linux-wireless@xxxxxxxxxxxxxxx
> Objet : Re: Setting tx retry count in ath10k
> 
> Ben Greear <greearb@xxxxxxxxxxxxxxx> 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

Attachment: a919-acksys-Add-parameter-for-software-retry.patch
Description: a919-acksys-Add-parameter-for-software-retry.patch


[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Wireless Regulations]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux