Received-SPF: softfail (google.com: domain of transitioning linux-wireless-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
Date:   Mon, 4 Apr 2022 23:25:12 +0200
From:   Peter Seiderer <ps.report@gmx.net>
To:     Toke =?UTF-8?B?SMO4aWxhbmQtSsO4cmdlbnNlbg==?= <toke@toke.dk>
Cc:     linux-wireless@vger.kernel.org, Kalle Valo <kvalo@kernel.org>,
        "David S . Miller" <davem@davemloft.net>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>,
        Johannes Berg <johannes@sipsolutions.net>,
        netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
        Felix Fietkau <nbd@nbd.name>
Subject: Re: [PATCH v1 2/2] mac80211: minstrel_ht: fill all requested rates
Message-ID: <20220404232512.4fdd7eb9@gmx.net>
In-Reply-To: <87fsmseml7.fsf@toke.dk>
References: <20220402153014.31332-1-ps.report@gmx.net>
        <20220402153014.31332-2-ps.report@gmx.net>
        <87fsmseml7.fsf@toke.dk>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Hello Toke, Felix,

On Mon, 04 Apr 2022 20:21:24 +0200, Toke H=C3=B8iland-J=C3=B8rgensen <toke@=
toke.dk> wrote:

> +Felix
>=20
> Peter Seiderer <ps.report@gmx.net> writes:
>=20
> > Fill all requested rates (in case of ath9k 4 rate slots are
> > available, so fill all 4 instead of only 3), improves throughput in
> > noisy environment. =20
>=20
> How did you test this? Could you quantify the gains in throughput you saw?

Investigating some performance degradation of a wifi system original with a=
th5k
cards using a legacy kernel and madwifi driver compared against the=20
performance using a ath9k card running IBSS mode over long distance/with
additional amplifier and using iperf for measurement...

With the ath5k cards under bad conditions the throughput is going down below
10 Mbits/s but with stable throughput..., with the ath9k card and the exact=
 same
setup there are short periods with good throughput values and periods up to=
 10-15
seconds with 0 Mbits/s...

The actual in-door/laboratory test setup is a wired connection between the
two wifi systems (with fixed attenuators in between) and an adjustable nois=
e/
disturb signal induced by a signal generator...

Without this patch the 0 Mbits/s periods from the field test are reproducib=
le,
with this patch applied we see a more or less stable throughput of 1-5 Mbit=
s/s...

Regards,
Peter

>=20
> -Toke
>=20
> > Signed-off-by: Peter Seiderer <ps.report@gmx.net>
> > ---
> >  net/mac80211/rc80211_minstrel_ht.c | 14 +++++++-------
> >  1 file changed, 7 insertions(+), 7 deletions(-)
> >
> > diff --git a/net/mac80211/rc80211_minstrel_ht.c b/net/mac80211/rc80211_=
minstrel_ht.c
> > index 9c6ace858107..cd6a0f153688 100644
> > --- a/net/mac80211/rc80211_minstrel_ht.c
> > +++ b/net/mac80211/rc80211_minstrel_ht.c
> > @@ -1436,17 +1436,17 @@ minstrel_ht_update_rates(struct minstrel_priv *=
mp, struct minstrel_ht_sta *mi)
> >  	/* Start with max_tp_rate[0] */
> >  	minstrel_ht_set_rate(mp, mi, rates, i++, mi->max_tp_rate[0]);
> > =20
> > -	if (mp->hw->max_rates >=3D 3) {
> > -		/* At least 3 tx rates supported, use max_tp_rate[1] next */
> > -		minstrel_ht_set_rate(mp, mi, rates, i++, mi->max_tp_rate[1]);
> > -	}
> > +	/* Fill up remaining, keep one entry for max_probe_rate */
> > +	for (; i < (mp->hw->max_rates - 1); i++)
> > +		minstrel_ht_set_rate(mp, mi, rates, i, mi->max_tp_rate[i]);
> > =20
> > -	if (mp->hw->max_rates >=3D 2) {
> > +	if (i < mp->hw->max_rates)
> >  		minstrel_ht_set_rate(mp, mi, rates, i++, mi->max_prob_rate);
> > -	}
> > +
> > +	if (i < IEEE80211_TX_RATE_TABLE_SIZE)
> > +		rates->rate[i].idx =3D -1;
> > =20
> >  	mi->sta->max_rc_amsdu_len =3D minstrel_ht_get_max_amsdu_len(mi);
> > -	rates->rate[i].idx =3D -1;
> >  	rate_control_set_rates(mp->hw, mi->sta, rates);
> >  }
> > =20
> > --=20
> > 2.35.1 =20