On 07/17/2018 12:56 AM, SEDE wrote:
Hi,
In the standard, 7 is the default for the short retry count, 4 is well the default for long retry count.
In ath10k, there is also non_agg_sw_retry_th to control this, will this still be used?
Or what is the difference with rc_num_retries?
Kind regards,
Sébastien.
The ath10k firmware has no idea of long vs short retries, so I just used the
long setting.
I will investigate that non_agg_sw_retry_th as well, and I did notice my wave-1
firmware (at least) uses 15 retries for self-generated frames. But, in my case,
those self-gen frames are not much used anyway since I disable firmware keep-alive.
And, I need to see how the mac80211 stack handles its own retries when working
with ath10k.
Thanks,
Ben
On 2018-07-17 09:39, Benjamin Beichler wrote:
Hi,
Am 17.07.2018 um 02:37 schrieb Ben Greear:
I spent a bit of time looking into setting the tx retry count in
ath10k (wave-1 firmware). The firmware has support for setting this as
a vdev parameter, and it defaults to '2', at least in my wave-1 firmware.
I enabled propagating the setting from mac80211, ie:
iw phy wiphy0 set retry short 2 long 2
And while debugging this, I noticed that mac80211 has a default of
4, but the ath10k firmware has a default of 2. Now, I am not sure
if I should enable setting the retry count since it will change
the behaviour even if users don't set anything.
Maybe I'm wrong, but I have in mind, that 7 retries is the default
setting of mac80211. Although 2 or even 4 seems to be pretty low for the
overall retry count, so maybe the values are somehow changed in the
firmware? From our experiments we know (at least for 802.11n) you need
for normal operation a retry count of something between 5 - 9, but
sometimes also 12 or 15 is beneficial.
We use for our experimental setup mainly ath9k cards and rt28xx nics,
and with them you need definitely more retries.
Nonetheless, I don't think the change from 2 to 4 does really affect the
behavior in a negative way (if it works as expected).
Any opinions on this?
Thanks,
Ben
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
