On 2013-06-27 6:40 PM, Jean-Pierre Tosoni wrote: > From: J.P. Tosoni <jp.tosoni@xxxxxxxxx> > > In the rate control algorithms, the maximum retry count is limited by > a) a constant value obtained from the hardware driver > b) a constant limit (6ms) on the time allowed for all > retries of each frame. > > Replace the retry count by existing configurable values from nl80211. > Use wiphy->retry_long for frames whose length exceed rts_threshold. > Use wiphy->retry_short for all other frames. > Check that the configured value does not exceed driver capabilities. > Use the new values as soon as the next frame is transmitted. > > Caveat: the retry count for frames sent outside the context of a STA is > still taken from the hardware driver. > --- > What I am seeking with this patch: > I believe the configuration of the retries will help making recovery > much faster when an AP (in infrastructure mode) or a peer (in mesh > mode) suddenly disappears. I'm all for reducing retries, but I think the way you're applying the limit is problematic. If minstrel decides to use many retries for a high rate and you're simply cutting off all retries that exceed the configured limit, you're potentially inviting quite a bit of unnecessary packet loss. I'm planning to remove the use of retry rate slot 4 (fallback to lowest rate) from minstrel, since max_prob_rate should already provide quite decent reliability. - Felix -- 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
