On 5/17/19 8:47 AM, Adrian Chadd wrote:
On Fri, 17 May 2019 at 08:06, Sebastian Gottschall
<s.gottsch...@newmedia-net.de> wrote:
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
It depends on what kind of channel you are. Not everyone is deploying
super dense enterprise APs. :-)
The 11ac and 11ax chips that do constant frequency readjusting work
better in things like moving drones, where you have constant doppler
shift. I know some people doing drone work that just don't bother with
MCS and aggregation because they need a super reliable channel and the
conditions constantly shift.
That said, they're very sad that they can't hack on the 11ac/11ax
firmware to fix some err, less optimal decisions in their use case
space like they can with ath5k/ath9k.
ISTR back at QCA days there were some people on the systems team that
could demonstrate CCK was more stable in some use cases and so didn't
like the Linux rate control behaviour of not falling back to CCK in 2G
11n mode. There was .. pushback against the linux upstream rate
control in this respect right until the linux folk totally deprecated
the QCA rate control in ath9k. :)
(And then bugs like what ben is seeing :)
Ben - did disabling CCK/OFDM fallback rates help? Did you fix the bit
that tries to send AMPDU frames in non-11n rates?
Yes, disabling the fallback appears to have fixed my issue.
I did not try to fix the fallback code because I think it will be quite
complicated to do it properly (I suspect a different tid must be used for this
to work). I'm not even entirely sure of exactly why the transmit logic fails
in this case, and by the time rate-ctrl logic is queried, I think it is too
late to easily change tids.
And FYI, in my firmware/driver, you can now specify the exact preamble-type,
mcs, bandwidth, txpower,
retransmit count, etc on a per packet basis. I'm not sure of all the bugs and
limitations
in this code, but it at least mostly works as hoped for the ways we are using it
(rx sensitivity test rigs, etc).
Might be of interest if someone wants to do a somewhat limited user-space
rate-ctrl for
ath10k wave-2.
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
