From: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
To: Ping-Ke Shih <pkshih@realtek.com>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
Yan-Hsuan Chuang <tony0620emma@gmail.com>,
Kalle Valo <kvalo@kernel.org>,
Ulf Hansson <ulf.hansson@linaro.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
Chris Morgan <macroalpha82@gmail.com>,
Nitin Gupta <nitin.gupta981@gmail.com>,
Neo Jou <neojou@gmail.com>,
Jernej Skrabec <jernej.skrabec@gmail.com>
Subject: Re: [RFC PATCH v1 00/19] rtw88: Add SDIO support
Date: Fri, 30 Dec 2022 00:18:39 +0100 [thread overview]
Message-ID: <CAFBinCBcurqiHJRSyaFpweYmrgaaUhpy632QQNWcrd3UHRtZbQ@mail.gmail.com> (raw)
In-Reply-To: <8fe9b10318994be18934ec41e792af56@realtek.com>
Hi Ping-Ke,
thanks again for all your input!
On Thu, Dec 29, 2022 at 5:19 AM Ping-Ke Shih <pkshih@realtek.com> wrote:
[...]
> > - RX throughput on a 5GHz network is at 19 Mbit/s
>
> I have a suggestion about RX throughput, please check below registers with
> vendor driver:
>
> REG_RXDMA_AGG_PG_TH
> REG_TXDMA_PQ_MAP(0x10c) BIT_RXDMA_AGG_EN (bit2)
> REG_RXDMA_MODE(0290) BIT_DMA_MODE (bit1)
Unfortunately I didn't manage to get the vendor driver to work with
mainline Linux.
The Android installation on my board (which is how it was shipped)
uses the vendor driver but unlike some Amlogic code the Realtek
(vendor) wireless driver does not allow reading arbitrary registers
through sysfs.
So I can't check the values that the vendor driver uses.
> Try to adjust AGG_PG_TH to see if it can help.
I tried a few values and I can say that it does change the RX
throughput, but the result is always lower than 19 Mbit/s, meaning
that it's worse than RX aggregation disabled (on my RTL8822CS).
Currently we're disabling RX aggregation in the driver. But Jernej
mentioned previously that for his RTL8822BS he found that RX
aggregation seems to improve performance.
Independent of this I did some investigation on my own and found that
when reducing the TX throughput the RX throughput increases.
For this I tried using ieee80211_{stop,wake}_queue() in the sdio.c HCI
sub-driver.
RX throughput is now at 23.5 Mbit/s (that +25% compared to before) on
my RTL8822CS (with RX aggregation still disabled, just like in the 19
Mbit/s test).
Unfortunately TX throughput is now way below 10 Mbit/s.
Additionally I think that the antenna of my board is worse than my
access point's antenna. So TX from rtw88 to my AP may be faster
(because the AP can "hear better") than RX (rtw88 "hearing is worse").
For today I'm tired and will stop here.
Best regards,
Martin
[0] https://github.com/xdarklight/linux/commit/3f2e6b9cd40dc785b5c72dbc9c8b471a2e205344
next prev parent reply other threads:[~2022-12-29 23:19 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-27 23:30 [RFC PATCH v1 00/19] rtw88: Add SDIO support Martin Blumenstingl
2022-12-27 23:30 ` [RFC PATCH v1 01/19] rtw88: mac: Use existing interface mask macros in rtw_pwr_seq_parser() Martin Blumenstingl
2022-12-27 23:30 ` [RFC PATCH v1 02/19] rtw88: pci: Change type of rtw_hw_queue_mapping() and ac_to_hwq to enum Martin Blumenstingl
2022-12-27 23:30 ` [RFC PATCH v1 03/19] rtw88: pci: Change queue datatype from u8 to enum rtw_tx_queue_type Martin Blumenstingl
2022-12-27 23:30 ` [RFC PATCH v1 04/19] rtw88: Move enum rtw_tx_queue_type mapping code to tx.{c,h} Martin Blumenstingl
2022-12-27 23:30 ` [RFC PATCH v1 05/19] mmc: sdio: add Realtek SDIO vendor ID and various wifi device IDs Martin Blumenstingl
2023-01-03 11:41 ` Ulf Hansson
2022-12-27 23:30 ` [RFC PATCH v1 06/19] rtw88: rtw8821c: Add support for parsing the RTL8821CS (SDIO) efuse Martin Blumenstingl
2022-12-28 6:21 ` Ping-Ke Shih
2022-12-27 23:30 ` [RFC PATCH v1 07/19] rtw88: rtw8822b: Add support for parsing the RTL8822BS " Martin Blumenstingl
2022-12-27 23:30 ` [RFC PATCH v1 08/19] rtw88: rtw8822c: Add support for parsing the RTL8822CS " Martin Blumenstingl
2022-12-27 23:30 ` [RFC PATCH v1 09/19] rtw88: hci: Add an optional power_switch() callback to rtw_hci_ops Martin Blumenstingl
2022-12-27 23:30 ` [RFC PATCH v1 10/19] rtw88: mac: Add support for the SDIO HCI in rtw_pwr_seq_parser() Martin Blumenstingl
2022-12-27 23:30 ` [RFC PATCH v1 11/19] rtw88: mac: Add support for the SDIO HCI in the TX/page table setup Martin Blumenstingl
2022-12-27 23:30 ` [RFC PATCH v1 12/19] rtw88: sdio: Add HCI implementation for SDIO based chipsets Martin Blumenstingl
2022-12-28 9:39 ` Ping-Ke Shih
2022-12-28 11:59 ` Martin Blumenstingl
2022-12-29 0:50 ` Ping-Ke Shih
2023-01-03 11:42 ` Ulf Hansson
2022-12-27 23:30 ` [RFC PATCH v1 13/19] rtw88: mac: Add support for SDIO specifics in the power on sequence Martin Blumenstingl
2022-12-29 1:14 ` Ping-Ke Shih
2022-12-29 10:49 ` Martin Blumenstingl
2022-12-29 11:24 ` Ping-Ke Shih
2022-12-27 23:30 ` [RFC PATCH v1 14/19] rtw88: main: Add the rpwm_addr and cpwm_addr for SDIO based chipsets Martin Blumenstingl
2022-12-27 23:30 ` [RFC PATCH v1 15/19] rtw88: main: Reserve 8 bytes of extra TX headroom for SDIO based cards Martin Blumenstingl
2022-12-27 23:30 ` [RFC PATCH v1 16/19] rtw88: ps: Increase LEAVE_LPS_TRY_CNT for SDIO based chipsets Martin Blumenstingl
2022-12-27 23:30 ` [RFC PATCH v1 17/19] rtw88: Add support for the SDIO based RTL8822BS chipset Martin Blumenstingl
2022-12-27 23:30 ` [RFC PATCH v1 18/19] rtw88: Add support for the SDIO based RTL8822CS chipset Martin Blumenstingl
2022-12-29 1:40 ` Ping-Ke Shih
2022-12-27 23:30 ` [RFC PATCH v1 19/19] rtw88: Add support for the SDIO based RTL8821CS chipset Martin Blumenstingl
2023-01-03 23:01 ` Chris Morgan
2023-01-04 15:40 ` Martin Blumenstingl
2023-01-04 17:05 ` Chris Morgan
2023-01-04 17:23 ` Martin Blumenstingl
2023-01-04 22:45 ` Chris Morgan
2023-01-04 19:59 ` Bitterblue Smith
2023-01-04 20:06 ` Felix Schwarz
2023-01-04 20:14 ` Larry Finger
2023-01-07 14:53 ` Bitterblue Smith
2023-01-05 8:01 ` Sascha Hauer
2023-01-05 15:38 ` Bitterblue Smith
2022-12-29 4:19 ` [RFC PATCH v1 00/19] rtw88: Add SDIO support Ping-Ke Shih
2022-12-29 23:18 ` Martin Blumenstingl [this message]
2022-12-30 0:06 ` Ping-Ke Shih
2023-01-16 16:01 ` Kalle Valo
2023-01-17 17:21 ` Jakub Kicinski
2023-01-17 18:01 ` Kalle Valo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAFBinCBcurqiHJRSyaFpweYmrgaaUhpy632QQNWcrd3UHRtZbQ@mail.gmail.com \
--to=martin.blumenstingl@googlemail.com \
--cc=jernej.skrabec@gmail.com \
--cc=kvalo@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=macroalpha82@gmail.com \
--cc=neojou@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=nitin.gupta981@gmail.com \
--cc=pkshih@realtek.com \
--cc=tony0620emma@gmail.com \
--cc=ulf.hansson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).