Hi Ben, Just a quick reaction: I guess the choice should mainly depend on the mean airtime to transmit a frame, not on the final throughput, since it is a shared half-duplex media? Retransmission is fine up to the point it does not take more airtime than a lower MCS? Jean-Pierre > -----Message d'origine----- > De : linux-wireless-owner@xxxxxxxxxxxxxxx [mailto:linux-wireless-owner@xxxxxxxxxxxxxxx] De la part de > Ben Greear > Envoyé : samedi 20 octobre 2018 20:57 > À : linux-wireless@xxxxxxxxxxxxxxx > Objet : Re: Rate-ctrl experience gained with ath10k > > I now have the 9984 ath10k working pretty good I think, at least as far as > rate-ctrl is going. It tries to keep retransmit < 10% and throughput is > fine compared to using MCS with higher retransmit (and higher encoding rates). > > But, I tried to put similar changes (dodge high retransmit MCS if possible), > and for the wave-1 9880 chip, this decreased throughput. > > For instance, current rate-ctrl was retransmitting about 30% of the frames > when allowed to choose its MCS. In this case, I saw around 225-230Mbps throughput. > > But, if I forced it down to MCS-5, 3x3, then throughput was about 220Mbps, and > retry percent was closer to 2%. > > So, question is...should I still tweak its ratectrl to choose lower MCS when > retransmit % is high, or should I just let it retransmit. Maybe lower MCS and lower > retransmit would be better over-all if there are lots of devices on the network? > > I'll run some tests to experiment with that when I have time, but curious if others > have already done similar... > > Thanks, > Ben > > > On 10/16/2018 04:31 PM, Ben Greear wrote: > > So, I've been trying to understand why the ath10k-rate ctrl was acting > > so poorly in my 20-station UDP tx case. I wrote that wifi-diag tool, > > and it gave some clues, but only in retrospect were they obvious :) > > > > The problem in general was that a single station could upload, at say 500Mbps, > > but 20 stations could only do about 325Mbps. If we fixed the MCS at 3x3 MCS7, > > then the 20 station upload test ran about 490Mbps. > > > > There were several optimizations I made in the ath10k firmware rate-ctrl. One > > was to penalize rates with higher PER (packet error rate) more than the old algorithm did. This > helped > > a small bit, but not enough (around 350-370Mbps total throughput). > > > > Then, after adding logs I noticed that each station was probing once about every 5 ampdu > > chains, or almost 20% of the time! These probe AMPDUs are limited to a max of 4 AMSDUs, > > and that explains why my 'bad' case showed 17% of the AMPDU chains were 4 in length in > > my wifi-diag output. > > > > I changed the firmware to take number of active stations into account, and increase the > > 75ms probe interval by up to a factor of 5. I also probe less often when the probed > > rate has PER > 5 or the last probe had a dropped frame. > > > > And, I allow probing with AMPDU chains of up to 16 AMSDU instead of just 4. > > > > Together this gets me up to about 460Mbps in this test case. Still not quite as good > > as fixing the MCS at 7, but good enough I think. > > > > Here's hoping this email will let other folks poking at rate-ctrl have a faster > > time at fixing things than I did. > > > > Thanks, > > Ben > > > > > -- > Ben Greear <greearb@xxxxxxxxxxxxxxx> > Candela Technologies Inc http://www.candelatech.com
