RE: How does the rate adaptive mask work on Realtek WiFi driver

[Pkshih]

> -----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.

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.

--
Ping-Ke