RE: [PATCH rtw-next 3/4] wifi: rtw88: Set AMPDU factor to hardware

[Ping-Ke Shih <pkshih@realtek.com>]

Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
> On 20/03/2025 02:38, Ping-Ke Shih wrote:
> > Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
> >> On 19/03/2025 02:28, Ping-Ke Shih wrote:
> >>> 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.
> >>>
> >>
> >> I checked today. With 0xffffffff I see 29% retransmission rate. With
> >> 0xffff the retransmission rate is only 8.6%.
> >
> > Can you help to confirm if retransmission is because AP can't receive the long
> > packets? I suppose the BA bitmap from AP aren't all one's.
> >
> 
> In a 30 second capture in the middle of running iperf3 with 0x458 =
> 0xffff there were 11440 block ack from the router to the RTL8814AU.
> Of those, 138 (1.2%) were block ack with the bitmap not all 1s.
> 
> In another 30 second capture in the middle of running iperf3 with
> 0x458 = 0xffffffff there were 8112 block ack from the router to the
> RTL8814AU. Of those, 305 (3.76%) were block ack with bitmap not all
> 1s.
> 
> See the attachments.

Thanks for the results, which shows ~90M (3.76%) vs ~300M (1.2%). 
Though we can't understand the rate of not all 1s can affect so much. 
Anyway, let's move on.