On Wed, Mar 03, 2010 at 10:55:26AM +1300, Derek Smithies wrote: > PID got it wrong - implicit in PID is the assumption that the rates can > be ordered in terms of more successful / less successful - and the > ordering follows the speed (faster speed=less successful). > > Since very slow rates are subject to interference loss (imagine there is > a 60hz transmitter out there) packets that take a long time to transmit > are far more likely to be shot down, stepping down a rate is going to > increase the loss rate. PID has more problems than just that -- it has lots of oscillation even when the rate is relatively stable. See this chart which I made using mac80211 hwsim and simulated loss (this was after I fixed the problem in commit e850f68b8f): http://bobcopeland.com/srcs/tcp_perf.pdf My simulation involved no collisions and just reduced the SNR over time. AARF in this case is an algorithm from academia, which is susceptible to collision related-loss as you describe above. In this example, it performed badly because of the latency inherent between packet queuing and status reporting. Minstrel definitely performs better 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? - 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. The large spikes at rate transition boundaries aren't quite so deep with fewer retries. -- Bob Copeland %% www.bobcopeland.com -- 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
