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. On another hand the code should work for any rate control plugin, not just minstrel. Finally this code is executed for each frame, and I don?t want to bloat it more than necessary... I am thinking of trimming only the largest retry count in the table, but not below 2 (one try and one retry). I'll test this today. Do you feel this is a good path ? Or should I just wait for the slot 4 removal ? I could also split the trimming between 2 rates, the largest count and the next-to-largest. Or I could use a minimum of 1 instead of 2. > > - Felix Jean-Pierre -- 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
