Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= <toke@redhat.com>
To:     Zefir Kurtisi <zefku@westermo.com>, linux-wireless@vger.kernel.org
Cc:     Felix Fietkau <nbd@nbd.name>, qca-developer-program@qualcomm.com
Subject: Re: [RFT] ath9k: multi-rate-retry fails at HW level
In-Reply-To: <2a8573d7-6683-3414-a8af-dab460772205@westermo.com>
References: <2a8573d7-6683-3414-a8af-dab460772205@westermo.com>
Date:   Tue, 24 Nov 2020 15:45:07 +0100
Message-ID: <878saqlsp8.fsf@toke.dk>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

Zefir Kurtisi <zefku@westermo.com> writes:

> Hi,
>
> I am running into a strange issue with the ath9k operating a 9590
> device which to me seems like a HW issue, but since work on rate
> controllers is already going for decades, I hardly can imagine this
> never showed up.
>
> The issue observed is this: the TX status descriptors never report
> rateindex 1, it is always 0, 2, or 3, but never 1.
>
> I noticed this by overwriting the rate configuration provided by
> minstrel to a static setup, e.g. (7,3)(5,3)(3,3)(1,3), all MCS. The
> device operates as iperf client to a connected AP and continuously
> transmits data. While at that, the attenuation between the endpoints
> is gradually increased, expecting to see a gradual shift in the
> reported TX status rateindex from 0 to 3. But nada, the values
> reported are 0,2, and 3 - never 1.
>
> I double checked that the TX descriptors are correctly set with the
> rates and retry counts - all looking sane.
>
> More obvious, after changing the rate configuration to
> (7,3)(1,3)(5,3)(3,3) the expectation would be to have either 0 or 1
> reported as rateidx, since the transmission ought to be successful
> with the lowest rate or never. Again all rates are reported but 1.
>
> Now the question for me is: what is the HW exactly doing with such a
> configuration? Is it skipping the second rate, or is it just reporting
> wrong?

You should be able to see this by looking at the rates the frames are
being sent at, shouldn't you?

> Both possibilities have great impact, since upper layers (like
> airtime) use the returned rateidx to calculate and configure operating
> parameters at runtime.

Have you actually observed any issues from this? If it's just skipping a
rate, minstrel should still be able to make decisions based on the
actual values returned, no?

> If this is a know issue, nevermind and thanks for pointing me to it. Otherwise if
> some of you have the named device operational, it would help a lot to get the
> issue confirmed. Just apply the attached patch and perform some TX testing in
> either attenuation adjustable or varying link condition setups. Whenever a frame
> is reported to have been transmitted at a rateidx > 0, the collected stats are
> logged, e.g.
> MRR: 2: [51029, 0, 4741, 6454]
>
> In essence, the failure is confirmed if the counter for 1 is 0 or very low
> compared to higher numbers for 0, 2, or 3.

Tried your patch and couldn't reproduce. Not the same hardware, though.
Mine is:

01:00.0 Network controller: Qualcomm Atheros AR9287 Wireless Network Adapter (PCI-Express) (rev 01)

-Toke