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
