On Thu, Mar 4, 2010 at 3:12 PM, Bob Copeland <me@xxxxxxxxxxxxxxx> wrote: > > Minstrel definitely performs better in real life. Agree, minstrel works very well in real life. > That said, I looked at the current minstrel code and have a few > puzzlements: > > - As I understand it, minstrel is not supposed to delay packets more > than 24 ms to avoid TCP resends. However, if I understand the code, > this is done by limiting each MRR segment to 6 ms, which doesn't seem > right to me. The retries in the second MRR slot will have to wait > a backoff before being used, right? I took a look at the minstrel code back in madwifi and the comments there suggest this 24 ms thing is not very theoretically based. It sounds like a very reasonable explanation though so I'm not saying it is wrong. But I think there might be another very good reason to limit the number of attempts at a given rate: after a certain number of retries we have to conclude that our hypothesis about the packet error/success rate is probably incorrect, and there is no point in more retries at that rate. An example: Lets say my hypothesis is that the packet error rate at 24 Mbit/s is 10%. The probability that 3 attempts in a row will fail is then 0.1^3 = 0.1% (given that my hypothesis is correct). A statistician would say that we have tested my hypothesis and that it can be rejected on the 99.9%-level. Continuing with a fourth attempt is approaching what Einstein defined as insanity: doing the same thing over and over again and expecting different results. :) > - Often, two slots in the MRR array use the same rate (e.g. slots 1 and 3). > Maybe we should pick a 'next lower' rate for the lower slot in such a case? > If we are really in a place where the originally attempted rate isn't > workable, this might slightly boost throughput. Agree. With the same reasoning as above this can be generalized to: if an MRR slot has failed and we have fallen through to the next one then that slot should be set up to be optimal under a new hypothesis (taking the failed MRR segment into account). In any case Felix patch is a giant leap towards better rate control. Looking forward to tweaking it and this time hopefully submitting something. /Björn -- 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
