On Thursday 27 November 2008 20:39:34 Stefanik Gábor wrote: > On Thu, Nov 27, 2008 at 10:59 PM, Johannes Berg > > <johannes@xxxxxxxxxxxxxxxx> wrote: > > On Thu, 2008-11-27 at 19:52 -0200, Herton Ronaldo Krzesinski wrote: > >> 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. > > > >> And other drivers have same bug? > > > > possibly. > > > > Another thing: the ".count" is the number of tries you should do, so if > > the hardware expects retries then you need to subtract 1. Ops sorry, then I did a mistake in a previous patch reverting a subtract in rtl8187_tx. This will fix the code, will submit a patch with proper changelog: diff --git a/drivers/net/wireless/rtl818x/rtl8187_dev.c b/drivers/net/wireless/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, struct sk_buff *skb) hdr->flags = cpu_to_le32(flags); hdr->len = 0; hdr->rts_duration = rts_dur; - hdr->retry = cpu_to_le32(info->control.rates[0].count << 8); + hdr->retry = cpu_to_le32((info->control.rates[0].count - 1) << 8); buf = hdr; ep = 2; @@ -256,7 +256,7 @@ static int rtl8187_tx(struct ieee80211_hw *dev, struct sk_buff *skb) memset(hdr, 0, sizeof(*hdr)); hdr->flags = cpu_to_le32(flags); hdr->rts_duration = rts_dur; - hdr->retry = cpu_to_le32(info->control.rates[0].count << 8); + hdr->retry = cpu_to_le32((info->control.rates[0].count - 1) << 8); hdr->tx_duration = ieee80211_generic_frame_duration(dev, priv->vif, skb->len, txrate); > > > > 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 resulted > 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 before > 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 applied while count is not enforced by mac80211. -- []'s Herton -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
