On 2013-07-02 3:28 PM, Jean-Pierre Tosoni wrote: > Hi Felix, > >> -----Message d'origine----- >> De : Felix Fietkau [mailto:nbd@xxxxxxxxxxx] >> > --- >> > 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. > > Well, on one hand, people who want to reduce retries are more concerned with > low latency and jitter than with reliable delivery of data. Makes sense. > On another hand the code should work for any rate control plugin, not just > minstrel. But much more important than that is to not cause regressions for other people via aggressive packet dropping. > Finally this code is executed for each frame, and I don’t want to bloat it > more than necessary... If you put the code in minstrel (and minstrel_ht), it not only allows making a better tradeoff for retry handling, the code also doesn't have to be run for every single packet. You can run it during the rate control stats update. The reduction of retry attempts definitely needs to be balanced properly. Retries with max_prob_rate can be more important than retries with max_tp_rate, but there needs to be a minimum for each of those. - 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
