Re: [RFC] rtl8187: Do not wait for an ACK when IEEE80211_TX_CTL_NO_ACK is set

On Thursday 27 November 2008 20:39:34 Stefanik G=E1bor wrote:

On Thu, Nov 27, 2008 at 10:59 PM, Johannes Berg

[off-list ref] wrote:

quoted

On Thu, 2008-11-27 at 19:52 -0200, Herton Ronaldo Krzesinski wrote:

quoted

In this case then shouldn't mac80211/rate control alg give a right
rates[0].count?

It probably should put 1 into that value, yes. It doesn't seem to
enforce that now though, I'll take a look at doing that.

quoted

And other drivers have same bug?

possibly.

Another thing: the ".count" is the number of tries you should do, s=

o if

quoted

the hardware expects retries then you need to subtract 1.

Ops sorry, then I did a mistake in a previous patch reverting a subtrac=
t in=20
rtl8187_tx. This will fix the code, will submit a patch with proper cha=
ngelog:

diff --git a/drivers/net/wireless/rtl818x/rtl8187_dev.c b/drivers/net/w=

ireless/rtl818x/rtl8187_dev.c
index ceebeb7..41444e2 100644

--- a/drivers/net/wireless/rtl818x/rtl8187_dev.c
+++ b/drivers/net/wireless/rtl818x/rtl8187_dev.c

@@ -238,7 +238,7 @@ static int rtl8187_tx(struct ieee80211_hw *dev, str=

uct sk_buff *skb)
 		hdr->flags =3D cpu_to_le32(flags);
 		hdr->len =3D 0;
 		hdr->rts_duration =3D rts_dur;
-		hdr->retry =3D cpu_to_le32(info->control.rates[0].count << 8);
+		hdr->retry =3D cpu_to_le32((info->control.rates[0].count - 1) << 8);
 		buf =3D hdr;
=20
 		ep =3D 2;

@@ -256,7 +256,7 @@ static int rtl8187_tx(struct ieee80211_hw *dev, str=

uct sk_buff *skb)
 		memset(hdr, 0, sizeof(*hdr));
 		hdr->flags =3D cpu_to_le32(flags);
 		hdr->rts_duration =3D rts_dur;
-		hdr->retry =3D cpu_to_le32(info->control.rates[0].count << 8);
+		hdr->retry =3D cpu_to_le32((info->control.rates[0].count - 1) << 8);
 		hdr->tx_duration =3D
 			ieee80211_generic_frame_duration(dev, priv->vif,
 							 skb->len, txrate);

quoted

johannes

I actually tested that 0 is the right setting - I initially tested it
with 1, and there was evidence that it was still retrying. Setting it
to 0 truly behaved like a NO_ACK bit would on other HW. (I used
aireplay-ng to get a view of transmission speed - the "chopchop" and
"interactive replay" are good indicators. I used a patch to make all
injected frames NO_ACK, then tested the highest rate that results in
no multiple tries for the same number in chopchop. With the original
code, I could transmit 25 frames per second - anything higher resulte=

d

in chopchop requiring more than 256 packets for each byte. Most
drivers start to behave this way over about 600 to 700 packets per
second. Setting the retry count to 1 resulted in a max of 220/s befor=

e

producing more-than-256-attempts errors, still lower than what other
drivers do with NO_ACK, suggestive of the driver still retrying.
Setting to 0 resulted in a 625/s max, on par with other drivers.)
This means, hdr->retry is the number of retries, unlike ".count",
which is the number of tries, including the initial transmit.

yep, you're right, I wrongly considered the retry field, that also made=
 me
introduce a bug that diff above fixes. Your patch was good, could be ap=
plied
while count is not enforced by mac80211.

--
[]'s
Herton
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html