On Tue, Mar 07, 2023 at 01:39:19AM +0000, Ping-Ke Shih wrote: > > > > -----Original Message----- > > From: Sascha Hauer <s.hauer@xxxxxxxxxxxxxx> > > Sent: Monday, March 6, 2023 9:00 PM > > To: Larry Finger <Larry.Finger@xxxxxxxxxxxx> > > Cc: Ping-Ke Shih <pkshih@xxxxxxxxxxx>; linux-wireless <linux-wireless@xxxxxxxxxxxxxxx> > > Subject: Re: Performance of rtw88_8822bu > > > > On Mon, Mar 06, 2023 at 10:18:45AM +0100, Sascha Hauer wrote: > > > Hi Larry, > > > > > > On Sat, Mar 04, 2023 at 08:52:26PM -0600, Larry Finger wrote: > > > > Sascha an Ping-Ke, > > > > > > > > I have been testing the RTW8822BU driver found in my rtw88 GitHub repo. This > > > > code matches the code found in wireless-next. I created 9 files of 5.8 GiB > > > > each and used a for loop to copy them from the test computer to/from my > > > > server. The wireless connection is on the 5 GHz band (channel 153) connected > > > > to an ax1500 Wifi 6 router, which in turn is connected to the server via a > > > > 1G ethernet cable. The connection has not crashed, but I see strange > > > > behavior. > > > > > > What chipset are you using? Is it a RTL8822bu or some other chipset > > > reported by the driver? > > > > > > > > > > > With both TX and RX, the rate is high at 13.5 MiB/s for RX and 11.1 MiB/s > > > > for TX for about 1/3 of the time, but then the driver reports "timed out to > > > > flush queue 3" and the rate drops to 3-5 MiB/s for RX and 2-3 MiB/s for TX. > > > > These low rates are in effect for 2/3 of the time. The 5G bands are > > > > relatively unused in my house, thus I do not suspect interference. > > > > > > I've received a very similar report this weekend. About 3-4 messages per > > > second, "timed out to flush queue 3", but driver continues to work. > > > I've also seen it this morning by accident and once again while writing > > > this mail. This was on a RTL8821CU. > > > > > > So far I have no idea what the problem might be. > > > > The "timed out to flush queue %d\n" message comes from > > __rtw_mac_flush_prio_queue(). Here some registers are read which show > > the number of reserved pages for a queue and the number of available > > pages of a queue. I used the debugfs interface to observe these > > registers from time to time: > > > > f=$(echo /sys/kernel/debug/ieee80211/phy*/rtw88/read_reg); for i in 0x230 0x234 0x238 0x23c; do echo "$i > > 4" > $f; cat $f; done > > > > This is what they show: > > > > reg 0x230: 0x00230040 > > reg 0x234: 0x00400040 > > reg 0x238: 0x00400040 > > reg 0x23c: 0x00000000 > > > > The upper 16bit contain the number of available pages and the lower > > 16bit contain the number of reserved pages (Note these are the registers > > on a RTL8822CU, on other chipsets the number of available pages is > > lower, like 0x10 on RTL8821CU). Register 0x230 is the interesting one > > for us, it has the values for queue 3. > > > > What I can see is that for the other queues the number of reserved pages > > usually matches the number of available pages. It happens sometimes that > > the number of available pages goes down to 0x3f, but with the next > > register read it goes back to 0x40. For 0x230 this is different though. > > Here the number of available pages continuously decreases over time and > > never goes back up. > > > > I don't know what this is trying to tell me. It seems that things queued > > to queue RTW_DMA_MAPPING_HIGH are sometimes (always?) stuck. > > Unfortunately I also don't know how the different priority queues relate > > to the different USB endpoints and how these in turn go together with > > the qsel settings. Maybe Ping-Ke can shed some light on this. > > > > To quickly check if RTW_DMA_MAPPING_HIGH get stuck, changing qsel_to_ep[] > to different priority queue would be helpful to identify the problem. > If only this queue works not well, we may dig MAC settings. Otherwise, > it may be a RF performance problem. By changing qsel_to_ep[] I can shift the problem to other priority queues. I changed qsel_to_ep[] back to default then and tried this instead: - txdma_pq_map |= BIT_TXDMA_HIQ_MAP(rqpn->dma_map_hi); - txdma_pq_map |= BIT_TXDMA_MGQ_MAP(rqpn->dma_map_mg); + txdma_pq_map |= BIT_TXDMA_HIQ_MAP(RTW_DMA_MAPPING_NORMAL); + txdma_pq_map |= BIT_TXDMA_MGQ_MAP(RTW_DMA_MAPPING_NORMAL); >From my understanding RTW_DMA_MAPPING_HIGH shouldn't be used anymore and I assumed that the number of available pages shown at 0x230 (REG_FIFOPAGE_INFO_1) shouldn't shrink anymore. To my surprise the value in 0x230 is still shrinking. I still wonder how the different endpoints relate to the different priority queues. Does a packet destined for a certain priority queue have to go through a specific endpoint, or are they completly unrelated? Sascha -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
