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. > > 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. -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) -- 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
