Am 17.05.2019 um 13:48 schrieb Ben Greear:
On 05/16/2019 09:21 PM, Sebastian Gottschall wrote:
Am 16.05.2019 um 21:40 schrieb Ben Greear:
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
according to the code this variable has only effect on 2.4 ghz. the
fallback to cck rates will only be done if phymode is 2.4 ghz
Ok, maybe the symptom I saw with stock-ish firmware was due to some
other cause. In my firmware,
I had "fixed" that cck-fallback to use OFDM rates in case CCK was not
available, so mine was
definitely trying to use an OFDM rate.
That said, very likely the same bug exists in upstream QCA firmware
for 2.4Ghz radios where CCK is available,
so still might be worth fixing or at least adding API to let the user
disable the fallback in case strange
problems are seen.
I am guessing that if it really wants to send OFDM/CCK rates, then it
will have to use a different
TID that is not set up for AMPDUs, and the current code does not deal
with that as far as I can tell.
personally i think going back to basic rates like 2 mbit makes no sense
anyway. its that dead slow that a connection must break and has to be
broken if this doesnt work.
still a shame that beacons are still transmitted in this way and
multicast/broadcast packets as well which causes a hell of problems. but
thats for backward compatibility of cause
Thanks,
Ben
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
