Rate-ctrl experience gained with ath10k

Rate-ctrl experience gained with ath10k

[Ben Greear]

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@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: Rate-ctrl experience gained with ath10k

[Ben Greear]

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@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

RE: Rate-ctrl experience gained with ath10k

[Jean-Pierre TOSONI]

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@vger.kernel.org [mailto:linux-wireless-owner@vger.kernel.org] De la part de
> Ben Greear
> Envoyé : samedi 20 octobre 2018 20:57
> À : linux-wireless@vger.kernel.org
> 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@candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com