Bitterblue Smith <rtl8821cerfe2@xxxxxxxxx> wrote: > On 20/03/2025 02:38, Ping-Ke Shih wrote: > > Bitterblue Smith <rtl8821cerfe2@xxxxxxxxx> wrote: > >> On 19/03/2025 02:28, Ping-Ke Shih wrote: > >>> Bitterblue Smith <rtl8821cerfe2@xxxxxxxxx> wrote: > >>>> On 18/03/2025 04:06, Ping-Ke Shih wrote: > >>>>> Bitterblue Smith <rtl8821cerfe2@xxxxxxxxx> wrote: > >>>>>> On 17/03/2025 05:01, Ping-Ke Shih wrote: > >>>>>>> Bitterblue Smith <rtl8821cerfe2@xxxxxxxxx> 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.
