On Mon, Feb 8, 2016 at 1:23 PM, Felix Fietkau <nbd@xxxxxxxxxxx> wrote: > On 2016-02-08 12:06, Krishna Chaitanya wrote: >> On Mon, Feb 8, 2016 at 4:34 PM, Felix Fietkau <nbd@xxxxxxxxxxx> wrote: >>> On 2016-02-08 10:54, Krishna Chaitanya wrote: >>>> On Mon, Feb 8, 2016 at 2:56 PM, Emmanuel Grumbach <egrumbach@xxxxxxxxx> wrote: >>>>> On Mon, Feb 8, 2016 at 10:38 AM, Felix Fietkau <nbd@xxxxxxxxxxx> wrote: >>>>>> Requires software tx queueing support. frag_list support (for zero-copy) >>>>>> is optional. >>>>>> >>>>>> Signed-off-by: Felix Fietkau <nbd@xxxxxxxxxxx> >>>>>> --- >>>>> >>>>> >>>>> Ok - looks fine, but... and here comes the hard stuff. >>>>> The frame size in the PLCP is limited in a way that you can't - from a >>>>> spec POV - enable A-MSDU for low rates. Of course, you don't want to >>>>> do that for low rates at all regardless of the spec. >>>>> Since you build the A-MSDU in the mac80211 Tx queue which is not aware >>>>> of the link quality, how do we prevent A-MSDU if the rate is low / >>>>> dropping. >>>>> I'd even argue that when the rates get lower, you'll have more >>>>> packets piling up in the software queue and ... even more chance to >>>>> get A-MSDU in the exact case where you really want to avoid it? >>>> >>>> Similar to triggering AMPDU setup, we should put this control >>>> in RC (minstrel) to start/stop AMSDU based on link quality/if the rates >>>> drop below a pre-defined MCS (or) only for best-throughput rates. >>> I think starting/stopping A-MSDU based on the rate is a bad idea. >>> Even with low rates, using A-MSDU can be a good thing (especially for >>> TCP ACKs), it just needs different size limits. >> >> By low rates, i was referring to bad channel conditions (more >> retries/crc errors) >> so using AMSDU might trigger more TCP level retries and for case >> of TCP ACK's its still worse in that it triggers TCP data retires from the >> peer. > Based on the research and data from the Bufferbloat project, I'd say > that in this case the latency due to queue buildup is a lot more harmful > than lost packets. > With unmanaged queues, the latency will cause unnecessary > retransmissions anyway. > With managed queues, packet drops start increasing with latency until > TCP starts behaving properly. > In both cases you have extra TCP retransmissions... > > With bad conditions you also get a strong increase in per-TXOP latency. > With A-MSDU you need fewer TXOPs for the same amount of data in the queue. Assuming you don't have collisions, then yes. But when things go bad, you may very well have more collisions, and A-MSDU becomes a disaster. The way I see it, collisions and "bad conditions" are tightly related. -- 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
