2010/7/26 Felix Fietkau <nbd@xxxxxxxxxxx>: > On 2010-07-26 7:10 PM, Björn Smedman wrote: >> I think there are some (in theory) simple improvements that can be >> done to the tx aggregation / rate control logic. A proof of concept of >> one such improvement is provided below. Basically, it's a hack that > I think it makes sense to rely less on on-chip MRR for fallback, but I > think to make this workable, we really should use the MRR table for > something, otherwise the rate control algorithm will take much longer to > adapt. > It's probably better to fix this properly after I'm done with my A-MPDU > rewrite, because then I can more easily push parts of the software > retransmission behaviour into minstrel_ht directly. Sounds very reasonable. I'm sure you've thought of it but now that it's fresh in my head it would be great if the new aggregation design allowed us to experiment with stuff like this: * The rate control logic treats the average aggregate length as a measured independent variable, when in fact it depends heavily on the rates selected (via the 4 ms txop limit). * When tx is aggregated most rate control probe frames end up inside aggregates and are never used for probing (effective probe frequency is divided by average aggregate length). * When setting up a hardware MRR for an aggregate the focus should be on throughput (as explained earlier in this thread). But there are situations when reliability is important: e.g. when a subframe in the aggregate is about to expire (because of time or block ack window). It may even be advantageous to tx the subframes that are about to expire in their own aggregate with lower / more reliable bitrate? * In many busy radio environments the packet success rate depends very much on the protection method being used (none, cts-to-self or rts-cts), often more so than on the bitrate itself. It would be interesting to experiment with including the protection method in the rate selection, i.e. to probe for the optimal protection method and bitrate combination. * In order to have the best possible rate control in very dynamic rf environments it's important to keep the hardware queue short and select rates as late as possible (to not introduce unnecessary delay when selecting new rates). I have no idea how to do this but it would be great if the tx queue could be kept long enough to never stall tx, but no longer. * If I understand correctly the Atheros hardware does not adjust the rts / cts-to-self duration field when going through the MRR (correct?). In that case it may be even more advantageous to use software retry as much as possible when some form of protection is enabled. Looking forward to the new aggregation code! /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
