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 rtl8188cus vendor driver I tested is here (It can be compiled with
kernel 5.12+)
https://github.com/mschiu77/rtl8188cus_vendor/
Chris
邱名碩 <[email protected]> 於 2021年5月10日 週一 下午4:35寫道：
>
> 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 rtl8188cus vendor driver I tested is here (It can be compiled with
> kernel 5.12+)
> https://github.com/mschiu77/rtl8188cus_vendor/
>
> Chris
Gentle ping. Any suggestions would be appreciated.
Chris
> -----Original Message-----
> From: 邱名碩 [mailto:[email protected]]
> Sent: Monday, May 10, 2021 4:36 PM
> To: Pkshih; Andy Huang; [email protected]; [email protected]; [email protected]; Reto
> Schneider; [email protected]; [email protected]
> 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
Pkshih <[email protected]> 於 2021年5月14日 週五 下午2:08寫道：
>
>
> > -----Original Message-----
> > From: 邱名碩 [mailto:[email protected]]
> > Sent: Monday, May 10, 2021 4:36 PM
> > To: Pkshih; Andy Huang; [email protected]; [email protected]; [email protected]; Reto
> > Schneider; [email protected]; [email protected]
> > 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?
Chris
> --
> Ping-Ke
>
On Thu, 2021-05-20 at 09:28 +0800, 邱名碩 wrote:
> Pkshih <[email protected]> 於 2021年5月14日 週五 下午2:08寫道：
> >
> > > -----Original Message-----
> > > From: 邱名碩 [mailto:[email protected]]
> > > Sent: Monday, May 10, 2021 4:36 PM
> > > To: Pkshih; Andy Huang; [email protected];
> > > [email protected]; [email protected]; Reto
> > > Schneider; [email protected];
> > > [email protected]
> > > 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