On Mon, Feb 8, 2016 at 3:23 AM, 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. +1. > With unmanaged queues, the latency will cause unnecessary > retransmissions anyway. typically at greater than 250ms, yes. It's my hope that everyone has agreed that > 250ms of queuing is bad, except for actual transit to the moon and back, at this point. My hope is that everyone can aim for < 20ms in the more general case. I was very happy to see the iwl patch go by cutting things down from seconds to 30-250ms under load, but am now puzzled. One iwl user has reported that AMPDUs are disabled by default on iwl, and had to do this: options iwlwifi 11n_disable=8 For a 4fold reduction in latency under load in his tests, iwl to ath9k. What enables/disable AMPDU and AMSDU in the general case? > With managed queues, packet drops start increasing with latency until > TCP starts behaving properly. > In both cases you have extra TCP retransmissions... One thrust of mine has been to get ecn more widely adopted, which would eliminate the tcp retransmit problem on devices using it for congestion control (except on actual loss). Apple turned ecn on universally on all dev devices last august. They ran into trouble with one major ISP and had to turn it off, I am not sure if they shipped with it on or not. https://plus.google.com/u/0/107942175615993706558/posts/1j8nXtLGZDm Stuart Cheshire also points at a real case where excessive queuing hurts and fq doesn't help - screen sharing - with a nice demo combining fq_codel + the tcp_netsent_lowat option. (his talk starts at about 16 minutes in, he goes into the relevant bits at about 24 minutes in, and I'm sorry for always pointing people at talks rather than papers) Toke ("the good, the bad, and the wifi") points to excessive queuing *not* being a problem so long as the fq portion is sufficiently close to the hardware, in other scenarios. http://www.sciencedirect.com/science/article/pii/S1389128615002479 Now, as to whether a driver or device doing retransmits should (or even could) drop or mark packets is a good question. I am biased towards achieving low latency and per device fairness so I lean towards giving up a lot sooner in bad conditions and moving on.... > With bad conditions you also get a strong increase in per-TXOP latency. Having an agreed upon table for all the "bad" conditions and what should be done in these cases would be good. I don't regard "contention" as a bad condition, but as an indicator to be smarter about bunching up and/or discarding packets. Interference is a "bad" condition. Low rates for one station compared to the others is not a bad condition, as striving for airtime fairness between all stations is a reasonable goal... etc... > With A-MSDU you need fewer TXOPs for the same amount of data in the queue. I like it. :) I note that for stations, I am perpetually seeing this sort of behavior: ap -> transmits a bunch of packets to station station -> takes 2 or more txops to respond why? it takes some processing time for the station to send out it's next batch of packets. Slightly better to wait until more stuff is batched up (and I know, this is hard) (it sounds like the iwl defers the aggregation decision, so might not do this. ath9k will do this) I would like to be testing for this behavior. > > - Felix > -- > 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 -- 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
