On Thu, 2021-05-20 at 09:28 +0800, 邱名碩 wrote: > Pkshih <pkshih@xxxxxxxxxxx> 於 2021年5月14日 週五 下午2:08寫道： > > > > > -----Original Message----- > > > From: 邱名碩 [mailto:ccchiu77@xxxxxxxxx] > > > Sent: Monday, May 10, 2021 4:36 PM > > > To: Pkshih; Andy Huang; Larry.Finger@xxxxxxxxxxxx; > > > kuba@xxxxxxxxxx; kvalo@xxxxxxxxxxxxxx; Reto > > > Schneider; linux-wireless@xxxxxxxxxxxxxxx; > > > linux-kernel@xxxxxxxxxxxxxxx > > > Subject: How does the rate adaptive mask work on Realtek WiFi > > > driver > > > > > > Hi guys, > > > I had a problem while verifying the ampdu tx throughput with > > > the > > > rtl8xxxu driver on RTL8188CUS module. The throughput number is > > > relatively good, 39~42Mbps TCP on 2.4GHz channel. However, the > > > retransmission rate is high, it's 15% ~ 21% with rtl8xxxu driver > > > and > > > It's almost the same result with the rtl8192cu driver. I can get > > > averagely 7~10% retransmission rate in the same test bed with > > > Realtek > > > vendor driver. > > > > > > From the air capture, I can see the rtl8xxxu driver keep > > > sending > > > the aggregated frames in MCS7 and doesn't even fall back to lower > > > MCS > > > index in the subsequent retries. I can only see very few retried > > > packets been sent with MCS0 or 6Mbps grate. On the vendor driver, > > > I'll > > > see the retried ampdu packets with MCS4 after 3 retries w/o ack > > > from > > > the receiver. > > > > > > From the rate mask command issued by the h2c command, I force > > > both > > > the rtl8xxxu driver and vendor driver to use the same ratemask > > > 0xfffff > > > (MCS 0-7 and b/g rate included) and leave the arg0 as-is (mostly > > > 0xa0) > > > and I expect both drivers can do the rate adaptive thing in the > > > same > > > way, but it seems to make no difference. The rtl8xxxu driver > > > still > > > sends the packets with highest MCS. > > > > > > Can anyone tell me what should I expect the rate adaptive to > > > work > > > with the rate mask 0xfffff and 0xf0000? Does the 0xf0000 means > > > that it > > > will pick up a tx rate only between nrate MCS4 to MCS7? I need a > > > base > > > line so that I can judge it's simply a rate mask problem or maybe > > > the > > > h2c command is not written correctly. Please kindly suggest what > > > I > > > should do next. Thanks > > > > > > > The rate mask indicates which rates will be used by rate adaptive > > mechanism. > > I'm not sure the exact bit allocation for CCK/OFDM/MCS, maybe > > 0x0000f/0x00ff0/0xff0000 for CCK/OFDM/MCS respectively, but you can > > trace > > vendor driver to know the detail. > > > > I suggest you can try to send only OFDM rate mask, and expect to > > see OFDM > > rate only by your sniffer. If it's still keep on MCS7, rate > > adaptive may > > not work properly. > > > Thanks. That's my expectation and I'll try to verify it on vendor > driver and upstream rtl8192cu driver. > > > Also, you can compare the content of rate adaptive H2C with vendor > > driver to > > see if the format is correct. > > > > Another thing is to try 'fix_rate' in tx_desc. Check the vendor > > driver to > > know the use_rate/rate/bw fields of tx_desc. Then, try to fix the > > rate you > > want. > > > If I set the fix_rate in tx_desc, will the rate mask in H2C command > be > ignored? Or the underlying firmware will do the tx rate fallback for > the retry packets? > The priority of fix rate in tx_desc is higher than rate mask in H2C command; yes, H2C is ignored. But it still does retry rate fallback unless you disable it in tx_desc. I think you can clarify whether the rate is controlled by firmware rate adaptive mechanism first. -- Ping-Ke
