On 5/15/19 6:00 AM, Ben Greear wrote:
On 5/15/19 5:26 AM, Sebastian Gottschall wrote:
Am 15.05.2019 um 14:20 schrieb Ben Greear:
On 05/14/2019 09:26 PM, Sebastian Gottschall wrote:
can you send me a detailed instruction for testing this on my devices? so which
commands have been used for generating the traffic etc. (iperf3?)
I am using our own traffic generator, but I imagine iperf3 should work fine too.
I am testing on x86-64 and so forth. Maybe you can test with UDP small-packet
load on your platform
in routed mode (ie, external iperf generator through your AP) and see if you
see issues?
thats the plan. can you do a test with iperf3 to see if its reproduceable. i
mean i will test it on ipq based boards and x64. but to make sure that the
scenario
is identical which raised up your issue, it would be find if we have identical
software for testing including the same options
I think I found the issue. The rate-ctrl logic in the firmware allows a
transition from HT/VHT 20 MCS0 down to OFDM rates.
It seems the hardware does not like to see an AMPDU with an OFDM rate for 20Mhz
and a VHT rate for 80Mhz (or maybe just the
single OFDM rate is the fault).
If you can edit firmware, then setting this to 0 probably fixes the issue.
g_rc_cck_rate_allowed
I think to reproduce you'd need to send high speed traffic in a situation where
the
RF environment is going to make rate-ctrl fail quite a bit. (Slow speed should
work too, but it would likely take a lot longer).
And, it is always possible that whatever I saw when testing mostly-stock FW is
different
from what I eventually debugged to in my firmware. Still, from looking at MCS
vs SNR
charts, there seems to be no advantage to trying OFDM vs MCS0 for 20Mhz.
Thanks,
Ben
--
Ben Greear <gree...@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
