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

[Pkshih <pkshih@realtek.com>]

On Thu, 2021-05-20 at 09:28 +0800, 邱名碩 wrote:
> Pkshih <pkshih@realtek.com> 於 2021年5月14日 週五 下午2:08寫道：
> > 
> > > -----Original Message-----
> > > From: 邱名碩 [mailto:ccchiu77@gmail.com]
> > > Sent: Monday, May 10, 2021 4:36 PM
> > > To: Pkshih; Andy Huang; Larry.Finger@lwfinger.net; 
> > > kuba@kernel.org; kvalo@codeaurora.org; Reto
> > > Schneider; linux-wireless@vger.kernel.org; 
> > > linux-kernel@vger.kernel.org
> > > 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