Just to add another datapoint, the "rack" optimization for tcp entered the kernel recently. It has some "interesting" timing/batching sensitive behaviors. While the TSO case is described, the packet aggregation case seems similar, and is not. https://www.ietf.org/proceedings/96/slides/slides-96-tcpm-3.pdf 10 Jan 2016 https://kernelnewbies.org/Linux_4.4#head-2583c31a65e6592bef9af426a78940078df7f630 The draft was significantly updated this month. https://tools.ietf.org/html/draft-cheng-tcpm-rack-01 -- Andrew Shewmaker On Mon, Jul 18, 2016 at 2:49 PM, Toke Høiland-Jørgensen <toke@xxxxxxx> wrote: > Toke Høiland-Jørgensen <toke@xxxxxxx> writes: > >> Felix Fietkau <nbd@xxxxxxxx> writes: >> >>> Hi, >>> >>> With Toke's ath9k txq patch I've noticed a pretty nasty performance >>> regression when running local iperf on an AP (running the txq stuff) to >>> a wireless client. >>> >>> Here's some things that I found: >>> - when I use only one TCP stream I get around 90-110 Mbit/s >>> - when running multiple TCP streams, I get only 35-40 Mbit/s total >>> - fairness between TCP streams looks completely fine >>> - there's no big queue buildup, the code never actually drops any packets >>> - if I put a hack in the fq code to force the hash to a constant value >>> (effectively disabling fq without disabling codel), the problem >>> disappears and even multiple streams get proper performance. >>> >>> Please let me know if you have any ideas. >> >> Hmm, I see two TCP streams get about the same aggregate throughput as >> one, both when started from the AP and when started one hop away. > > So while I have still not been able to reproduce the issue you > described, I have seen something else that is at least puzzling, and may > or may not be related: > > When monitoring the output of /sys/kernel/debug/ieee80211/phy0/aqm I see > that all stations have their queues empty all the way to zero several > times per second. This is a bit puzzling; the queue should be kept under > control, but really shouldn't empty completely. I figure this might also > be the reason why you're seeing degraded performance... > > Since the stats output doesn't include a counter for drops, I haven't > gotten any further with figuring out if it's CoDel that's being too > aggressive, or what is happening. But will probably add that in and take > another look. > > -Toke > -- > 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 -- Dave Täht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org -- 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
