On 07/27/2010 01:11 AM, Felix Fietkau wrote:
On 2010-07-26 9:23 PM, Björn Smedman wrote:
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).
Yes, with the new design maybe we could use the initial rate lookup only
for setting the sampling flag, and then doing a separate per-AMPDU
lookup, which properly takes the AMPDU length into account.
* 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).
Nope, a probing frame never ends up inside an aggregate. It's always
sent out as a single frame, which is why I had to make the decision
about sending a probing frame more complex in minstrel_ht, compared to
minstrel - the previous 10% stuff was limiting aggregation size.
* 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?
Yes, that's what I was thinking as well. We should probably make this
decision based on the number of sw-retransmitted frames, and maybe
consider the offset of seqno vs baw_tail as well.
* 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.
Sounds good.
* 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.
This would work with what I suggested above - per-AMPDU rate lookup.
With software scheduling that's easy to do, since we already restrict
the queue to max. 2 AMPDUs
* 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.
Not sure, but I think it does adjust the duration field according to the
rate, while transmitting.
[ranga] Yes it does. If you enable RTS on all rates, you would see
different RTSs coming with different duration.
Looking forward to the new aggregation code!
That will still take some time, I recently came up with some better
design ideas, which require some larger changes to the code that I
already wrote.
- Felix
_______________________________________________
ath9k-devel mailing list
ath9k-devel@xxxxxxxxxxxxxxx
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
--
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
