linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ping-Ke Shih <pkshih@realtek.com>
To: Bitterblue Smith <rtl8821cerfe2@gmail.com>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: RE: [PATCH rtw-next 3/4] wifi: rtw88: Set AMPDU factor to hardware
Date: Wed, 19 Mar 2025 00:28:40 +0000	[thread overview]
Message-ID: <95da11e5ec6f43babaedc6dfc25c3cbf@realtek.com> (raw)
In-Reply-To: <aa278922-5fac-4f47-acc2-25cc2c133365@gmail.com>

Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
> On 18/03/2025 04:06, Ping-Ke Shih wrote:
> > Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
> >> On 17/03/2025 05:01, Ping-Ke Shih wrote:
> >>> Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
> >>>>
> >>>> Tell the chip the maximum AMPDU size supported by the AP. This greatly
> >>>> improves the TX speed of RTL8814AU in the 2.4 GHz band. Before: ~90
> >>>> Mbps. After: ~300 Mbps.
> >>>>
> >>>> Add this configuration for all the chips, even if it only has an effect
> >>>> on RTL8814AU in my tests. Surely they all need this.
> >>>
> >>> The hardware default value of REG_AMPDU_MAX_LENGTH is 0xffff (unlimited)
> >>> for most chips. It seems like RTL8812A/RTL8821A are also exceptions, so
> >>> at power on function they do
> >>>     rtw_write32(rtwdev, REG_AMPDU_MAX_LENGTH, 0xffffffff);
> >>>
> >>> I feel RTL8814A has similar setting, so maybe you can just add similar
> >>> stuff.
> >>>
> >>> By the way, the AMPDU is controlled by TX descriptor basically:
> >>>       pkt_info->ampdu_factor = ampdu_factor;
> >>>       pkt_info->ampdu_density = ampdu_density;
> >>>       pkt_info->ampdu_en = ampdu_en;
> >>>
> >>> Since you didn't change this part at all, I still feel setting
> >>> REG_AMPDU_MAX_LENGTH to 0xffffffff can fix low throughput problem.
> >>>
> >>
> >> I tried 0xffffffff just now and it doesn't work. It's the same with
> >> both of my routers. They advertise a maximum AMPDU size of 64 K.
> >> I can't just set it to 0xffff either, because then the upload speed
> >> in the 5 GHz band suffers a lot. The dual band router advertises a
> >> maximum AMPDU size of 256 K in the 5 GHz band so it gets a value of
> >> 0x3ffff.
> >
> > Not sure if 0xffffffff is a special value. Since this is a limit of
> > AMPDU length, you can set a constant large value such as 0x3ffff you
> > have tested. Is there special case it can't handle?
> >
> >
> 
> 0x3ffff is not good for the 2.4 GHz band. The upload is only ~90 Mbps
> with both of the routers I tested. Same with 0x1ffff. Only 0xffff
> works well for them.

Have you checked the packets in the air? How about their difference?
Intuitively larger REG_AMPDU_MAX_LENGTH would be better.

> 
> 0xffff is too little for the 5 GHz band. The upload speed is ~200 Mbps
> less than with 0x3ffff.
> 
> I guess if you really don't want this patch I can hardcode 0xffff and
> 0x3ffff in rtw8814a_switch_band(). I just don't know if all access
> points will be happy with that.

Initially I wanted to simply this patch, because changing REG_AMPDU_MAX_LENGTH
for other chips without testing is risky. With your tests, the behavior of
REG_AMPDU_MAX_LENGTH works not fully expected, so I suspect the risk
is even higher. 

Therefore, I would like limit this change to RTL8814A. Though hardcode proposal
is not sure workable for all AP, we also don't know this patch works for all
AP. Anyway this proposal is fine to me if we don't have other ideas.



  reply	other threads:[~2025-03-19  0:28 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-13 20:15 [PATCH rtw-next 0/4] Improve RTL8814AU performance Bitterblue Smith
2025-03-13 20:16 ` [PATCH rtw-next 1/4] wifi: rtw88: usb: Enable switching the RTL8814AU to USB 3 Bitterblue Smith
2025-03-17  2:52   ` Ping-Ke Shih
2025-03-13 20:17 ` [PATCH rtw-next 2/4] wifi: rtw88: usb: Enable RX aggregation for RTL8814AU Bitterblue Smith
2025-03-17  2:53   ` Ping-Ke Shih
2025-03-13 20:18 ` [PATCH rtw-next 3/4] wifi: rtw88: Set AMPDU factor to hardware Bitterblue Smith
2025-03-17  3:01   ` Ping-Ke Shih
2025-03-17 13:24     ` Bitterblue Smith
2025-03-18  2:06       ` Ping-Ke Shih
2025-03-18 18:41         ` Bitterblue Smith
2025-03-19  0:28           ` Ping-Ke Shih [this message]
2025-03-19 22:02             ` Bitterblue Smith
2025-03-20  0:38               ` Ping-Ke Shih
2025-03-21 17:36                 ` Bitterblue Smith
2025-03-24  0:39                   ` Ping-Ke Shih
2025-03-13 20:20 ` [PATCH rtw-next 4/4] wifi: rtw88: Don't set SUPPORTS_AMSDU_IN_AMPDU for RTL8814AU Bitterblue Smith
2025-03-17  3:31   ` Ping-Ke Shih

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=95da11e5ec6f43babaedc6dfc25c3cbf@realtek.com \
    --to=pkshih@realtek.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=rtl8821cerfe2@gmail.com \
    /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).